Ryzyka, jeśli się zmaterializują, mają negatywny wpływ na nasze projekty. Zarządzanie ryzykiem polega na rozważeniu, jakie ryzyka istnieją, oraz podjęciu działań w celu zmniejszenia prawdopodobieństwa ich wystąpienia, wyeliminowania ich lub ograniczenia ich wpływu na cele interesariuszy.
W niektórych firmach zarządzanie ryzykiem prowadzi się z inżynierską i matematyczną precyzją. W oprogramowaniu nie da się osiągnąć aż takiej precyzji. Większość organizacji nadal nie stosuje systematycznie testowania opartego na ryzyku. Istnieje jednak ku temu ważny powód: po zidentyfikowaniu ryzyka związane z produktem programistycznym często są niezwykle trudne do oceny.
Z perspektywy testowania i zapewniania jakości ryzyko to „tryb awarii, który powinien budzić obawy”. Testowanie oparte na ryzyku to praktyka modelowania potencjalnych trybów awarii systemu jako ryzyk związanych z produktem w celu wsparcia określania zakresu, skalowania i ustalania priorytetów testów.
W tym artykule przedstawię manifest testowania opartego na ryzyku. Przyjrzymy się klasycznemu zarządzaniu ryzykiem i zobaczymy, jak możemy je dostosować, aby było przydatne dla testerów. Na koniec omówimy kilka praktycznych kwestii i aspektów, które pomogą zastosować własną metodę testowania opartego na ryzyku.
- Ryzyko projektu, procesu i produktu
- Manifest testowania opartego na ryzyku
- Klasyczne podejście do ryzyka
- Ryzyko produktu i testowanie
- Kwestie praktyczne
- Zrozumienie roli testowania w zarządzaniu ryzykiem
Ryzyko projektu, procesu i produktu
Istnieją setki książek na temat ryzyka i zarządzania ryzykiem, które przedstawiają liczne podejścia do zarządzania ryzykiem na poziomie projektu. Zazwyczaj podejścia te koncentrują się na tym, co nazwiemy ryzykiem projektu i procesu, być może z pojedynczym ryzykiem zatytułowanym na przykład „niespełnienie wymagań”. Posiadanie jednego ryzyka dotyczącego wymagań nie jest zbyt pomocne, ponieważ nie można przecież ustalić priorytetu jednego ryzyka na potrzeby testowania.
Istnieją trzy rodzaje ryzyka związanego z oprogramowaniem.
Ryzyko projektu: Ryzyka te dotyczą projektu w jego własnym kontekście. Projekty zazwyczaj mają zależności zewnętrzne, takie jak dostępność kompetencji, zależność od dostawców, nieprzekraczalne terminy lub ograniczenia, na przykład umowę o stałej cenie. Zależności zewnętrzne należą do odpowiedzialności za zarządzanie projektem.
Ryzyko procesu: Ryzyka te dotyczą przede wszystkim wewnętrznych aspektów projektu, a planowanie, monitorowanie i kontrola projektu podlegają analizie. Typowe ryzyka w tym obszarze to niedoszacowanie złożoności projektu, nakładu pracy lub wymaganych kompetencji. Wewnętrzne zarządzanie projektem, takie jak dobre planowanie, monitorowanie postępów i kontrola, należy do obowiązków związanych z zarządzaniem projektem.
Ryzyko produktu: Ryzyko produktu jest głównym obszarem ryzyka, który interesuje testerów. Ryzyka te dotyczą definicji produktu, stabilności (lub jej braku) wymagań, złożoności produktu oraz podatności technologii na usterki.
Od tej pory skupimy się na ryzyku produktu. Będziemy używać terminu „ryzyko produktu” w następującym znaczeniu:
Manifest testowania opartego na ryzyku
W projektach, w których podejmowane będzie ryzyko (a naszym zdaniem dotyczy to wszystkich projektów), testerzy muszą zapewniać kierownictwu widoczność ryzyk i proponować wiarygodne metody testowania, które pozwolą uwzględniać te ryzyka w całym cyklu projektu.
Jest to zadanie kierownictwa — wykonywanie poniższych zadań związanych z testowaniem opartym na ryzyku i/lub nadzorowanie ich:
Klasyczne podejście do ryzyka
Istnieje wiele wariantów, ale klasyczne podejście do ryzyka stara się mieć charakter ilościowy.
Have an account? Log In
Prawdopodobieństwo, konsekwencje i ekspozycja
Aby ocenić ryzyko związane z produktem, musimy zrozumieć, jakie są konsekwencje danego trybu awarii. Jeśli wystąpi awaria, mówimy, że ryzyko się materializuje. Następnie pytamy: „jak poważne jest ryzyko?”, co inaczej określa się mianem ekspozycji.
Aby obliczyć ekspozycję, oceniamy ryzyko w dwóch wymiarach:
- Prawdopodobieństwo (lub możliwość) materializacji ryzyka. Wartość ta jest zazwyczaj wyrażana jako wartość procentowa między (ale bez uwzględniania) zerem a 100 procentami.
- Konsekwencje (lub wpływ albo strata) materializacji ryzyka. Jest to potencjalny koszt szkody, jeśli wystąpi dany tryb awarii.
Ekspozycję na ryzyko – czyli to, jak poważne jest ryzyko – oblicza się jako iloczyn prawdopodobieństwa i konsekwencji.
Klasycznemu podejściu do ryzyka często brakuje wsparcia technologicznego potrzebnego do efektywnego zarządzania. Nowoczesne rozwiązania do zarządzania testami wypełniają tę lukę, oferując funkcje dostosowane do testowania opartego na ryzyku.
Ocena ilościowa czy jakościowa
Obecnie często trudno jest przewidzieć potencjalny koszt awarii. Bez dodatkowych informacji niemal niemożliwe jest również przewidzenie prawdopodobieństwa awarii z dużą pewnością. Dlatego większość praktyków przyjmuje półilościowe lub jakościowe skale prawdopodobieństwa i konsekwencji.
Powszechnie stosuje się zakresy liczbowe od jednego do pięciu dla obu skal, co daje możliwe wartości ekspozycji od jednego do dwudziestu pięciu. Jednak niewielu testerów, programistów czy interesariuszy przypisuje tym liczbom wartości z jakąkolwiek pewnością, dlatego często po prostu ocenia się ekspozycję na ryzyko bezpośrednio za pomocą skali od 1 do 5 lub — jeszcze prościej — stosuje się ocenę czerwona, bursztynowa, zielona. Niektórzy posuwają się nawet do stwierdzenia, że ryzyko mieści się w zakresie projektu lub poza nim, ale sugerowalibyśmy, że jest to zbyt daleko idące uproszczenie.
Niezależnie od tego, czy kwantyfikujesz ryzyka, czy oznaczasz je kolorami w tabeli, kluczowym aspektem ocen ryzyka nie jest punktacja, lecz rozmowy i debaty prowadzone podczas przypisywania i omawiania ocen.
Jeśli poproszono Cię o ocenę ryzyka z większą precyzją niż za pomocą skal od jednego do trzech (lub najwyżej pięciu), powinieneś poważnie rozważyć, czy przypisywane przez Ciebie liczby mają jakąkolwiek rzeczywistą wartość.
Ocena liczbowa może sprawiać wrażenie naukowej rygorystyczności, ale jeśli liczby są zgadywane, oszukujesz sam siebie. Jeśli liczby ujawniają różnice zdań, np. użytkownik mówi „pięć”, a programista „jeden!”, oznacza to, że należy przeprowadzić rozmowę, ponieważ oczekiwania lub postrzeganie są wyraźnie różne.
Uważaj na stosowanie prostego podziału ryzyka na mieszczące się w zakresie projektu i wykraczające poza jego zakres. Może być jasne, które istotne ryzyka należy uwzględnić w testach. Jednak projekty rozwijają się z czasem i często się opóźniają, dlatego trzeba iść na kompromisy. Jeśli ryzyka nie zostaną w jakiś sposób ustalone priorytetowo, konieczne będzie przejrzenie wszystkich istotnych ryzyk, aby zdecydować, które z nich należy usunąć z zakresu, a które do niego dodać.
Omówimy zakres, ustalanie priorytetów i skalowanie bardziej szczegółowo w kolejnych artykułach, więc zaglądaj do nas.
Ryzyko związane z produktem i testowanie
Omówienie ryzyk związanych z produktem ujawni obawy interesariuszy dotyczące prawdopodobieństwa awarii w krytycznych obszarach projektu lub systemu. Mając listę ryzyk związanych z produktem, jak przełożyć ją na działania i konkretne plany testów? Zanim odpowiemy na to pytanie, musimy nieco lepiej zrozumieć, jak testowanie wpływa na nasze oceny ryzyka.
Testowanie nie zmniejsza ryzyka — dostarcza informacji do oceny ryzyka
Często można usłyszeć, że „testowanie zmniejsza ryzyko”. To nieprawda — testowanie czasami może zwiększać ryzyko. Hasło, że testowanie zmniejsza ryzyko, wynika z braku zrozumienia zarówno ryzyka, jak i testowania.
Załóżmy, że zidentyfikowaliśmy ryzyko, iż jakaś funkcja lub funkcjonalność może ulec awarii. Formułujemy test i uruchamiamy go. Test może zakończyć się powodzeniem albo niepowodzeniem. Jak pozytywny lub negatywny wynik testu wpłynąłby na naszą ocenę ryzyka?
Po pierwsze, testy nie mają wpływu na nasze rozumienie konsekwencji awarii. Konsekwencje awarii są takie, jakie są, a testowanie tego nie zmienia.
Istnieją cztery istotne wyniki testu i ich wpływ na prawdopodobieństwo ryzyka. Zostały one podsumowane w poniższej tabeli:
| Prawdopodobieństwo ryzyka wzrasta | Prawdopodobieństwo ryzyka maleje | |
| Test zakończony pomyślnie | Nie. Pomyślnie zakończony test może jedynie zwiększyć naszą pewność, że dana przyczyna awarii nie wystąpi. (Zakłada to, że nasze testy są miarodajne). | Tak, ostatecznie. W miarę przeprowadzania kolejnych pomyślnie zakończonych testów i badania różnych scenariuszy prawdopodobieństwo awarii maleje. |
| Test zakończony niepowodzeniem | Możliwe, w zależności od rodzaju niepowodzenia. Jednak prawdopodobieństwo z czasem maleje. Przewidzieliśmy, że ten tryb awarii wystąpi; wybór testu został potwierdzony. Na szczęście możemy teraz to naprawić i skoncentrować testowanie na zmniejszeniu ryzyka innych awarii tego typu. | Mało prawdopodobne, chyba że błędnie oceniliśmy ryzyko. |
Uruchamianie testów, które wiążemy z konkretnym ryzykiem, dostarcza nam coraz więcej informacji pozwalających udoskonalić ocenę ryzyka. Jeśli testy zakończą się niepowodzeniem, nasz wybór zostaje potwierdzony. Gdy naprawimy problem i ponownie przeprowadzimy testy, wraz z ich pomyślnym przebiegiem nasza ocena ryzyka powinna się zmniejszyć. Jeśli jednak nadal będziemy znajdować nowe lub kolejne błędy, możemy ponownie ocenić ryzyko jako wyższe.
Teraz, gdy rozumiesz potencjał testowania w kontekście oceny ryzyka, możemy przyjrzeć się określaniu testów na podstawie opisów ryzyka.
Planowanie testów oparte na ryzyku
Jako testerzy, gdy zidentyfikujemy istotne ryzyko dotyczące produktu, musimy sformułować zestaw testów wykazujących, że dany tryb awarii jest mniej prawdopodobny. Oczywiście nasze podejście testowe będzie polegać na wywołaniu tego trybu awarii na jak najwięcej sposobów, a tym samym:
Łącznie nasze testy koncentrują się na sposobach wystąpienia wybranego trybu awarii. Załóżmy na przykład, że ryzyko polegało na „nieprawidłowym obliczeniu składki ubezpieczenia komunikacyjnego”. W takim przypadku odpowiednim celem testu mogłoby być „wykazanie za pomocą techniki wszystkich par dla zmiennych wejściowych, że system prawidłowo oblicza składkę ubezpieczenia komunikacyjnego”. Taki cel testu można przekazać testerowi, aby opracował zestaw przypadków testowych zapewniający pokrycie z wykorzystaniem techniki wszystkich par.
Aspekty praktyczne
Teraz przyjrzyjmy się kilku praktycznym kwestiom związanym z testowaniem opartym na ryzyku.
Co zrobić, jeśli interesariusze nie są zainteresowani pomocą w ocenie ryzyka?
Może się okazać, że trudno jest uzyskać czas interesariuszy na pomoc w identyfikacji i ocenie ryzyka oraz opracowaniu planu testów.
Co zrobić, jeśli dla danego ryzyka produktu istnieje wiele opcji testowania?
Oczywiście prawie zawsze tak jest. Na przykład, aby przetestować istotną funkcję, można zastosować dowolną z szeregu technik projektowania testów albo w unikalny sposób zamodelować funkcję i wyprowadzić testy z tego modelu. Można zastosować szereg miar pokrycia w celu ustalenia wartości docelowej. Funkcję można testować ręcznie, za pomocą narzędzia lub innej technologii.
W kolejnym artykule „Ile testowania wystarczy?” przyjrzymy się temu, jak można dokonywać wyborów.
Co zrobić, jeśli testowanie (w celu ograniczenia ryzyka) kosztuje zbyt dużo?
Ponieważ prawie zawsze istnieją różne możliwości i nie ma ograniczenia co do zakresu testowania, które można zastosować w celu zbadania ryzyka i uzyskania informacji do jego oceny, należy dokonać wyboru. Nie trzeba dodawać, że niektóre opcje zostaną uznane za zbyt drogie. Dlatego przedstawiając interesariuszom dostępne możliwości, trzeba mieć co najmniej jedną opcję przystępną cenowo oraz jedną, która może być nieosiągalna finansowo.
Ponownie: w kolejnym artykule „Ile testowania wystarczy?” przyjrzymy się temu, jak można dokonywać wyborów.
More Articles
Jeśli dokładniej testujemy funkcje wysokiego ryzyka, to testujemy mniej pozostałych funkcji, prawda?
Jeśli budżet na testowanie zespołu jest z góry ustalony albo wielkość zespołu i liczba testerów są stałe, zakres testowania, który można przeprowadzić, jest ograniczony (w dowolnej ustalonej skali czasu lub okresie ograniczonym czasowo). Jeśli więc większy nacisk położymy na niektóre funkcje, testowanie pozostałych musi zostać ograniczone. Zakres pokrycia, a przynajmniej nakład pracy poświęcony poszczególnym funkcjom, zmienia się wraz z ryzykiem.
Należy spojrzeć na to w ten sposób: gdy test kończy się niepowodzeniem i w systemie zostaje znaleziony błąd, dotkliwość przypisana temu błędowi prawdopodobnie będzie ściśle związana ze skutkiem tej awarii (na środowisku produkcyjnym). Poważniejsze błędy są naprawiane, ponieważ są po prostu ważniejsze dla interesariuszy.
Analiza ryzyka produktu wskazuje obszary, w których błędy, ze względu na ich znaczenie, mają większe szanse na naprawę. Wykorzystanie analizy ryzyka do wskazania, gdzie przeprowadza się testy lub gdzie stosuje się ich większą liczbę, oznacza zatem, że z większym prawdopodobieństwem znajdziemy ważne błędy, a z mniejszym — błędy w funkcjach, na których interesariuszom może mniej zależeć.
Dobrze byłoby myśleć, że czasami możemy testować wszystko w bardziej równomierny sposób. Jednak gdy zasoby i czas są ograniczone (a zawsze tak jest, prawda?), podejście oparte na ryzyku pomaga efektywniej i wydajniej wykorzystywać czas testerów.
Co, jeśli testowanie nie jest właściwą reakcją?
Zanim poświęcisz czas na szczegółowe opracowanie podejścia do testowania ryzyka związanego z produktem, należy również rozważyć opcje niezwiązane z testowaniem. Załóżmy na przykład, że istnieje duża obawa, iż komponent systemu może nie działać wystarczająco dobrze w środowisku produkcyjnym, a czasy odpowiedzi lub niezawodność są niezadowalające. Oczywiście można przeprowadzić testy obciążeniowe i próbować rozwiązać problemy poprzez debugowanie. Inne możliwości to jednak:
- Kupić komponent od strony trzeciej, zamiast go budować i podejmować ryzyko.
- Przeprojektować architekturę rozwiązania tak, aby rozłożyć obciążenia na wiele instancji komponentu.
- Przenieść przetwarzanie do systemu wsadowego działającego na kopii danych.
- Zamiast wdrażać rozwiązanie jednocześnie dla wszystkich użytkowników, przyjąć etapowe podejście do wdrażania go u klientów, region po regionie, i dokładnie monitorować wydajność.
- I tak dalej.
Często inne działania zapobiegające wystąpieniu problemów są skuteczniejsze i bardziej ekonomiczne niż testowanie mające na celu znalezienie tych problemów na późniejszym etapie.
Zrozumienie roli testowania w zarządzaniu ryzykiem
Testowanie może zmniejszyć ryzyko związane z wydaniem produktu. Jeśli wykorzystamy ocenę ryzyka do ukierunkowania naszych działań testowych, celem testerów staje się jawne projektowanie testów w celu wykrywania defektów, aby można je było naprawić, a tym samym zmniejszyć ryzyko wystąpienia wad w produkcie.
Wykrywanie defektów zmniejsza ryzyko rezydualne awarii podczas działania systemu na produkcji, gdzie koszty rosną bardzo gwałtownie. Gdy test wykryje defekt i zostanie on naprawiony, liczba defektów się zmniejsza, a w konsekwencji spada ogólne prawdopodobieństwo awarii.
Można również spojrzeć na to w następujący sposób: „mikroryzyko” wynikające z tego defektu zostaje wyeliminowane. Należy jednak pamiętać, że testowanie nie jest w stanie wykryć wszystkich defektów, dlatego zawsze pozostaną ukryte defekty, których nie usunięto i o których testowanie nie dostarczyło żadnych bezpośrednich informacji.
Jeśli jednak skupimy się na funkcjach krytycznych i wykryjemy w nich defekty, prawdopodobieństwo wystąpienia niewykrytych defektów w tych funkcjach będzie mniejsze. Defekty pozostałe w niekrytycznych funkcjach systemu będą miały mniejsze konsekwencje.
Na koniec jeszcze jedna uwaga: sam proces analizy ryzyka jest ryzykowny. Analiza ryzyka może zarówno przeszacować, jak i niedoszacować ryzyko, prowadząc do decyzji, które nie są optymalne. Analiza ryzyka może również przyczyniać się do powstawania kultury obwiniania, jeśli posunie się ją zbyt daleko.
Wśród innych potencjalnych problemów związanych z analizą ryzyka należy zrozumieć, że nie istnieje coś takiego jak absolutne ryzyko, które można obliczyć po zakończeniu projektu. Charakter ryzyka polega na tym, że jest ono niepewne. Podobnie jak w przypadku skuteczności testowania, wartość analizy ryzyka można określić dopiero z perspektywy czasu, po zakończeniu projektu.
I to wszystko w naszym manifeście testowania opartego na ryzyku. Koncepcja ta będzie powracać w całej serii „Przywództwo w testowaniu”, więc śledźcie kolejne artykuły!
Zapisz się do newslettera The QA Lead, aby otrzymywać powiadomienia o publikacji nowych części serii. Te wpisy są fragmentami kursu „Przywództwo w testowaniu” Paula, który gorąco polecamy wszystkim, którzy chcą dokładniej zgłębić ten i inne tematy. Jeśli zdecydujesz się na zakup, użyj naszego wyjątkowego kodu kuponu QALEADOFFER, aby otrzymać $60 zniżki od pełnej ceny kursu!
