Błędy – znajdź je zanim zaczną Cię kosztować

Skąd się biorą błędy w oprogramowaniu?

Błędy do oprogramowania wkradają się jeszcze zanim powstanie pierwsza linijka kodu. Ba! One są już wtedy, kiedy rodzi się pomysł – kiedy Ty jeszcze do końca nie wiesz czym będzie produkt końcowy, a one już wiedzą gdzie się usadowić. Jak to robią? Są sprytne. Dyskretnie przemycają się pomiędzy wierszami specyfikacji. Zanim dotrą do programisty, rozmnożą się na etapie projektowania. To bardzo płodna dla błędów faza. Na etapie implementacji błędy zaczynają zbierać swoje żniwa, ale sieją też kolejne ziarna. Zanim aplikacja trafi do testów, występują już tak licznie, że nie widzisz ich końca. Najgorzej, jeśli w takim gronie zdecydują się wpaść do klienta…

Peer review, czyli lepsza jakość oprogramowania przed etapem testów

Kilka prawd na temat testów:

• Około 40-50% nakładu prac w oprogramowaniu pochłaniają przeróbki, których można było uniknąć
• Około 80% przeróbek, których można było uniknąć wynika z 20% błędów w aplikacji
• 80% wad generuje 20% funkcji
• Peer review pozwala wychwycić od 30 do 90% błędów (średnio 60%)

/Źródło: Software Defect Reduction Top 10 List, Software Management Jan 2001, Barry Boehm, Victor R. Basil/

Pomimo, że przedstawione powyżej dane pochodzą z 2001 roku, uważam je za wciąż aktualne. Jakkolwiek z liczbami można polemizować (nie znalazłam bardziej aktualnych danych), fakty te są czymś na kształt praw Edwarda Murphy’ego – opisują sytuacje pozornie nieprawdopodobne, jednak często występujące. Dają pewne wyobrażenie o skali.

Dekalog PM’a i testera

Testerzy stanowią część zespołu projektowego, choć często do projektu włączani są zbyt późno. Nie znają wymagań aplikacji, często nawet nie znają zespołu wdrożeniowego. Pomijani na etapie implementacji, nagle muszą przetestować nowe oprogramowanie. W efekcie piętrzą się pytania, jeśli nie zostaną zadane, testy wypadną słabo. Jak temu zapobiec? Zastosuj poniższe przykazania.