testowanie na podstawie ryzyka

Bogdan Bereza-Jarociński
TESTOWANIE NA PODSTAWIE RYZYKA (RISK-BASED
TESTING) JAKO SPOSÓB ZARZĄDZANIA
ZAGROŻENIAMI W PROJEKCIE INFORMATYCZNYM
© NewQuality
Wstęp
Zagrożenia dla projektu (risks) to czynniki, co do których nie wiemy z góry, czy
wystąpią, mogące spowodować opóźnienia, przekroczenie budżetu lub skonstruowanie
wadliwego, niezgodnego ze specyfikacją produktu.
Testowanie jest główną czynnością wykonywaną w ramach zarządzania
zagrożeniami. Bez testowania zarządzanie zagrożeniami pozbawione jest oparcia w
rzeczywistości.
Podstawową metodą doboru testów jest tzw. testowanie na podstawie ryzyka,
którego opis przedstawiamy w niniejszej pracy.
Zarządzanie zagrożeniami
Zagrożenia dla projektu (risks) to czynniki, co do których nie wiemy z góry, czy
wystąpią, mogące spowodować opóźnienia, przekroczenie budżetu lub skonstruowanie
wadliwego, niezgodnego ze specyfikacją produktu.
Z zagrożeniami, które nieodłącznie towarzyszą wszelkim ludzkim
przedsięwzięciom, można postępować trojako.
Po pierwsze, można ich unikać (risk avoidance) nie podejmując się zadań
ryzykownych, nowatorskich, unikając wyzwań. Czynności rutynowe, dobrze znane, z
reguły obciążone są znacznie niższym ryzykiem niż nieznane, oparte na nowych
technologiach, dążące do osiągnięcia celów, których wcześniej osiągnąć się nie dało.
Takie podejście może się opłacać tylko na krótką metę, dopóki śmielsza konkurencja nie
wyprze z rynku aktora unikającego wszelkich nowości i wyzwań.
Po drugie, zagrożenia można lekceważyć (ignoring risks), przymykać na nie oczy
i z desperacką odwagą rzucać się w najbardziej ryzykowne przedsięwzięcia. Wydaje się
niekiedy, że niektórych firmach informatycznych występuje swoista kultura premiująca
takie podejście. Kierownik projektu, który lekceważył sygnały ostrzegawcze i
przedstawił nierealny harmonogram, nawet po znacznym opóźnieniu projektu będzie
chwalony jako śmiałek i usprawiedliwiany tym, że każdemu może się nie udać natomiast
kierownik racjonalnie oceniający trudności i zagrożenia zostanie napiętnowany jako
przesadny pesymista, wręcz nielojalny wobec firmy. Setki popularnych w przemyśle
informatycznym anegdot, rozpowszechniona nieufność czy zgoła cynizm wobec
wszelkich obietnic dotyczących obiecywanych terminów i celów, jest dobitnym
symptomem tej kultury wzajemnego okłamywania się i obowiązkowego, fałszywego
optymizmu.
Wreszcie zagrożeniami można zarządzać (risk management), to znaczy
identyfikować je, oceniać ich wielkość i tę wiedzę wykorzystywać do nadzorowania
projektu. Harmonogram projektu, w którym mądrze zarządza się zagrożeniami, nie
będzie miał wprawdzie daty zakończenia (nierealnie optymistycznej) wykutej złotymi
literami, tylko ocenę prawdopodobieństwa osiągnięcia celu projektu w określonym
terminie, ale za to będzie oparty na prawdziwych przesłankach i umożliwiający
autentyczne zarządzanie projektem, a nie tylko jego namiastkę.
Zagrożenia dzieli się niekiedy na dwie klasy: produktowe i projektowe.
Zagrożenia projektowe (project risks) to takie, które mogą spowodować
opóźnienie lub przekroczenie budżetu projektu, ale bezpośrednio nie wpływają na jakość
końcowego produktu. Przykładowo, jeśli okaże się, że wydajność pracy programistów
będzie niższa od spodziewanej, zaplanowany harmonogram zostanie przekroczony.
Zagrożenia produktowe (product risks) oznaczają ryzyko, że produkt nie będzie
spełniał specyfikacji, na przykład że nie będzie miał pełnej funkcjonalności lub że
niektóre funkcje będą działać wadliwie, lub że nie będą spełnione inne wymagania, takie
jak osiągi, przepustowość czy łatwość obsługi.
W praktyce taka klasyfikacja nie jest specjalnie użyteczna: konkretne wydarzenia
lub stany będące zagrożeniami z reguły przekładają się zarówno na ryzyko projektowe
jak i produktowe. Przykładowo, zła organizacja i spowodowana ją słabsza od zakłada
wydajność pracy w projekcie spowoduje opóźnienie, które być może zostanie
zlikwidowane kosztem funkcjonalności czy jakości produktu. Podobnie wady produktu,
spowodowane nieprzewidzianymi trudnościami technicznymi, mogą pociągnąć za sobą
opóźnienie dostawy końcowej lub konieczność przekroczenia budżetu.
Ocena zagrożeń
Pierwszym krokiem w zarządzaniu zagrożeniami jest ich identyfikacja (risk
identification). Często stosowaną metodą identyfikacji jest tzw. burza mózgów, czyli
zbiorowe generowanie wielu pomysłów, często niekonwencjonalnych, bez próby ich
analizy czy krytyki. Zaletą tego sposobu podejścia jest możność oderwania się od
utartych schematów i stereotypów. W praktyce doświadczenie poucza, że mimo
stosowania burzy mózgów wiele istotnych zagrożeń pozostaje niezidentyfikowanych,
zwłaszcza gdy dotyczą obszarów tabu w danym przedsiębiorstwie czy organizacji.
Przykłady takich tematów to brak środków finansowych na ukończenie projektu,
zbiorowe odejście grupy kluczowych pracowników (np. w celu założenia
konkurencyjnej firmy), bankructwo kluczowego dostawcy, niepowodzenie zastosowania
technologii uznanej przez kierownictwo firmy za jedyną słuszną itp.
Skuteczność identyfikacji poprawia się, jeśli dane z wcześniejszych projektów
wykorzystuje się do stworzenia wstępnej listy zagrożeń. Problemy z poprzedzającego
projektu powinny automatycznie wejść w skład listy zagrożeń następnego projektu.
Efektywność tej metody zależy przede wszystkim od tego, na ile gromadzone są,
przechowywane i udostępniane metryki z kolejnych projektów w organizacji.
Wielkość
zagrożeń
określamy
na
dwóch
skalach.
Oceniamy
prawdopodobieństwo zmaterializowania się danego zagrożenia (risk probability) – na
przykład prawdopodobieństwo trafienia działu informatycznego firmy przez meteoryt
jest mniejsze niż prawdopodobieństwo epidemii grypy wśród pracowników w styczniu.
Zagrożenia o których wiemy, że na pewno wystąpią – na przykład fakt, że w lipcu część
pracowników weźmie urlop – nie są już przedmiotem zarządzania zagrożeniami, lecz po
prostu jednym z czynników, które bierze się pod uwagę przy planowaniu projektu tak
samo jak dostępne zasoby, kwalifikacje personelu itp.
Oceniamy także konsekwencje zagrożeń (risk consequences) – na przykład skutki
nieoczekiwanego podkupienia wszystkich naszych programistów przez konkurencję
byłyby o wiele poważniejsze niż skutki 3-dniowej niedyspozycji administratora systemu.
Na pierwszy rzut oka powyższe stwierdzenia wydają się oczywiste, w praktyce
jednak już sama ocena wielkości zagrożeń nastręcza wiele trudności.
Oszacowanie zarówno prawdopodobieństwa jak i konsekwencji natrafia na szereg
trudności. Trudność pierwsza to wybór stosownej skali. Częstą pułapką jest
zastosowanie zbyt dokładnej skali, np. 10-stopniowej, podczas gdy tak precyzyjne
oszacowanie prawdopodobieństwa czy konsekwencji jest zwykle zupełną fikcją.
Najczęściej stosowana w praktyce jest skala 3-stopniowa.
Trudność druga to uświadomienie sobie rodzaju stosowanej skali i
dopuszczalnych sposobów interpretacji uzyskanych wyników. Jeśli np.
prawdopodobieństwo oceniamy od „1” (niskie) do „3” (wysokie), czy dopuszczalne jest
twierdzenie, że zagrożenie o prawdopodobieństwie „3” jest trzykrotnie bardziej
prawdopodobne niż grożenia wycenione na prawdopodobieństwo „1”?
Trudność trzecia polega na psychologicznych uwarunkowaniach oszacowań
zarówno prawdopodobieństwa jak i konsekwencji. Istnieje rozległa wiedza na temat
psychologicznych mechanizmów powodujących nietrafność – niekiedy rażącą – takich
oszacowań, kiedy dokonuje się ich intuicyjnie. Nie mamy niezawodnego sposobu
uniknięcia ani nawet ograniczenia wpływu tych mechanizmów, które dotyczą szeregu
zagadnień: dynamiki grupowej, subiektywnej oceny prawdopodobieństwa, dysonansu
poznawczego, postrzegania zależności korelacyjnych czy przyczynowych na podstawie
niedostatecznych przesłanek, pomijanie efektów pojawiających się z opóźnieniem w
odniesieniu do sytuacji zmiennych w czasie, itp.
Trudność czwarta dotyczy sposobu priorytetyzacji zagrożeń na podstawie funkcji
ich prawdopodobieństwa i konsekwencji. Często stosuje się proste mnożenie wartości z
obu skali, ale uzyskane w ten sposób wyniki mają istotność w najlepszym razie
orientacyjną.
Przeciwdziałanie zagrożeniom
Zagrożeniom można przeciwdziałać dwojako: po pierwsze, ograniczając
prawdopodobieństwa ich zaistnienia (zapobieganie), po drugie ograniczając ich skutki
(konsekwencje) gdy wystąpią (czynności zaradcze).
Zapobieganie zagrożeniom (risk mitigation) składa się z czterech kroków. Po
pierwsze, trzeba zidentyfikować możliwe metody zapobiegawcze – również te
niekonwencjonalne. Po drugie, trzeba oszacować skuteczność każdej z metod (o ile
spadnie prawdopodobieństwo zagrożenia gdy zastosujemy daną metodę) oraz – po
trzecie – koszty zastosowania metody. Na tej podstawie można wyliczyć opłacalność
zastosowania czynności zapobiegawczych:
Jeśli koszt_zapobiegania < koszt_konsekwencji * prawdopodobieństwo
wówczas zastosowanie czynności zapobiegawczych jest uzasadnioneii.
Planując czynności zaradcze (contingencies), bierzemy pod uwagę koszt
wdrożenia czynności zaradczych w razie zmaterializowania się zagrożenia oraz
ewentualny koszt przygotowania czynności zaradczych i utrzymywania ich w gotowości.
Jeśli koszt_wdrożenia + koszt_przygotowania < koszt_konsekwencji
wówczas zaplanowanie czynności zaradczych jest uzasadnione.
W praktyce uzyskanie dostatecznie dokładnych i pewnych oszacowań kosztów
jest zwykle trudne, aby umożliwić precyzyjne obliczenia wg powyższych wzorów,
wobec czego stosuje się metody przybliżone, heurystyczne lub wręcz intuicyjne, ze
wszystkimi ich zagrożeniami.
Zarządzanie zagrożeniami nie jest czynnością jednorazową, lecz procesem, który
powinien biec równolegle z projektem przez cały czas jego trwania. Pewne zagrożenia
znikną, inne nowe się pojawią, zmianie mogą też ulec oszacowania kosztów i
prawdopodobieństwa. Dlatego zbiór zagrożeń powinien podlegać nieustającemu
monitorowaniu (risk monitoring), mającemu wykryć ewentualne zmiany.
Monitorowanie polega na systematycznym wykonywaniu pomiarów oraz ich analizie w
celu wykrycia zmian w zbiorze zagrożeń.
Zarządzanie zagrożeniami a testowanie
Testowanie w projektach informatycznych często rozumiane jest w wąskim sensie
jako uruchamianie aplikacji (systemu) lub jej części w celu sprawdzenia, czy działa
poprawnie. W tej pracy używamy pojęcia testowanie w szerszym znaczeniu, jako ogół
czynności (weryfikacja, walidacja, certyfikacja, testowanie dynamiczne, analiza
statyczna, przeglądy) wykonywanych w trakcie projektu w celu skontrolowania czy
artefakty projektu zgodne są z założeniami, wymaganiami i specyfikacjami. Sprawdzane
artefakty to zarówno cały produkt (program, aplikacja, system informatyczny) jak i jego
części, dokumentacja będąca częścią produktu, dokumentacja będąca specyfikacją
produktu, a także dokumentacja projektowa, np. plany, harmonogramy itp.
Natomiast nie wchodzi w skład tak rozumianego testowania kontrola jakości
samego projektu, np. audyty przestrzegania w projekcie przyjętego procesu, norm i
standardów, ani pomiary jakości czy dojrzałości procesów i projektu.
Testowanie jest główną czynnością wykonywaną w ramach zarządzania
zagrożeniami. Bez testowania zarządzanie zagrożeniami pozbawione jest oparcia w
rzeczywistości, staje się jedynie teoretycznym roztrząsaniem, bez możliwości
stwierdzenia, czy zagrożenia materializują się lub jakie są ich faktyczne konsekwencje.
Wyniki testów z wcześniejszych projektów, odpowiednio wykorzystane, są
znakomitym źródłem, przy pomocy którego identyfikujemy zagrożenia istniejące w
bieżącym projekcie. Ponadto w trakcie projektu, odpowiednio wcześnie rozpoczęte
testowanie umożliwia zarówno identyfikację ew. nowych zagrożeń, jak i monitorowanie
zagrożeń. Wyniki testów są sygnałem ostrzegawczym informującym, że zagrożenie
zaczyna się materializować lub że prawdopodobieństwo zagrożenia wzrasta. Pozytywne
wyniki testów są z kolei informacją, że jakieś zagrożenie maleje lub wręcz przestało
istnieć.
Testowanie jest przede wszystkim metodą wykrywania i pomiaru zagrożeń
dotyczących produktu, które jednak z reguły przekładają się – jak zaznaczono wyżej –
na zagrożenia projektowe. Testowanie dokumentacji projektowej (planów,
harmonogramów) może także wykryć lub zmierzyć zagrożenia projektowe
bezpośrednio.
Zarys testowania na podstawie ryzyka
Testowanie, zwłaszcza testowanie produktu, ma na celu przede wszystkim
wykrycie jak największej liczby ważnych błędów, tak aby umożliwić ich usunięcie o
zmniejszyć liczbę i konsekwencje awarii produktu w działaniu.
Drugim podstawowym celem testowania jest pomiar jakości produktu tak, by móc
możliwie trafnie ocenić jego przyszłą niezawodność w działaniu i na tej podstawie
podejmować trafne decyzje projektowe i biznesowe, np. dotyczące terminu wdrożenia,
przewidywanych kosztów utrzymania i konserwacji itd.
Zwykle nie ma możliwości zupełnego przetestowania produktów
informatycznych, czyli takiego, które skontroluje działanie produktu we wszystkich
możliwych stanach, konfiguracjach i z wszelkimi możliwymi danymi, które mogą
zaistnieć podczas wieloletniego posługiwania się produktem przez setki czy wręcz
tysiące użytkowników. Przeciwnie – możliwych przypadków (scenariuszy, danych,
warunków) testowych są zwykle setki miliardów czy wręcz nieskończona liczba, a w
projekcie mamy możliwości wykonania ledwo kilku tysięcy testów. W tej sytuacji
kluczowym warunkiem sukcesu jest trafny dobór testów, tak aby jak najlepiej
odwzorowywały rzeczywiste zastosowanie systemu w działaniu i pozwalały wykrywać
jak największą liczbę ważnych błędów. Jednym słowem, dobór przypadków testowych
powinien gwarantować miarodajność wyników testowania dla oceny niezawodności
systemu informatycznego w działaniu.
Inżynieria oprogramowania dysponuje szeregiem metodyk i technik
pozwalających na zbliżanie się do tego celu. Tutaj skoncentrujemy się na podstawowej
metodzie, zwanej testowaniem na podstawie ryzyka. Nazwa ta jest często nadużywana,
wobec czego jej zakres znaczeniowy stał się w praktycznym zastosowaniu zamazany i
niejednoznaczny. Poniżej przedstawiamy kompletny model znaczenia tego pojęcia.
Model i definicja testowania na podstawie ryzyka
Przedmiotem testowania powinny być – zgodnie z paradygmatem testowania na
podstawie ryzyka – te funkcje lub właściwości produktu (systemu, aplikacji)
informatycznego, których wadliwe działanie powodowałoby największe straty. Wielkość
strat poniesionych w wyniku awarii zależy zarówno od tego, jak wysokie są koszty
pojedynczej awarii, jak i od tego, jak często ta awaria ma miejsce.
Nie każdy rodzaj zagrożenia daje się równie łatwo ocenić i wykryć przy pomocy
testowania. Przykładowo, wpływ trzęsienia ziemi na sprzęt systemu informatycznego,
daje się przetestować wyłącznie przy użyciu kosztownych symulatorów trzęsienia ziemi.
Zależności opisane powyżej pokrótce, można opisać dokładniej przy pomocy
grafu:
1.
1. waga
waga testu
testu
2.
2. koszt
koszt testu
testu
4.
4. techniki
techniki testów
testów ii
charakter
zagrożenia
charakter zagrożenia
7.
7. oszacowania
oszacowania
biznesowe
biznesowe
3.
3. waga
waga awarii
awarii
5.
5. koszt
koszt awarii
awarii
8.
8. profil
profil użycia
użycia
10.
10. wiedza
wiedza nt.
nt. użycia
użycia
6.
6. częstość
częstość awarii
awarii
9.
9. częstość
częstość błędów
błędów
11.
11. szereg
szereg czynników
czynników
Rys. 1 Zależności pozwalające określić wagę przypadków testowych
1. Waga testu to miara pozwalająca porównywać testy między sobą i wybierać te, które
bardziej się opłacają. Waga testu jest skorelowana pozytywnie z kosztami (wagą)
awarii, którym ten test pozwala zapobiec [5], a negatywnie z kosztem (trudnościami)
wykonania tego testu [2].
2. Koszt testu jest miarą określającą, na ile danej awarii da się w ogóle zapobiec
poprzez testy mające na celu zlokalizowanie mogących ją spowodować błędów. Im
dokładniejszą ma się wiedzę o technicznych i organizacyjnych aspektach testowania
[4], tym trafnej można oszacować ten koszt.
3. Waga awarii zależy od konsekwencji (kosztu) tej awarii [5] oraz od przewidywanej
częstotliwości jej występowania [6]. Kształt tej zależności nie da się jednoznacznie
określić, na pewno jest różny dla różnych projektów, rodzajów produktów, wymagań
klientów.
4. Informacje o skuteczności i kosztach testów uzyskujemy ze szczegółowych danych
nt. pokrycia testowego, kosztów wykonania testów, organizacji testów (poziomy
testowania, testy regresji) oraz na podstawie danych archiwalnych z poprzednich
projektów.
5. Informację o koszcie awarii uzyskuje się na podstawie oceny biznesowej [7].
6. Częstotliwość awarii wpływa, podobnie jak jej koszty, na wagę awarii. Im częściej
dana awaria występuje, tym wyższe jej łączne koszty. Zależność ta nie zawsze ma
charakter liniowy, bowiem np. awaria o niskim koszcie jednostkowym, ale
występująca szczególnie często, może mieć nieoczekiwanie wysoki wpływ na
subiektywną ocenę jakości systemu przez klientów/użytkowników, co z kolei
wpływa na wysokość ponoszonych w wyniku awarii strat. Częstotliwość awarii
zależy od dwóch czynników, częstotliwości sposobu użycia [8] oraz od gęstości
błędów w kodzie, realizującym testowaną funkcjonalność [9]. Jeśli dwie funkcje
mają podobną liczbę błędów, to awarie pojawiają się częściej w tej, która jest
intensywniej (częściej) używana. Istnieje też zależność odwrotna: kiedy dwie funkcje
są jednakowo intensywnie użytkowane, to więcej awarii wystąpi przy wykonywaniu
tej funkcji, która ma większą gęstość błędów.
7. Oszacowanie biznesowe pozwala ocenić koszty awarii. W praktyce pewne składowe
kosztów daje się ocenić względnie precyzyjnie (np. wysokość kar umownych, koszty
wytworzenia i wdrożenia nowej wersji systemu itp.), inne składowe jednak z trudem
pozwalają się wyliczyć (efekty długofalowe, stopniowa utrata klientów itp.).
8. Profile użycia, jeśli są dostępne, pozwalają określić, jak intensywnie i z jakimi
danymi użytkowane są poszczególne funkcjonalności i ścieżki testowanego systemu.
9. Zwykle nie jest nam znana gęstość błędów w danej funkcji czy części systemu,
jednak często można ją próbować oszacować na podstawie wartości danych
skorelowanych [11], takich jak złożoność algorytmu, liczba osób odpowiedzialnych
za implementację, historia wcześniejszych podobnych błędów, jakość projektu
systemu itp.
10. Profile użycia uzyskujemy bądź to na podstawie wcześniej gromadzonych danych
archiwalnych, bądź na podstawie analizy przewidywanego profilu użytkowania, bądź
wreszcie przy pomocy analizy logów i innych pomiarów wykonywanych na systemie
działającym już w środowisku produkcyjnym.
Podsumowanie
Przedsięwzięcia informatyczne obciążone są niepewnością. Istniejące zagrożenia mogą
spowodować fiasko planowanego wyniku przedsięwzięcia. Zarządzenie zagrożeniami
(Risk Management) umożliwia osiągnięcie sukcesu nawet w sytuacji realnie
zmaterializowanych zagrożeń. Kluczowym elementem zarządzania zagrożeniami jest
testowanie. Testowanie pozwala na skuteczną identyfikację zagrożeń produktowych,
oszacowanie prawdopodobieństwa ich materializacji i monitorowania, jak również
usprawnia ocenę konsekwencji zagrożeń.
Skuteczne testowanie musi dotyczyć przede wszystkim obszarów o największych
zagrożeniach. Przypadki testowe do takiego testowania dobiera się tak, aby dotyczyły
najwyższych zagrożeń produktowych (Risk Based Testing).
Literatura
A. Andrzej Kobyliński, Modele jakości produktów i procesów programowych,
Oficyna Wydawnicza SGH, Warszawa, 2005
B. Tom DeMarco, Timothy Lister, Waltzing with Bears –Managing Risk on SW
Projects, Dorset House Publishing, New York, 2003
C. Rex Black, Managing the Test Process – Practical Tools and Techniques for
Managing HW and SW Testing, Wiley Publishing, 2002
D. Fredrick P. Brooks, The Mythical Man-Month – Essays on SW Engineering
Anniversary Edition, ADDISON-WESLAEY, 2001
E. Dietrich Dorner, Rita Kimber (Translator), Robert Kimber (Translator), The
Logic of Failure: Recognizing and Avoiding Error in Complex Situations,
Metropolitan Books, 1996
F. Martyn Ould, Managing SW Quality and Business Risk, Wiley, 1999
G. Andreas Spillner, Tilno Lintz, Hans Schaeffer, SW Testing Foundations,
dpunkt.verlag, 2006
H. Erik van Veenendaal, The Testing Practitioner, UTN Publishers, 2002
i
Np. zagrożenie mające prawdopodobieństwo „2” i konsekwencje „2” otrzymuje priorytet „4” (2 * 2 = 4),
podczas gdy zagrożenie o prawdopodobieństwie „1” i konsekwencjach „3” otrzymuje priorytet „3” (1 * 3
= 3).
ii
Ściślej, rozstrzygnięcie zależy od przyjętej strategii decyzji, np. przy strategii maksymalizacji zysku
można przyjąć unikanie jakichkolwiek dodatkowych kosztów zapobiegania zagrożeniom, które mogą
przecież wcale się nie zmaterializować.