Biznesowa wartość testowania

Testowanie nie stanowi na pierwszy rzut oka żadnej wartości dodanej. Wręcz przeciwnie – może się wydawać, że generuje ono jedynie koszty, bo produkt po przetestowaniu nie zmienia się, a testowanie wymaga przecież często sporych nakładów. Testowanie niesie jednak bardzo dużą wartość. Polega ona na tym, że oszczędzamy na kosztach, które ponieślibyśmy, gdyby produkt nie był ulepszony dzięki informacji zwrotnej od testerów.

Ta nieoczywista, pośrednia w gruncie rzeczy wartość jest przyczyną, dla której wielu menedżerów nie potrafi właściwie docenić testowania. Często nie zwraca się uwagi na jakość i doświadczenie zatrudnianych inżynierów (bo lepsi kosztują więcej), czas przeznaczony na testy jest pierwszy w kolejce do obcięcia w przypadku konieczności skrócenia projektu, inwestycje w środowisko testowe mają zaś najniższy priorytet.

Tymczasem ulepszanie, o którym mowa, może dotyczyć trzech aspektów:

• • tworzonego produktu;
• • decyzji dotyczących produktu;
• • procesów wykorzystywanych zarówno w testowaniu, jak i produkcji oprogramowania.

Ocena kosztów jakości oprogramowania

Kierownik testów powinien znać wartość testowania oraz umieć przekonać zarówno członków zespołu, jak i dyrektorów wyższego szczebla do tego, że inwestycja w testowanie jest opłacalna. Może temu służyć tzw. business case, oparty na metodzie kosztu jakości. Zysk z testowania jest możliwy dzięki temu, że koszt usuwania defektów rośnie z czasem. Zysk ten wystąpi, jeśli koszt wykrycia usterek w fazach wcześniejszych nie przekroczy ewentualnych strat spowodowanych odkryciem i koniecznością naprawy defektu w fazach późniejszych bądź u klienta.

Koszt jakości (Cost of Quality / Cost of Software Quality) jest techniką opisaną przez J.M. Jurana (Quality Control Handbook), która pozwala ilościowo wyrazić koszt złej jakości produktu. Dlatego metodę tę często nazywa się kosztem złej jakości. Najprościej koszt ten określić za pomocą czasu lub wysiłku, ale najczęściej ujmuje się go w wartości pieniężnej. Koszt jakości to całkowity koszt związany z jakością, na który składają się koszty działań prewencyjnych, wykrycia wewnętrznych i zewnętrznych awarii.

Według H. Krasnera (Using the Cost of Quality Approach for Software), „koszt jakości oprogramowania to technika księgowa użyteczna w rozumieniu ekonomicznych kompromisów związanych z dostarczaniem oprogramowania wysokiej jakości”. CoQ (Cost of Quality) wyróżnia dwie główne kategorie kosztów: związanych z kontrolą oraz z awariami.

Generalnie im wyższe koszty kontroli, tym niższe koszty awarii, jednak niestety działa tu tzw. prawo malejących przychodów (law of diminishing returns), to znaczy coraz większe nakłady na kontrolę dają coraz mniejsze zyski z zapobiegania awariom. Dlatego należy znaleźć optymalny punkt – złoty środek – między wielkością kosztów kontroli, jakie decydujemy się ponieść, a zyskami wynikającymi z zapobiegania awariom. Oto cztery kategorie kosztów w CoQ:

Dotyczą wszelkich czynności wykonywanych w celu zapobiegania powstawaniu defektów w produkcie. Przykładowe koszty prewencji dotyczą: przeprowadzania szkoleń, planowania jakości, oceny dostawcy, analiz przyczyny źródłowej, oceny zdolności procesu, ulepszania procesu.

Są związane z analizowaniem produktów i usług, aby identyfikować znajdujące się w nich defekty. Przykładowe koszty wykrycia dotyczą: przeprowadzania przeglądów i inspekcji, testowania, audytów produktów, procesów i serwisów, pomiaru jakości produktu oraz innych czynności związanych z weryfikacją i walidacją oprogramowania.

