Błędy oprogramowania – 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 przewijają 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…

Poznaj trasę, którą poruszają się błędy

• Specyfikacji wymagań (analiza) – tu błędy zaczynają swoją podróż; pojawiają się w postaci sprzecznych, nieprecyzyjnych wymagań (kolizja wymagań), problemów z ich interpretacją, niekompletności. Jeśli ich nie złapiesz, pójdą dalej.
• Projekt funkcjonalny (projektowanie) – wymagania zebrane w etapie analizy przekładane są na konkretne rozwiązania, które później będą implementowane. Jeśli znajdzie się błąd w projekcie, prawdopodobnie powędruje on również do oprogramowania.
• Programista (implementacja) – zarówno łatwa do naprawienia literówka w kodzie, jak i znacznie trudniejszy do znalezienia i naprawienia błąd logiczny, ponadto niezrozumienie lub własna interpretacja wymagań lub brak odpowiednich kompetencji – warunki rozrodcze błędów. Ups… jest ich coraz więcej.
• Administrator – jego błąd (zarówno na etapie implementacji, testów, jak i wdrożenia) dotyczy zwłaszcza wymagań pozafunkcjonalnych związanych z bezpieczeństwem czy wydajnością oraz odpowiednią konfiguracją aplikacji. Jeśli administrator się pomyli, błąd się cieszy.
• Tester (testy wewnętrzne) – nie generują błędów, jednak pozwalają je ujawnić – a mam cię!; nieznalezienie i niepoprawienie błędów na tym etapie, spowoduje, że będą one przechodziły dalej. Nie łudź się – one wcale nie są zmęczone swoją wędrówką, a szczyt jest bliski.
• Klient (testy akceptacyjne klienta) – tu już robi się gorąco, ale Tobie; błędy, jeśli są, mają się dobrze. Zgłoszone przez klienta świadczą o tym, że nie zostały znalezione lub poprawione w trakcie trwania testów wewnętrznych, jak również poprawki wykonane w ramach testów wewnętrznych mogły wygenerować nowe błędy. O tak, one lubią się rozmnażać.
• Użytkownicy końcowi (wdrożenie) – nie generują błędów, ale je znajdują. Tu błędy już wcale nie zamierzają się ukrywać, triumfują –  kolejny szczyt zdobyty!

Jaki z tego wniosek? Błędy są sprytniejsze od Ciebie. No i wytrwałe. Jeśli nie wykryjesz ich już na starcie, coraz trudniej będzie Ci je dogonić. Oprogramowania nie da się przetestować całkowicie, podobnie jak nie uda się przejść przez projekt bezbłędnie, jednak pamiętaj, że im później dopadniesz błąd, tym większy jest koszt jego usunięcia. Poniższy wykres przedstawia jak ten koszt rośnie w czasie.

Znalezienie i naprawienie błędu oprogramowania po jego wdrożeniu jest często 100 razy droższe niż znalezienie i naprawienie go podczas analizy wymagań i fazy projektowania. /Źródło: Software Defect Reduction Top 10 List, Software Management Jan 2001, Barry Boehm, Victor R. Basil/

 Jak obniżyć koszt naprawy błędów?

1. Zacznij od analizy – znalezienie błędów na tym etapie pozwoli Ci sporo zaoszczędzić na etapie projektowania i implementacji. Upewnij się, że dokumentacja jest jednoznaczna, kompletna, spójna i zrozumiała.
2. Zweryfikuj etap projektowania – to ostatni moment, aby ograniczyć ilość błędów, które trafią do implementacji. Poproś o weryfikację zespół programistów, uzyskaj akceptację klienta.
3. Testuj oprogramowanie we wczesnych stadiach jego rozwoju. Testować należy jak najwcześniej, ponieważ często błędy mogą występować już na poziomie specyfikacji i projektu; ich wczesne wykrycie zapobiegnie generowaniu części błędów w dalszych etapach prac.
4. Przeprowadzaj testy na każdym etapie tworzenia oprogramowania. Wprowadź testy peer review, dzięki którym dostarczysz do testów wewnętrznych aplikację lepszej jakości.
5. Zastanów się nad wdrożeniem testów sekwencyjnych (model V), które polegają na prowadzeniu testów na każdym etapie trwania projektu, przy czym poziomy testowania należy dostosować do etapu projektu.
6. Nie pozwól, aby klient stał się testerem. Nie przekazuj aplikacji do odbioru, kiedy jest jeszcze na to za wcześnie. Opóźnienie jest przyjemniejsze w skutkach niż naszpikowana błędami i nieodebrana aplikacja.
7. Wdrożenie nie oznacza końca prac. Teraz zaczyna się prawdziwa weryfikacja. Życzę Ci, aby na tym etapie błędy były tylko wspomnieniem :-)