Odpowiedź.

Projektowanie testów to proces opracowywania scenariuszy testowych i danych na podstawie wymagań, specyfikacji i analizy produktu. Powstał w wyniku potrzeby uporządkowania testów, aby zapewnić maksymalne pokrycie i minimalizować powielanie wysiłków.

Historia pytania:

Wcześniej testy były tworzone intuicyjnie, co prowadziło do luk w weryfikacjach i nieefektywnego wykorzystania zasobów. Metody projektowania testów pozwoliły zwiększyć jakość i kompletność pokrycia.

Problem:

Bez sformalizowanych technik istnieje ryzyko nadmiaru jednorodnych testów lub, przeciwnie, pominięcia krytycznych przypadków. Ponadto trudno udowodnić wystarczalność testowania przed wydaniem.

Rozwiązanie:

Wdrożenie techniki projektowania testów pozwala racjonalnie rozdzielić zasoby, wyróżnić najważniejsze sprawdzenia i kontrolować pokrycie. Kluczowe techniki:

Podział ekwipolentny (dzielenie danych wejściowych na klasy ekwipotentne — każda klasa jest testowana jednym testem)
Analiza wartości brzegowych (testowanie na granicach zakresów, gdzie najczęściej pojawiają się błędy)
Tabela przyczyn i skutków (formalizacja logik przejść i warunków)
Testowanie parami (Pairwise) (pokrycie wszystkich możliwych par parametrów wejściowych)

Kluczowe cechy:

Racjonalne pokrycie danych wejściowych
Zapobieganie powielaniu przypadków testowych
Dokumentacja procesów

Pytania pułapki.

Czy wystarczy testować tylko na wartościach brzegowych, aby uzyskać pełne pokrycie?

Nie, należy również uwzględnić pozytywne/negatywne scenariusze, weryfikacje logiki biznesowej i przypadki nieekwiwalentne.

W jakich przypadkach lepiej używać pairwise, a nie podziału ekwipolentnego?

Gdy istnieje kilka parametrów o różnych zakresach wartości — pairwise skuteczniej identyfikuje błędy interakcji między parametrami.

Czy testowanie na przestarzałych specyfikacjach jest wystarczające?

Nie, specyfikacje muszą być zaktualizowane, w przeciwnym razie pokrycie testami nie będzie odpowiadało aktualnemu produktowi.

Typowe błędy i antywzorce

Sprawdzanie tylko „na oko” przez interfejs bez stosowania technik
Pomijanie przypadków brzegowych
Powielanie testów bez analizy pokryć

Przykład z życia

Negatywny przypadek

Testując pole „Wiek” wzięto tylko 18, 25, 40 lat, a krytyczne błędy na granicach (0, 100) nie zostały zauważone do czasu wydania.

Zalety:

Szybkie przygotowanie testów

Wady:

Pominięcie ważnych przypadków brzegowych
Krytyczne błędy trafiły do produkcji

Pozytywny przypadek

Użyto metody klas ekwipotentnych i wartości brzegowych: testy pokryły 0, 1, 17, 18, 99, 100, 101, a także typowe wartości w zakresie.