Ponoszone w związku z usuwaniem defektów wykrytych podczas procesu wytwórczego, przed przekazaniem oprogramowania do klienta. Przykładowe koszty awarii wewnętrznej dotyczą: wytworzenia oprogramowania, które nie będzie używane, procesu zarządzania incydentami, debugowania, poprawiania defektu, przebudowy oprogramowania, przeprowadzenia ponownych przeglądów po poprawie, testów regresji oraz testów potwierdzających.

Ponoszone w związku z usuwaniem błędów polowych, tzn. wykrytych po przekazaniu oprogramowania do klienta. Koszty te generalnie są związane z tymi samymi czynnościami, co w przypadku kosztów awarii wewnętrznej, a ponadto dotyczyć mogą: gwarancji, SLA (Service Level Agreement), kar umownych, postępowań sądowych, strat poniesionych przez klienta, wydawania poprawek do oprogramowania, wsparcia technicznego, utraty reputacji lub wizerunku, niezadowolenia klienta, strat spowodowanych zmniejszeniem sprzedaży oraz utraty udziału w rynku.

Rozważmy następujący przykład: koszt całego projektu wynosi 100 000 USD, z czego 10 000 USD to koszty szkolenia testerów, 35 000 USD to koszty testowania i inspekcji, 12 000 USD – koszty usuwania defektów podczas produkcji oprogramowania, a 6000 USD – koszty usunięcia kilku awarii wykrytych przez klienta oraz wprowadzenia poprawek do aplikacji. Całkowity koszt jakości wynosi więc 10 000 USD + 35 000 USD + 12 000 USD + 6 000 USD = 61 000 USD, co stanowi 61% całkowitych kosztów projektu. Gdybyśmy zwiększyli koszty testowania, prawdopodobnie znaleźlibyśmy więcej błędów, przez co klient odkryłby mniej awarii i być może całkowity koszt byłby mniejszy.

Im wyższa jakość, tym większy koszt jej zapewnienia, ale jednocześnie – tym mniejszy koszt awarii, ze względu na mniejszą liczbę pozostałych błędów. Klasyczne podejście do analizy CoQ (górny wykres na rysunku) zakłada, że istnieje teoretyczny, optymalny poziom kosztów minimalizujący całościowy koszt jakości. W praktyce jednak punkt ten bardzo trudno wyznaczyć, ponieważ wiele kosztów zewnętrznej awarii, takich jak niezadowolenie klienta czy utrata wizerunku, jest trudnych do zmierzenia. Współczesne podejście (dolna część rysunku) jest oparte na empirycznych danych, które zdają się potwierdzać tezę, że ulepszanie procesu oraz techniki zapobiegania defektom zwiększają efektywność kosztów. Wyniki te sugerują, że można uzyskać niemal optymalny poziom jakości dla skończonego kosztu (J. Campanella, Principles of Quality Costs: Principles, Implementation and Use).

Na rysunku pokazano, że koszty wewnętrznej i zewnętrznej awarii można zredukować niemal do zera, przez co całkowity koszt jakości będzie praktycznie równy kosztowi prewencji i wykrywania defektów. H. Krasner opisuje wyniki trwającego 3 lata badania 15 projektów w Raytheon Electronic Systems, mającego na celu zbadać związek między kosztem jakości a poziomem dojrzałości procesu CMM2. Na najniższym poziomie dojrzałości (CMM 1) koszt jakości stanowił 55–67% całkowitych kosztów projektu. Gdy organizacja osiągnęła poziom trzeci (CMM 3), udział kosztów jakości spadł do 40%. Pod koniec trzyletniego okresu udział ten spadł jeszcze bardziej, do ok. 15% całkowitych kosztów.

Dane CoQ powinny być zbierane dla każdego projektu. Dzięki temu mogą być potem porównane z danymi historycznymi, wzorcowymi lub pochodzącymi od konkurencji. Można również przedstawić ich zmianę w czasie. Pozwala to: zidentyfikować nieefektywne obszary, które można będzie poprawić przez ulepszanie procesu tak, aby zredukować całkowity koszt wytwarzania; ocenić wpływ ulepszenia procesu (np. czy narzucenie większego formalizmu w postaci rygorystycznych inspekcji formalnych przyczynia się do redukcji kosztów jakości?); dostarczyć informację dla przyszłych, opartych na ryzyku kompromisów między kosztami a wymaganiami integralności produktu.

