Ekonomia testowania oprogramowania

Ekonomia testowania oprogramowania
Kiedy pytają nas, czy testowanie się opłaca wiele testerek i testerów, z oczywistych względów, potwierdza. 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 tezy, 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. Naprawianie 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. Znajdywanie awarii po stronie wykonawcy systemu jest tańsze niż ich znajdywanie po stronie jego użytkownika.
    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 lub nowszych 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, często biznesowo zorientowanym rozmówcom i, co ważniejsze, jest dla nich priorytetowe. Najważniejszym argumentem będą liczby, takie jak liczba defektów, koszt dobrej 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.

ekonomia-testowania-1.jpg

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ć przekonującą argumentację nawet dla najzatwardzialszych krytyków testowania.

[Aktualizacja 13.01.2022] Artykuł pierwotnie pojawił sie w 27.12.2011.

 

Źródła:
http://www.rbcs-us.com/images/documents/What-IT-Managers-Should-Know-about-Testing-ROI.pdf
http://www.nist.gov/director/planning/upload/report02-3.pdf
https://rbcs-us.com/site/assets/files/1386/case-study-info-appliance-test-roi.xls
https://testerzy.pl/artykuly/definicja-testowania-oprogramowania-cz-2

To powinno Cię zainteresować