Jak decydujesz, co trzeba przetestować?

Aby określić, co należy przetestować, używam kombinacji podejść:

1. Analiza wymagań:

   • Studiowanie dokumentacji (specyfikacje techniczne, historie użytkownika, specyfikacje).
   • Wyjaśnianie niejasnych punktów z analitykami, programistami, Product Ownerem.
   • Podział wymagań na atomowe przypadki testowe.

2. Testowanie oparte na ryzyku:

   • Identyfikacja najbardziej krytycznych lub najczęściej używanych funkcji systemu.
   • Ocena prawdopodobieństwa wystąpienia defektów i ich potencjalnego wpływu.
   • Priorytetyzacja testów na podstawie zidentyfikowanych ryzyk.

3. Analiza artefaktów rozwojowych:

   • Analiza makiet UI/UX.
   • Przegląd zmian w kodzie lub konfiguracji (w przypadku testów regresyjnych).
   • Analiza logów i raportów o wcześniejszych defektach.

4. Wykorzystanie technik analizy testów:

   • Podział na równoważne grupy.
   • Analiza wartości granicznych.
   • Diagramy stanów i przejść.
   • Tabele decyzyjne.

5. Testy eksploracyjne:

   • Swobodne badanie funkcjonalności w celu wykrycia nieoczywistych scenariuszy i defektów.
   • Generowanie pomysłów na testy na podstawie zrozumienia zachowania użytkownika i systemu.

6. Konsultacje z zespołem:

   • Omówienie szczegółów implementacji z programistami.
   • Wyjaśnienie scenariuszy użytkownika z Product Ownerem.
   • Wymiana doświadczeń i wiedzy z innymi testerami.

7. Automatyzacja:

   • Identyfikacja kandydatów do automatyzacji na podstawie stabilności, krytyczności i częstotliwości wykonywania testów.
   • Zastosowanie piramidy automatyzacji testów (Unit, Integration, UI).

Kombinacja tych podejść pozwala na stworzenie wystarczającego modelu testowego, obejmującego główne wymagania funkcjonalne i niefunkcjonalne, a także potencjalne ryzyko.