Redakcja
Poniższa publikacja jest częścią powstającej właśnie, nowej książki Radosława Smilgin o roboczej nazwie "Zapewnienie jakości w procesie wytwarzania oprogramowania. Proces testowy."
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 błędy znalezione we wczesnych fazach zapobiegają błędom w późnych fazach. Zgodnie z badaniami amerykańskich naukowców 75% 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% błędó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:
– 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?
