Testy oparte na ryzyku

Testowanie oparte na ryzyku (RBT) to rodzaj testowania oprogramowania , który funkcjonuje jako zasada organizacyjna stosowana do ustalania priorytetów testów cech i funkcji w oprogramowaniu, w oparciu o ryzyko niepowodzenia, funkcję ich ważności i prawdopodobieństwa lub wpływ niepowodzenia.   Gerrard, Paweł; Thompson, Neil (2002). Testowanie e-biznesu oparte na ryzyku . Wydawnictwo Artech House. ISBN 978-1-58053-314-0 . </ref> Teoretycznie istnieje nieskończona liczba możliwych testów. Testowanie oparte na ryzyku wykorzystuje (ponowną) ocenę ryzyka do kierowania wszystkimi fazami procesu testowego, tj. planowaniem testów, projektowaniem testów, implementacją testów, wykonywaniem testów i oceną testów. Obejmuje to na przykład ranking testów i podtestów pod kątem funkcjonalności; techniki testowe, takie jak analiza wartości granicznych , testowanie wszystkich par i tablice przejść między stanami, mają na celu znalezienie obszarów, w których występuje największe prawdopodobieństwo wystąpienia defektów.

Ocena ryzyka

Porównanie zmian między dwoma wydaniami lub wersjami ma kluczowe znaczenie dla oceny ryzyka. Ocena krytycznych modułów biznesowych jest pierwszym krokiem w ustalaniu priorytetów testów, ale nie obejmuje pojęcia ryzyka ewolucyjnego. Jest to następnie rozszerzane przy użyciu dwóch metod: testowania opartego na zmianach i testowania regresji .

• Testowanie oparte na zmianach umożliwia zespołom testowym ocenę zmian wprowadzonych w wydaniu, a następnie nadanie priorytetu testom w kierunku zmodyfikowanych modułów.
• Testy regresyjne zapewniają, że zmiana, taka jak poprawka błędu, nie wprowadziła nowych błędów do testowanego oprogramowania. Jednym z głównych powodów testowania regresji jest ustalenie, czy zmiana w jednej części oprogramowania ma jakikolwiek wpływ na inne części oprogramowania.

Te dwie metody pozwalają zespołom testowym ustalać priorytety testów w oparciu o ryzyko, zmianę i krytyczność modułów biznesowych. Niektóre technologie może sprawić, że tego rodzaju strategia testowa będzie bardzo łatwa do skonfigurowania i utrzymania dzięki zmianom w oprogramowaniu.

Rodzaje ryzyka

Ryzyko można zidentyfikować jako prawdopodobieństwo, że niewykryty błąd oprogramowania może mieć negatywny wpływ na użytkownika systemu.

Metody oceniają ryzyko w różnych wymiarach:

Biznesowe lub operacyjne

• Wysokie wykorzystanie podsystemu, funkcji lub cechy
• Krytyczność podsystemu, funkcji lub cechy, w tym koszt awarii

Techniczny

• Rozmieszczenie geograficzne zespołu programistów
• Złożoność podsystemu lub funkcji

Zewnętrzny

• Preferencje sponsora lub kierownika
• Wymogi regulacyjne

Związane z trybem awaryjnym e-biznesu

• Statyczne wady zawartości
• Wady integracji strony internetowej
• Funkcjonalne niepowodzenie związane z zachowaniem
• Awaria związana z usługą (dostępność i wydajność).
• Awaria związana z użytecznością i dostępnością
• Luka w zabezpieczeniach
• Błąd integracji na dużą skalę

Niektóre rozważania na temat ustalania priorytetów ryzyka zostały napisane przez Venkata Ramakrishnana na blogu.