Z czasem testowanie ręczne dostosowało się do zwinnych metodologii, takich jak Scrum. Na początku testerzy pracowali „na końcu sprintu”, testując wynik całej pracy. Często prowadziło to do kryzysów i niewystarczającego testowania (historyjka).
Główny problem – brak czasu na testowanie, częste zmiany wymagań oraz zadania, które nie docierają do testerów w trakcie sprintu. Testerzy są pod presją, co obniża jakość (problem).
Rozwiązanie – zintegrować testerów z zespołem od samego początku sprintu: uczestniczyć w spotkaniach, planować przypadki testowe w miarę pojawiania się nowych zadań, wspólnie organizować codzienne stand-upy oraz retrospektywy, a także wspierać zwiększenie przejrzystości statusu artefaktów testowych (rozwiązanie).
Kluczowe cechy:
Czy można rozpocząć testowanie dopiero po zakończeniu wszystkich zadań sprintu?
Nie, tester powinien być zaangażowany od pierwszych dni sprintu i w miarę możliwości testować jeszcze nie do końca ukończoną funkcjonalność.
Czy wszystkie błędy muszą być naprawiane w bieżącym sprincie?
Nie jest to konieczne, krytyczne błędy – tak, błędy niekrytyczne mogą być przeniesione do zewnętrznego backlogu i naprawione w następnym sprincie.
Czy ręczne testowanie jest wymagane przy istniejącej automatyzacji w Scrumie?
Tak, ręczne testowanie jest krytycznie ważne do weryfikacji nowych funkcji i nieformalnych wymagań, a także do testów eksploracyjnych.
Tester nie uczestniczył w planowaniu i nie miał dostępu do nowych historii zadań do końca sprintu. W efekcie testy były pisane w pośpiechu, część błędów przeniesiono na kolejne sprinty.
Plusy:
Minusy:
Tester dołączył do zespołu od pierwszych dni sprintu, uczestniczył w spotkaniach, z wyprzedzeniem widział pojawiające się zadania i planował testy równolegle z rozwojem.
Plusy:
Minusy: