O wyższości wczesnego testowania nad późnym

Testerzy powinni z zasady negować zapisy typu „wczesne”, „późne” itp. jako że są to zapisy nieprecyzyjne, więc w konsekwencji również nieweryfikowalne. W publikacji nie odnosimy się jednak do konkretnych założeń organizacji czy projektu i musimy (niestety) utrzymywać wysoki poziom ogólności. Przy bardzo ogólnych założeniach precyzyjne określenie czasu zaangażowania nie jest możliwe. Zależeć będzie ono od wielu czynników.

Jak wcześnie możemy zacząć testować? Możemy testować, zanim jeszcze powstanie oprogramowanie. Co więcej, możemy rozpocząć testowanie, zanim powstanie dokumentacja oprogramowania. Możemy testować już samą koncepcję i stopień możliwości jej realizacji. Nie zawsze uda nam się zaangażować wystarczająco wcześnie, ale musimy pamiętać: „lepiej późno niż wcale”. Szczególnie że możemy również testować każdy półprodukt lub produkt dodatkowy, który stoi na drodze od koncepcji do końcowego oprogramowania. Służą do tego niezliczone techniki, metody i narzędzia. Zakładamy, że defekty znalezione we wczesnych fazach zapobiegają defektom w późnych fazach. Zgodnie z badaniami amerykańskich naukowców z SEI, 80% wszystkich defektów to wynik złej specyfikacji.

Dzięki niezliczonym doświadczeniom wiemy również, że testowanie specyfikacji jest w stanie wyeliminować do 70% defektów. Szybka kalkulacja pomaga nam oszacować, że wczesne zaangażowanie to eliminacja ponad 50% defektów w projekcie. Czemu więc, odwołując się do własnych doświadczeń, nie angażujemy się wcześniej? Może dlatego, że testowanie dla wielu to tylko i wyłącznie koszt, a nie korzyść?

Możemy spróbować przeanalizować wymyślone historie, których podobieństwo do realnych zdarzeń i faktów jest przypadkowe, a które mogą nam pomóc zrozumieć:

• kierownik projektu nie wierzy w testowanie oprogramowania, dlatego budżet na testerów jest ułamkową częścią środków na programistów, a wydłużenie czasu na wytwarzanie oprogramowania powoduje skrócenie czasu na testowanie
• klient uważa, że programiści są w stanie zadbać o jakość bez pomocy testerów, dlatego nie uwzględnia się testowania w budżecie projektu. Klient nie zgodzi się na płacenie za testowanie, poprosi raczej o takie pisanie kodu, żeby nie trzeba było go testować
• przecież testowanie nie musi być wykonywane przez testerów. Wielu spośród członków projektu przedkłada pracę twórczą nad odtwórczą (za jaką uważa się testy), więc testowanie zostawimy końcowemu użytkownikowi
• sami testerzy nie do końca rozumieją sens czytania dokumentów we wczesnych fazach - przecież do końca projektu zmienią się one wielokrotnie
• we wczesnych fazach projektu nie widzi się defektów, więc trudno uzasadnić potrzebę testowania. Przecież nie ma oprogramowania, więc co może nie działać?

Bez względu na to co myślicie, jeśli jeszcze nie wierzycie we wczesne zaangażowanie, musicie spróbować się przekonać. Spójrzcie na inne obszary naszego życia, aby poszukać inspiracji. Ustawy, zanim zostaną uchwalone, są poddawane konsultacjom społecznym (testy beta). Przed wybudowaniem mostu oblicza się jego siłę nośną i możliwe obciążenia, jakie pojawią się na poszczególnych elementach nośnych (analiza statyczna). Środki chemiczne przed premierą rynkową sprawdza się na zwierzętach (testy laboratoryjne).

Skoro wczesne testowanie sprawdza się wszędzie dookoła, to dlaczego nie miałoby pomagać w produkcji oprogramowania?

Oryginalna publikacja pochodziła z 01/02/2012 i została zaktualizowana.