Ekonomia testowania oprogramowania

 


Kiedy pytają nas czy testowanie się opłaca wielu testerów i testerek, z oczywistych względów, nie zaprzecza. Powinniśmy zadać sobie jednak pytanie: ilu z nas potrafi w otwartej dyskusji obronić wartość testowania oprogramowania?

Gdzie kryje się wartość dodana znajdywania defektów?


Jedną z najtrudniejszych rzeczy w testowaniu jest udowodnienie jego opłacalności. Łatwo z wiarą w swoją nieomylność, lecz bez argumentów, powtarzać twierdzenie, że testowanie jest opłacalne. Kiedy jednak stajemy twarzą w twarz z rozmówcą, który niczego nie przyjmuje na słowo (np. klientem) i trzeba udowodnić swoje racje, nierzadko brakuje nam namacalnych i jednoznacznych dowodów potwierdzających nasze przekonania. Jak powiedział Christopher Hitchens (a może przed nim ktoś równie mądry) „Jeśli można coś udowodnić bez dowodu, to można to również bez dowodu obalić".

Więc czy testowanie oprogramowania naprawdę się opłaca? Można śmiało powiedzieć TAK, ale za TAK muszą iść konkretne argumenty.

Na początek kilka stwierdzeń, które da się łatwo udowodnić i które stanowią podstawę do dalszych rozważań.
1) Testowanie oprogramowania ujawnia defekty i awarie
- prosty dowód: tester oprogramowania, który uruchamia aplikację i ma wystarczającą wiedzę jest w stanie znaleźć w aplikacji przynajmniej jeden błąd. 

2) Znajdywanie błędów w specyfikacji jest tańsze niż w oprogramowaniu
- prosty dowód: do testowania specyfikacji potrzeba wydrukowanej kartki, do testowania aplikacji potrzeba komputera z systemem operacyjnym.

3) Naprawiania błędów w specyfikacji jest tańsze niż awarii w oprogramowaniu
- prosty dowód: po znalezieniu błędu w specyfikacji można ją poprawić, po znalezieniu awarii w aplikacji trzeba  ją debagować, aby znaleźć jej przyczynę, a następnie defekt usunąć. Wczesne techniki zaangażowania, takie jak przeglądy, mogą podnosić opłacalność całych projektów informatycznych.

4) Znajdowania awarii po stronie wykonawcy systemu jest tańsze niż ich znajdywania po stronie jego użytkownika, szczególnie jeśli z niepoprawnym działaniem oprogramowania wiążą się kary umowne dla wytwórcy.
- prosty dowód 1: Zapłacenie kary umownej jest kosztem niskiej jakości. Zapłacenie kary będzie stratą, a przeznaczenie tych środków na profesjonalne testowanie zwróci się z nawiązką. Jeśli zgodzimy się co do powyższych to z prostej logiki wynika, że (ERGO): Testowanie systemów z karami umownymi jest opłacalne.
- prosty dowód 2: awarie widoczne po stronie użytkownika zniechęcają go do zakupu kolejnych produktów, nowych wersji, a także obniżają prestiż rynkowy firmy dostarczającej oprogramowanie.

Próbując udowadniać opłacalność testowania należy odwoływać się do liczb i twardych dowodów, gdyż takie podejście znane jest naszym rozmówcom i, co ważniejsze, dla nich priorytetowe. Pierwszym krokiem będą liczby, takie jak ilość defektów, koszt dobre i złej jakości, czy ROI.

Zwrot z inwestycji (Return of Investment) w testowanie oprogramowania opisał, przytaczając liczby, Rex Black w swojej publikacji "What IT Managers Should Know about Testing: How to Analyze the Return on the Testing Investment". Co więcej, dostarczył narzędzie do liczenia wartości zwrotu z inwestycji (linki poniżej). Z jego wyliczeń jednoznacznie wynika, że testowania oprogramowania w każdym przypadku jest zyskowne.

Warto również posłużyć się przykładami ukazującymi konkretne koszty i możliwe oszczędności:
a) "The Economic Impacts of Inadequate Infrastructure for Software Testing." Wydane przez: National Institute of Standards & Technology. Koszty niskiej jakości oprogramowania  wynoszą 59,5 miliarda dolarów rocznie, a możliwe oszczędności związane z lepszym testowaniem to 22,2 miliarda dolarów rocznie.

b) Koszt defektów pojawiający się w wielu publikacjach w tym w książce Steva McConnell, "Code Complete" wydanej przez Microsoft Press.

 

 

Tabela przedstawia koszty poprawiania defektów w zależności od czasu ich znalezienia.


Tabela pokrywa się z regułą: 1:10:100, która wspominana jest w wielu innych źródłach, m.im w badaniach IBM, czy w książce "Effective Methods for Software Testing", napisanej przez Williama E. Perry’ego. Reguła ta mówi, że koszt naprawy defektów w specyfikacji jest jednokrotnością w stosunku do 10-krotnie większego kosztu gdy ten sam defekt trzeba naprawić po testowaniu i 100 krotnie większy jeśli naprawiany jest po wydaniu klientowi.

c) Informacje o awariach. Najlepiej powołać się na najnowsze i najgłośniejsze informacje o awariach i ich kosztach. Kilka przykładów znajdziecie tutaj >>

Powyższe powinny stanowić przekonywującą argumentację nawet dla najzatwardzialszych krytyków testowania.

Artykuł powstał w oparciu o następujące źródła:
http://www.rbcs-us.com/images/documents/What-IT-Managers-Should-Know-about-Testing-ROI.pdf
http://www.rbcs-us.com/images/documents/AdvancedTemplates/Case-Study-Info-Appliance-Test-ROI.xls
http://www.nist.gov/director/planning/upload/report02-3.pdf
http://www.ibm.com/developerworks/rational/library/dec04/bessin/
http://testerzy.pl/artykuly/testowanie-jest-potrzebne-cz-2-powstajacej-ksiazki-zapewnienie-jakosci-w-procesie-wytwarzania-oprogramowania
http://www.davidconsultinggroup.com/blogs/harris/?p=180



 

 

Najbliższe terminy szkoleń

 

28-30 listopada - Katowice

ISTQB Poziom Podstawowy (Foundation Level)


28 listopada-1 grudnia - Wrocław

Zawód Tester


4-6 grudnia - Warszawa

ISTQB Poziom Podstawowy (Foundation Level)

 

Partnerzy

Narzędzia testerskie