Problem:
- Niewystarczająco zdefiniowane wymagania – jeśli wymagania są niejasne, niekompletne, zbyt ogólne lub nietestowalne, na pewno pojawią się problemy.
- Nierealistyczny time plan projektu – zbyt wiele pracy zaplanowanej w zbyt krótkich przedziałach czasu.
- Niewystarczająca ilość testów – nikt nie wie jakiej jakości jest system, dopóki klient nie zacznie zgłaszać problemów.
- Zmiany po zatwierdzeniu specyfikacji – mała z punktu widzenia klienta zmiana, może oznaczać zmianę koncepcji działania całego systemu. To oznacza dodatkową pracę, koszty oraz konieczność przeplanowania zadań.
- Brak komunikacji – jeśli programiści nie wiedzą czego oczekuje klient (np. z powodu braku wymagań) lub klient zmienia wymagania w trakcie trwania projektu, czas zaplanowany na kodowanie, testowanie jest przeznaczany na wyjaśnianie.
Rozwiązanie:
- Zdefiniowane wymagania – jasne, kompletne, szczegółowe, spójne logicznie oraz testowalne wymagania, które zostały zaakceptowane przez wszystkie strony. W projektach prowadzonych wg metodyk lekkich niezbędna jest ciągła koordynacja wymagań z udziałem klienta.
- Realistyczne estymacje czasu – zapewnienie odpowiedniej ilości czasu na planowanie testów, tworzenie przypadków testowych, testowanie, poprawę i retesty błędów, zmiany (change requests), raporty i dokumentację - zarówno tworzenie jak i czytanie. Zespół powinien mieć szansę na ukończenie projektu bez efektu wypalenia się.
- Testowanie w odpowiednim momencie – rozpoczęcie testów na wczesnym etapie SDLC, retesty po poprawie błędów, testy regresywne po zmianach w bieżącej wersji systemu.
- Trzymanie się zdefiniowanych wymagań – kiedy ruszy kodowanie, pojawią się zmiany, które zazwyczaj oznaczają dodatkową pracę w ustalonym na początku zakresie godzin. Dobrą praktyką jest komunikowanie konsekwencji takich zmian i jeśli są one niezbędne - reestymacja czasu na testy.
- Komunikacja – tam, gdzie ma to sens, pomagają przeglądy i inspekcje. Narzędzia do pracy grupowej: email, repozytorium błędów i dokumentacji. Wersjonowanie. Aktualne wersje dokumentów projektowych. Oraz najważniejsze – bezpośredni kontakt członków zespołu.
Powyższy artykuł jest przedrukiem z wygasłego bloga testerskiego testowanie.net.