Odpowiedź

Historia pytania:

W miarę wzrostu złożoności oprogramowania zauważono, że część błędów wykrywana jest tylko poza testami lub specyfikacjami — często takie błędy są najbardziej krytyczne dla rzeczywistych użytkowników. Aby znaleźć takie defekty, testerzy stosują specjalne techniki, łącząc standardowe testy z własnym doświadczeniem.

Problem:

Ukryte błędy związane z interakcją komponentów, nieprawidłowym przetwarzaniem nieoczywistych sytuacji lub brakiem wymagań są najtrudniejsze do wykrycia i udokumentowania. Często testerzy nie są pewni, czy warto dokumentować znaleziony problem, jeśli "nie jest opisany w specyfikacji".

Rozwiązanie:

Stosują metody testowania eksploracyjnego, testowania parami, doświadczenie w pracy z podobnymi produktami. Zawsze dokumentuj taki błąd jak najdokładniej: kroki, obserwacje, dlaczego uważasz, że to defekt, odnośniki do pokrewnych wymagań lub przyjętej logiki.

Kluczowe cechy:

Konieczność inicjatywy i krytycznego myślenia.
Ważne jest, aby uzasadnić, dlaczego to właśnie defekt.
W niektórych przypadkach należy brać udział w dyskusji z analitykami/PO.

Pytania z pułapką.

Czy błędy, które nie są opisane w wymaganiach, można ignorować lub nie dokumentować?

Nie, zawsze zgłaszaj, nawet jeśli nie ma dokładnego odniesienia do wymagania, w przeciwnym razie krytyczne problemy trafią do klienta.

Czy niedogodność użytkownika jest błędem, czy poprawką (feature request)?

Jeśli zachowanie jest ewidentnie nielogiczne, powoduje zamieszanie lub ryzyko, dokumentuj to jako błąd, w przeciwnym razie — jako poprawkę.

Czy tester powinien konsultować się z zespołem w sprawie każdego nieoczywistego błędu?

Zaleca się wstępne omówienie spornego przypadku z analitykiem lub programistą, aby uniknąć bezsensownych zgłoszeń.

Typowe błędy i antywzorce

Ignorowanie oczywistych dla użytkowników defektów, które nie są opisane w wymaganiach.
Słabe/niedostateczne dokumentowanie ukrytych błędów.
Brak uzasadnienia dla raportu błędu.

Przykład z życia

Negatywny przypadek

Tester zauważył, że podczas jednoczesnego otwierania dwóch okien system zawiesza się, ale nie zgłosił błędu, ponieważ taki scenariusz nie był opisany w wymaganiach i testach.

Zalety:

Nie dodał "zbędnego" błędu, uwolnił ręce programistom do innych zadań.

Wady:

System trafił do wydania z krytyczną podatnością, klienci ucierpieli.

Pozytywny przypadek

Tester zgłosił błąd z opisem kroków (otwarcie dwóch okien, sekwencja działań), dołączył zrzut ekranu, wyjaśnił, dlaczego uważa to za błąd (rzeczywisty użytkownik może się znaleźć w tej sytuacji).