Menu

Jak radzić sobie ze złymi wymaganiami jako tester

how deal with bad requirements

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Cicha sala konferencyjna dusiła się i wszyscy w niej byli zdezorientowani. Jak mogliśmy to przegapić , było pytaniem, na które odbijała się twarz wszystkich.

W końcu brak wyświetlania się z żadnym istotnym błędem, gdy użytkownik próbuje zduplikować istniejący rekord i pozwolenie mu na to, nie był małym błędem - to też dla firmy ubezpieczeniowej.

Po podjęciu decyzji o rozwiązaniu problemu wszyscy się rozeszli. Podczas wykopywania zaobserwowano, że klient nigdy nie wspominał o dwulicowości zapisów w dokumencie wymagań i dlatego nikt nie zadawał istotnych pytań ani nie myślał o tym.

złe wymagania

To był tylko przykład.

W karierze trwającej ponad 10 lat , Zaobserwowałem wiele przypadków, w których projekty ucierpiały z powodu złych lub złych wymagań.

Ale jak mówią, nic nie jest doskonałe na tym świecie i będziesz musiał sobie z tym poradzić, a zajmowanie się projektami, które nie mają wymagań lub słabych wymagań, to swego rodzaju koszmar.

Pozwól mi wyjaśnić -

Czego się nauczysz:

Jak złe, słabe i sprzeczne wymagania powodują problemy:

# 1) Brak wymagań - Żadne wymagania nie oznaczają przypuszczeń i domysłów, dlatego nie ma pewności. Testowanie produktu / aplikacji bez punktu odniesienia jest bardzo trudne. A to powoduje więcej pracy, więcej błędów po stronie klienta i więcej cierpienia dla projektu.

  • Jak mógłbyś Zgłoś problem o awarii systemu, gdy nie ma definicji sposobu postępowania z zachowaniem, czy jest dostępna?
  • Jak można wyrazić, że czas ładowania strony głównej wynoszący 100 sekund jest niedopuszczalny, jeśli nie ma odpowiednich wymagań dotyczących wydajności?

Więcej informacji na temat braku wymagań i radzenia sobie z sytuacją podczas testowania można znaleźć we wcześniej opublikowanym artykule - Jak przetestować aplikację bez wymagań?

# 2) Słabe wymagania - Cytat, Świadomość czegoś niekompletnego jest niebezpieczna niż niewiedza w ogóle , jest bardzo prawdziwe, jeśli chodzi o radzenie sobie ze złymi wymaganiami.

Zinterpretowanie słabego wymagania i wdrożenie tego samego to duże ryzyko.

  • W jaki sposób potwierdzisz, że wyskakujące okienko z wynikami wyszukiwania jest prawidłowe, czy nie, skoro jedynym wymienionym wymaganiem było - wyniki wyszukiwania powinny być poprawne i nie masz pewności, które kryteria należy wziąć pod uwagę podczas wyszukiwania.
  • Jak byś to zinterpretował - Zapomniane hasło powinno zostać wdrożone, aby ułatwić użytkownikowi regenerację / zresetowanie zapomnianego hasła. Nie wiadomo, jakiego przepływu pracy klient chce zapomnieć hasła, programista wdraża to, co uważa za najlepsze, i zaczynają się konflikty.

# 3) Sprzeczne wymagania - Poproszenie kogoś o zrobienie dwóch różnych rzeczy w tym samym czasie po prostu wprowadza go w zakłopotanie, a system również nie jest wyjątkiem.

  • Jak przetestowałbyś aplikację z wymienionymi wymaganiami, jak poniżej:
    • Aplikacja powinna zawsze otwierać się na stronie głównej.
    • Użytkownicy muszą się zalogować, aby uzyskać dostęp do aplikacji.
  • Jaki byłby priorytet, jeśli dokument wymagań jest taki jak poniżej:
    • Aplikacja do gier powinna awansować użytkownika na następny poziom, jeśli użytkownik uzyska 1000 punktów.
    • Użytkownik powinien zostać przekierowany na stronę bezpłatnej subskrypcji, gdy zdobędzie 1000 punktów.