Wartość ekonomiczna oprogramowania i problemy z nią związane

Pojęcie „wartości ekonomicznej” oprogramowania, tak jak pojęcie jakości, jest niejasne i to z tych samych powodów. Każdy interesariusz projektu ma inne oczekiwania co do oprogramowania, zatem patrzy na wartość oprogramowania z innego punktu widzenia. Dla dostawcy najważniejszy będzie zysk, uzyskanie przewagi konkurencyjnej, czas wprowadzenia produktu na rynek (time to market) czy zwrot z inwestycji ROI (Return of Investment). Dla nabywcy wartość oprogramowania może oznaczać obniżenie kosztów operacyjnych organizacji, zwiększenie sprzedaży czy osiągnięcie większych zysków z powodu wykorzystania innowacyjnego modelu biznesowego przy użyciu oprogramowania.

Gdy popatrzymy na oprogramowanie z punktu widzenia procesu jego produkcji, z jednej strony mamy nakłady ponoszone w związku z tworzeniem tego produktu, z drugiej zaś – poziom jego jakości. Problem polega na tym, aby minimalizować koszty przy maksymalizacji jakości. Skoro oprogramowanie jest rezultatem procesu produkcyjnego, projekty informatyczne powinniśmy analizować za pomocą klasycznych metod ekonomiki produkcji. Niestety, nawet w obecnych czasach wciąż zbyt wiele projektów kończy się niepowodzeniem. Jednym z powodów jest błędne rozumienie ekonomiki produkcji w odniesieniu do oprogramowania. Trzy główne przyczyny wypaczające rozumienie ekonomiki produkcji to:

Estymację kosztu często prowadzi się na podstawie danych historycznych, ale dane te równie często są niekompletne i nie zawierają wszystkich poniesionych kosztów. Dlatego szacunki dla bieżącego projektu zwykle są alarmujące, bo pokazują, że w porównaniu z projektami historycznymi wydajemy dużo więcej pieniędzy, co wcale nie musi być prawdą. Często nie zbiera się wszystkich danych historycznych, a jedynie te dotyczące wybranych wycinków czy aspektów projektu. Aby uniknąć tworzenia fałszywych analiz, zwykle przeprowadza się wywiady z członkami zespołów projektowych. Na strukturę podziału prac bieżącego projektu odwzorowuje się dane historyczne podobnego projektu. Dla każdego zadania w tej strukturze, którego odpowiednika nie ma w danych historycznych, członkowie zespołu muszą określić, czy zadanie to w projekcie historycznym wystąpiło, czy nie. Jeśli tak, to proszeni są o ocenę jego kosztów.

Metryka LOC narusza podstawowe zasady ekonomiki wytwarzania, ponieważ każdy język programowania ma inną „efektywność”: to, co możemy napisać w 4 liniach kodu języka typu C# czy Java, może zająć 30 linii w Asemblerze. Wobec tego nie można porównywać produktywności wyrażanej w LOC na jednostkę czasu dla programów pisanych w różnych językach programowania. Oczywiście można stosować tablice przeliczników między językami, jednak takie działanie zawsze jest obarczone dużym błędem. Innym problemem związanym z LOC jest to, że różne osoby rozumieją różnie pojęcie linii kodu. Komentarze, nagłówki funkcji, fizyczne linie w pliku z kodem źródłowym, logiczne instrukcje kodu, klamry wyznaczające bloki instrukcji – to tylko kilka przykładów rodzajów informacji, które mogą, ale  nie muszą być zliczane jako linie kodu. Zamiast LOC lepiej jest wykorzystywać punkty funkcyjne, które nie tylko są niezależne od przyjętego języka oprogramowania, ale umożliwiają również wczesną estymację praco- i kosztochłonności, ponieważ można je obliczyć na podstawie dokumentacji projektowej, a nie tylko z gotowego kodu. Punkty funkcyjne spełniają podstawowe założenia ekonomiki produkcji.

