Odpowiedź.

Testowanie ręczne na etapie utrzymania to testowanie już istniejącego i działającego systemu przy poprawkach, naprawach błędów lub integracji nowych komponentów.

Historia pytania

Wcześniej utrzymanie było realizowane na zasadzie resztek, często testowaniu podlegały tylko nowe funkcje. Z czasem stało się jasne, że jakiekolwiek ingerencje mogą wpłynąć na już działające scenariusze.

Problem

Typowa sytuacja:

Wprowadzane są lokalne zmiany, ale ich wpływ na stary funkcjonalność często nie docenia się
Regresja występuje w, wydawałoby się, niepowiązanych modułach
Brak systemowego podejścia zwiększa ryzyko nagłych "upadków" w produkcji

Rozwiązanie

Efektywna organizacja maintenance testing wymaga:

Wyodrębnienia i stałego aktualizowania "zbioru kluczowych scenariuszy", które są weryfikowane przy każdej poprawce
Wykorzystania checklist i map regresyjnych
Włączenia do pracy exploratory testing w celu poszukiwania nieoczekiwanych skutków zmian

Kluczowe cechy:

Szybkie reagowanie na niewielkie zmiany z minimalnym wycofaniem
Skupienie na rzeczywistych scenariuszach użytkowników, które mogą być pośrednio dotknięte
Elastyczność w wyborze metodologii: od checklist do kreatywnego testowania eksploracyjnego

Pytania z podstępem.

Czy trzeba testować tylko te moduły, które zostały zmienione?

Nie, należy również obowiązkowo testować powiązane części systemu, aby nie przeoczyć skutków ubocznych zmian.

Czy wystarczy pełne testowanie regresyjne po każdej naprawie?

Nie, często wystarczy sprawdzić kluczowe (krytyczne) ścieżki, a pełna regresja odbywa się tylko przed wydaniem lub przy znaczących zmianach.

Czy można całkowicie zrezygnować z exploratory testing na etapie utrzymania?

Nie, testowanie eksploracyjne pozwala znaleźć nietrywialne błędy poza zasięgiem scenariuszy i powinno towarzyszyć fazie utrzymania.

Typowe błędy i antywzorce

Lekceważenie powiązanych modułów: testują tylko "patczone" miejsce
Brak aktualnego zbioru scenariuszy regresyjnych
Ignorowanie rozumienia architektury, spowalnia ustalanie obszarów ryzyka

Przykład z życia

Negatywny przypadek

Po naprawie błędu w profilu użytkownika testowany jest tylko profil, ale nie sprawdzana jest autoryzacja i wyświetlanie profilu na innych stronach. W wyniku pojawia się błąd: na stronie głównej profil się nie aktualizuje.

Zalety:

Szybkie zakończenie testowania konkretnego zadania

Wady:

Przeoczenie błędów w powiązanych sekcjach
Spadek zaufania do QA i produktu

Pozytywny przypadek

Naprawiony błąd w profilu testowany jest zarówno osobno, jak i kompleksowo: sprawdzany jest profil wszędzie tam, gdzie jest używany. Używana jest checklist kluczowych scenariuszy.