I w ten sposób złe, ubogie i sprzeczne wymagania stwarzają kłopoty.

Będąc w branży oprogramowania, powinno to być częścią projektu, ponieważ czasami nawet klient nie jest pewien, czego dokładnie chce i jak to sformułować.

Z perspektywy testów, chociaż trudno jest poradzić sobie z tymi niejednoznacznymi lub niejasnymi wymaganiami, nie jest to całkowicie niemożliwe.

Spójrzmy na możliwe rozwiązania:

Złe wymagania i jak sobie z nimi radzić jako tester:

Metoda nr 1)Przeglądaj i ucz się:

Poznawanie innych aplikacji, poznanie ogólnych oczekiwanych zachowań, zrozumienie przepływu pracy, myślenie o wygodzie użytkownika i stosowanie logiki to jeden ze sposobów radzenia sobie z sytuacją. Również, polegający na testach eksploracyjnych byłoby pomocne w tego rodzaju sytuacjach, w których wymagania nie są jasne.

W większości przypadków dobrym pomysłem jest priorytetowe traktowanie wygody użytkownika i wygody, gdy wymagania nie są jasne.

Metoda nr 2)Skorzystaj z doświadczenia:

Skorzystaj z doświadczenia

Doświadczenie domeny , ogólne doświadczenie w testowaniu, problemy z przeszłością i osobiste spostrzeżenia mogą pomóc w rozwiązaniu zagmatwanych sytuacji i wymagań.

Metoda nr 3)Odnoś się do modeli szkieletowych:

Modele szkieletowe są rodzajem wymogu wizualnego, w którym można znaleźć drobne szczegóły, które mogą być bardzo pomocne w tworzeniu oczekiwanego obrazu produktu lub aplikacji i pomagają w lepszym opisaniu aspektów testowania.

Czytaj więcej => Modele szkieletowe - czy naprawdę należy je przetestować? A jeśli tak, to jak?

Metoda nr 4)Dyskusja partnerska:

jak otworzyć plik .dat w systemie Windows

Dyskusja partnerska

Bez względu na zamieszanie, jeśli zostanie omówione z odpowiednią grupą ludzi, sprawy zostaną wyjaśnione. Każdy ma inne doświadczenia, oczekiwania, spojrzenie użytkownika i spojrzenie na analizę, a omawianie tych słabych wymagań z rówieśnikami będzie służyć krystalizacji zrozumienia i zwiększeniu pewności siebie.

Metoda nr 5)Wyjaśnienie od klienta:

Klient jest właścicielem produktu / aplikacji i zawsze mądrze jest zwracać się do niego, jeśli chodzi o jasność wymagań. Pamiętaj jednak, że nie zaleca się atakowania klienta setkami pytań. Zanim to zrobisz, wymagana jest praca domowa.

Spróbuj poznać dostępne najlepsze praktyki, zrozum korzyści płynące z wdrożenia, a następnie skontaktuj się z klientem z pytaniem i możliwym rozwiązaniem.

Wniosek

Wreszcie, luźno zdefiniowane lub niezdefiniowane wymagania są częścią życia testera i musimy je zaakceptować, ale spróbujmy być optymistami i znaleźć rozwiązania. W końcu jesteśmy testerami, pomagamy utrzymać aplikacje na właściwym torze i chronić je przed upadkiem. YAY do nas :)

O autorze: Ten inspirujący post został napisany przez członka zespołu STH, Bhumikę M. Jest kierownikiem projektu i ma ponad 10-letnie doświadczenie w testowaniu oprogramowania.

Życzymy udanego testowania, jak zwykle…… czekam na Wasze opinie, komentarze i opinie.

rekomendowane lektury

^