Jest to jedna z najstarszych miar jakości oprogramowania, mierząca godziny związane z naprawą defektów podzielone przez liczbę znalezionych usterek, przemnożone przez koszt godziny pracy. Chociaż poprawna z matematycznego punktu widzenia, metryka ta ma zasadnicze, bardzo niebezpieczne wady. Ze względu na koszty stałe (np. koszt testowania i inspekcji), koszt usunięcia defektu zawsze będzie niższy dla projektów o większej liczbie błędów. Wraz ze wzrostem jakości liczba wykrytych defektów maleje, a więc koszt usunięcia jednego błędu rośnie – w granicy aż do nieskończoności, gdy liczba defektów osiągnie zerową wartość. Druga wada tej metryki polega na nieuwzględnieniu zysków, jakie osiągamy z wzrostu jakości. Lepsza jakość może polegać na tym, że pewne prace wykonujemy szybciej i lepiej. Jednak zyski z oszczędności na czasie nie są uwzględniane podczas obliczania kosztu usunięcia defektu. Większość błędów znajdowanych jest w początkowych fazach projektu, dlatego obserwujemy sztuczny wzrost metryki kosztu usunięcia defektu w czasie.

Dług technologiczny w kontekście testowania

Dług technologiczny to metaforyczne pojęcie oznaczające koszty, jakie zaciągamy przez niestaranne, niedbałe tworzenie systemu. Źle zaprojektowany, stworzony „na kolanie” kod może działać dziś, ale za pewien czas – gdy okaże się, że musimy go modyfikować, utrzymywać i poprawiać – koszty tych czynności będą o wiele większe niż te, które ponieślibyśmy na początku, inwestując w lepszą jakość kodu. Jedna z bardziej oczywistych form zaciągania długu technologicznego jest związana z brakiem testowania lub niedbałym jego przeprowadzeniem. Mechanizm ten działa podobnie jak w świecie finansów: gdy spłacamy pożyczkę, poza pożyczoną kwotą musimy spłacić jeszcze odsetki. Każda niedbałość, każdy brak pokrycia testami ryzyka, funkcjonalności czy fragmentu kodu działa jak odsetki od długu. Im więcej odsetek i dłuższy czas ich zaciągania, tym większa kwota długu do spłacenia. Rezygnacja z czynności projakościowych, takich jak weryfikacja, walidacja, testowanie czy inspekcje, jest kusząca, gdyż koszty przeprowadzania tych czynności mogą być duże.

Nie zawsze jednak należy dążyć do zerowej wartości długu technologicznego za wszelką cenę. Przykładem możliwego, a nawet pożądanego długu technologicznego może być projekt tworzony w organizacji typu start-up. Z jednej strony, projekty takie zwykle są innowacyjne i nie do końca wiadomo, czy odniosą komercyjny sukces. Z drugiej zaś firma, aby przetrwać, musi generować zyski ze sprzedaży. Często w tego typu przedsięwzięciach nie warto więc inwestować olbrzymich kwot w zapewnianie jakości, lecz dążyć do jak najszybszego wydania produktu na rynek, aby uprzedzić konkurencję, zweryfikować realne zapotrzebowanie na dany produkt czy usługę i zacząć zarabiać. Dopiero po osiągnięciu sukcesu można spłacić zaciągnięty dług technologiczny. Dokładne obliczenie tego, ile długu zaciągamy przez zaniechanie określonych czynności lub wykonanie ich z mniejszą starannością, jest w praktyce bardzo trudne. Zwykle wymaga posiadania danych historycznych oraz umiejętności modelowania matematyczno-statystycznego.

Jest to fragment książki „Testowanie i jakość oprogramowania. Modele, techniki, narzędzia” Adama Romana, wydanej przez Wydawnictwa Naukowe PWN, 2015. Magazyn ITwiz został jej partnerem medialnym.