Zespół pracujący nad systemem płatności online stosuje testowanie oparte na ryzyku, aby zdecydować, na czym się skupić. Analiza ryzyka identyfikuje przepływ autoryzacji płatności jako obarczony wysokim ryzykiem (duże prawdopodobieństwo wystąpienia defektów i poważne skutki, jeśli wystąpią), natomiast funkcja pobierania raportów ma niskie ryzyko. Wysiłek testowy jest rozdzielany odpowiednio: przepływ płatności otrzymuje rozległe projektowanie i wykonywanie testów, w tym analizę wartości brzegowych i testy integracyjne, a funkcja pobierania raportów — lżejsze przejście testowe. Interesariusze są informowani o poziomie ryzyka rezydualnego przez cały czas trwania projektu.
Czym testowanie oparte na ryzyku różni się od zwykłego testowania? To podejście, w którym poziom testowania jest wyznaczany przez poziom zidentyfikowanych ryzyk produktu. Ryzyka są identyfikowane już na początkowych etapach projektu, a ich poziomy kierują procesem testowania — im więcej ryzyka, tym więcej testowania.
Czym jest ryzyko produktu? Ryzyko produktu to ryzyko, że sam komponent lub system nie spełni swoich celów — na przykład nieprawidłowa funkcjonalność, słaba wydajność lub luki w zabezpieczeniach. Testowanie oparte na ryzyku celuje właśnie w te ryzyka produktu.
Kto wykonuje analizę ryzyka? Zespół testowy, programiści i interesariusze wspólnie. Identyfikacja ryzyk zyskuje na wielości perspektyw, a wynikowe poziomy ryzyka są uzgadniane, a nie narzucane.
Czy testowanie oparte na ryzyku zastępuje inne techniki projektowania testów? Nie. Określa, GDZIE i ILE testować; same przypadki testowe nadal korzystają z technik takich jak podział na klasy równoważności, analiza wartości brzegowych czy zgadywanie błędów.
Jaka jest rola ryzyka w planie testów? Plan testów dokumentuje ryzyka wymagające planowania działań awaryjnych. Testowanie oparte na ryzyku nadaje temu praktyczny wymiar: plan, harmonogram i kryteria wyjścia odzwierciedlają zidentyfikowane poziomy ryzyka.