Odpowiedź.

Testowanie wymagań to ważny etap ręcznego testowania, ponieważ niedociągnięcia na tym etapie prowadzą do kosztownych błędów w przyszłości.

Historia pytania:

Na wczesnych etapach rozwoju wymagania dotyczące produktu są zapisane w formie dokumentów (specyfikacje, wymagania). Ich niewłaściwe lub niekompletne sformułowanie rodzi wiele problemów na etapie realizacji i testowania.

Problem:

Wymagania często okazują się niekompletne, niejednoznaczne lub sprzeczne. Prowadzi to do nieporozumień i niskiej jakości realizacji produktu. Tester powinien wcześniej wykrywać takie niespójności.

Rozwiązanie:

Ręczne testowanie wymagań obejmuje:

Dokładny audyt wymagań pod kątem kompletności, jasności i spójności
Sformułowanie dodatkowych pytań do analityków i klientów biznesowych
Rejestrowanie wszystkich przewidywanych scenariuszy użytkowania (przypadków pozytywnych/negatywnych)
Stosowanie technik analizy wymagań: tabele zgodności, macierze śledzenia, listy kontrolne dla wymagań

Kluczowe cechy:

Wykrywanie sprzeczności i „dziur” — identyfikowanie niezgodności i sytuacji, które nie są odzwierciedlone w wymaganiach
Aktywna komunikacja z analitykami i zespołem — wyjaśnianie szczegółów, doprecyzowywanie sformułowań
Formułowanie jasnych, testowalnych wymagań — wymagania powinny być jednoznaczne, wykonalne i mierzalne

Pytania refleksyjne.

Co oznacza „wymaganie jest testowalne”?

Testowalne wymaganie to takie wymaganie, które można dokładnie określić, czy zostało zrealizowane w produkcie, czy nie. Nie dopuszcza się w nim abstrakcji, ogólnych zwrotów i niejasnych parametrów.

Czy można uznać wymagania za wysokiej jakości, jeśli są zrozumiałe tylko dla autorów?

Nie. Wysokiej jakości wymagania muszą być jednoznacznie zrozumiałe dla wszystkich członków zespołu (programistów, testerów, analityków, biznesu).

Czy obowiązkiem testera jest dopisywanie lub poprawianie wymagań?

Nie, tester wykrywa problemy i informuje o nich odpowiedzialnych, ale nie powinien samodzielnie przepisywać wymagań.

Typowe błędy i antywzorce

Przyjmowanie wymagań na wiarę, bez zadawania dodatkowych pytań
Ignorowanie drobnych niezgodności i założeń
Nieudokumentowanie znalezionych „dziur” i sprzeczności, mając nadzieję, że „programiści się tym zajmą”

Przykład z życia

Negatywny przypadek

Tester otrzymał wymagania, nie sprawdził ich na kompletność i spójność, nie zwrócił uwagi na niejednoznaczne sformułowania. W rezultacie programiści różnie interpretowali te wymagania, pojawiły się nieprzewidziane scenariusze, które zostały wykryte dopiero podczas wydania.

Zalety:

Zaoszczędzony czas na etapie pisania wymagań

Wady:

Wiele poprawek na późniejszych etapach
Wysokie koszty poprawek błędów
Niezadowolenie klienta

Pozytywny przypadek

Na etapie zapoznawania się z wymaganiami tester przygotował pytania dla analityka biznesowego, wyjaśnił sporne kwestie, pomógł dodać negatywne scenariusze. Udało się uniknąć wielu nieporozumień i znacząco zmniejszyć liczbę błędów w wydaniu.