ultimate guide risk based testing
Kompletny przewodnik po testowaniu opartym na ryzyku, zarządzaniu ryzykiem i jego podejściu z przykładami:
Co to jest testowanie oparte na ryzyku?
Testowanie oparte na ryzyku polega na przeprowadzaniu testów lub projektowaniu i wykonywaniu scenariuszy, tak aby główne ryzyka biznesowe, które będą miały negatywny wpływ na działalność zidentyfikowane przez klienta, zostały odkryte w jego produkcie lub funkcji na wczesnym etapie cyklu życia i są złagodzone poprzez wdrożenie środków łagodzących.
=> Kliknij tutaj, aby uzyskać pełną serię samouczków dotyczących planu testów
Negatywny wpływ może obejmować wpływ na koszty, niezadowolenie klienta, złe wrażenia użytkownika, a nawet utratę klientów.
Innymi słowy, podejście RBT polega na zapewnieniu, że testowanie jest wykonywane w taki sposób, że nawet jeśli użytkownik znajduje błąd w produkcji, która nie przeszkadza mu w korzystaniu z oprogramowania lub nie wpływa w poważny sposób na biznes.
RBT to testy przeprowadzane w oparciu o ryzyka produktowe. RBT ma na celu ustalenie z dużym wyprzedzeniem, jakie jest ryzyko niepowodzenia danej funkcji lub funkcjonalności w produkcji i jej wpływ na biznes pod względem kosztów i innych szkód, stosując technikę priorytetyzacji przypadków testowych.
Dlatego testowanie oparte na ryzyku wykorzystuje zasadę priorytetyzacja testów cech, modułów i funkcjonalności produktu lub oprogramowania. Priorytetyzacja opiera się na ryzyku prawdopodobieństwa awarii tej funkcji lub funkcjonalności w produkcji i jej wpływie na klientów.
Czego się nauczysz:
- Testowanie oparte na ryzyku i jego znaczenie dla Agile i DevOps
- Zarządzanie ryzykiem podczas planowania testów
- Zarządzanie ryzykiem w fazie wykonywania testów (z przykładem)
Testowanie oparte na ryzyku i jego znaczenie dla Agile i DevOps
Trzysta godzin spędzonych na tworzeniu oprogramowania może stać się bezużyteczne w zaledwie 30 sekund po zidentyfikowaniu jednej usterki w produkcji.
To z kolei może zrujnować cel całego produktu, nie mając innego wyjścia, jak tylko wycofać go z rynku. I to jest znaczenie i potrzeba „testowania jakości”.
Wraz z szybkim rozwojem technologii, oprogramowanie jest hostowane w chmurze obsługującej wiele systemów operacyjnych, wiele platform, złożoną infrastrukturę IT itp., Użytkownicy końcowi stają się coraz bardziej wybredni co do funkcji, opcji i nigdy nie idą na kompromis w kwestii satysfakcji klienta .
W dzisiejszych czasach „Jakość” staje się kluczowym czynnikiem w dostarczaniu oprogramowania, gdzie ciągłe ulepszenia mają na celu poprawę jakości i zadowolenie klientów.
Często zauważamy, że częstym problemem dla prawie wszystkich testerów jest to, że są pod ogromną presją, że ich okno testowe jest ściśnięte, a kompilacja jest zwykle przekazywana im do przetestowania w ostatniej chwili. Nie ma wystarczająco dużo czasu i zasobów, aby przeprowadzić wszystkie testy, które zaprojektowali, a pokrycie automatyzacji nie zawsze wynosi 100% i ma swoje własne wyzwania.
Nie można przegapić harmonogramu dostaw, a jednocześnie nie można zagrozić jakości. Jakikolwiek plan B, dodanie dodatkowych zasobów testowych poprzez wycofanie się z innych zespołów, nie działa, Plan C, zaprzestanie wykonywania wszystkich innych czynności i skierowanie wysiłku na to samo, tak naprawdę nie pomaga. Jednak wiele dodawania zasobów testowych ostatecznie nie działa.
Nie ma innego wyjścia, jak tylko przeprowadzić ograniczone i ważne testy w dostępnym czasie i zasobach.
Jak więc zdecydować, który test jest ważny na tym etapie? Cokolwiek Tester uważa za ważne, może nie być naprawdę ważne dla klientów. Z czyjej perspektywy decyduje się znaczenie danej cechy lub funkcjonalności? Kto zadecyduje, które testy są ważne? I pojawia się wiele innych pytań.
Aby odpowiedzieć na wszystkie te pytania i skutecznie poradzić sobie z powyższą sytuacją, zastosowano podejście testowe o nazwie „Testowanie oparte na ryzyku” , krótko nazywany „RBT” powstało, gdzie zespół jasno zaplanował i zidentyfikował scenariusze testowe w oparciu o kryteria „ryzyka projektu”.
Chociaż zespół ds. Kontroli jakości ma jasny obraz ważnych testów, RBT jest sprawdzoną metodą identyfikacji kluczowych i ważnych testów z perspektywy klienta i biznesu poprzez 'Ocena ryzyka' procedura .
Tak więc, w przeciwieństwie do tradycyjnego sposobu prostego identyfikowania defektów w oprogramowaniu, podejście i cel QA zmieniły się z czasem ze względu na zmianę technologii, wzrost konkurencji na rynku w celu wydania oprogramowania wysokiej jakości, wprowadzenie „Automatyzacja wszystkiego”, a także całkowite wprowadzenie praktyki Agile i DevOps polegającej na dostarczaniu oprogramowania w ciągu kilku godzin.
Stąd obecny trend „Zasady testowania” polega nie tylko na „identyfikacji defektów”, ale także na
# 1) Skoncentruj się na obszarze produktu, który ma duży wpływ na biznes z powodu awarii lub wysokiego prawdopodobieństwa niepowodzenia w produkcji.
#dwa) Skupiając się na identyfikacja wad wcześnie i umożliwiając zespołowi naprawienie go tak wcześnie, jak to możliwe, a tym samym zezwalając oprogramowaniu / produktowi lub funkcji „Szybka porażka”.
# 3) Najważniejszym aspektem obsługi zespołu QA jest teraz skupienie się na kliencie w dostarczaniu wartości dla klienta poprzez zwiększenie nacisku na „Od końca do końca”.
Podejście oparte na ryzyku
To zawsze tak, jakbyśmy przygotowywali się do egzaminu, że nie można powiedzieć, że testowanie wystarczy i nie ma już błędów w oprogramowaniu, nawet jeśli projektuje i wykonuje dużą liczbę testów.
Jest moment, w którym stabilność oprogramowania nie będzie podwójnie zapewniona poprzez samo zwiększenie liczby przypadków testowych. W tym momencie nie chodzi tylko o skupienie się na liczbie testów, ale także na tym, czego klient oczekuje od wydania.
Dlatego konieczne jest zachowanie równowagi w optymalizacji testów, aby uzyskać maksymalne korzyści przy rozsądnym wysiłku związanym z testowaniem. Jest to ważniejsze, gdy ramy czasowe testów są bardzo napięte i nie ma wystarczających zasobów, aby przeprowadzić wystarczające testy.
Tak więc w tym przypadku podejście RBT odgrywa kluczową rolę w optymalizacji wysiłku QA i maksymalizacji korzyści z testowania przy minimalnym ryzyku biznesowym.
Jeśli więc skupimy się na powyższym aspekcie, praca podczas kontroli jakości będzie znacznie odciążona. Nie muszą spędzać weekendów w biurze, ciągle testując oprogramowanie i martwiąc się o wszystkie usterki S4 (Severity 4) i P4 (Priority 4), które wynikną z testów.
Cóż, 4 jest uważane za najniższy priorytet i dotkliwość błędów w testowaniu. Mogą lepiej zainwestować swój czas w inne przydatne aspekty projektu.
Podsumowując kluczowe czynniki wpływające na podejście „testowania opartego na ryzyku”:
- Aby umożliwić testowanie „tego, czego chcą klienci” z biznesowego punktu widzenia.
- Dotrzymać harmonogramu z oczekiwaną jakością.
- Aby zoptymalizować wysiłek związany z kontrolą jakości.
Kiedy stosujemy podejście RBT?
Jest to używane w poniższych scenariuszach:
- Podejście RBT może być stosowane zawsze, gdy występuje ograniczenie lub ograniczenie czasu, kosztów i zasobów projektu oraz zawsze, gdy istnieje potrzeba optymalizacji zasobów.
- Podejście RBT jest stosowane, gdy program jest bardziej złożony i dostosowuje nową technologię, co wiąże się z wieloma wyzwaniami.
- Kiedy program jest projektem badawczo-rozwojowym i jest to projekt pierwszego rodzaju, a projekt zawiera szereg niewiadomych i zagrożeń.
Przykład podejścia RBT
W branży IT stosuje się kilka metod analizy opartej na ryzyku, aby przezwyciężyć ryzyko związane z produkcją i jej wpływem.
Poniżej podano jedno z takich podejść:
Podejście RBT obejmuje identyfikację „istotnych funkcji lub kluczowych cech” produktu i ocenę ryzyka, na które narażona jest każda z tych funkcji podczas produkcji, oraz wdrożenie odpowiednich środków łagodzących w celu obniżenia lub ograniczenia ryzyka.
Stąd podejście RBT obejmuje testowanie funkcjonalności, które mają prawdopodobieństwo awarii i największy wpływ na biznes. Rodzaje awarii mogą być operacyjne lub biznesowe, techniczne, zewnętrzne itp.
Sposoby przeprowadzania analizy ryzyka
Nie ma standardowego procesu ani szablonu zdefiniowanego jako taki do przeprowadzania analizy ryzyka w testowaniu oprogramowania dla każdej cechy produktu. Różne organizacje stosują własne podejście do metod analizy ryzyka.
Analizę ryzyka można przeprowadzić na różnych pozycjach projektu, aby zidentyfikować ryzyko i wdrożyć podejście RBT do analizy. Te pozycje obejmują,
- funkcje
- Funkcjonalności
- Historie użytkownika
- Wymagania
- Przypadków użycia
- Przypadki testowe
W tym przypadku skupmy się tylko na przypadkach testowych, aby zrozumieć implementację podejścia opartego na ryzyku.
Procedura analizy ryzyka
Analiza ryzyka obejmuje zaangażowanie odpowiednich interesariuszy programu zarówno z „ Zespół techniczny i zespół biznesowy ” , w tym właściciel produktu, menedżerowie produktu, analitycy biznesowi, architekci, testerzy i przedstawiciele klientów.
Zorganizowano by sesje burzy mózgów z udziałem tych interesariuszy, aby przeprowadzić dyskusję w celu zidentyfikowania wagi każdej cechy produktu i uszeregowania ich pod względem ważności w oparciu o ryzyko awarii i jej wpływ na użytkowników końcowych w produkcji.
Różne „dokumenty projektowe”, takie jak dokument wymagań, dokumenty specyfikacji technicznej, dokumenty dotyczące architektury i projektu, dokumenty procesu biznesowego, dokumenty przypadków użycia itp. Staną się danymi wejściowymi do sesji burzy mózgów.
Wiedza interesariuszy na temat produktu i produktu istniejącego na rynku również będzie czynnikiem wejściowym do dyskusji.
Niewiele innych źródeł danych wejściowych może również obejmować:
- Aby zebrać dane wejściowe dotyczące najczęściej używanych funkcji.
- Dane wejściowe z konsultacji z ekspertem domeny.
- Dane z poprzedniej wersji produktu lub podobnego produktu na rynku.
Podczas burza mózgów sesji, zidentyfikowane zostaną ryzyka związane z każdą z tych funkcji. Rodzaje ryzyka mogą być operacyjne, techniczne lub biznesowe. Testy i związane z nimi scenariusze są ważone, a wartości ryzyka oceniane są na podstawie prawdopodobieństwa wystąpienia ryzyka i wpływu ryzyka.
„Prawdopodobieństwo wystąpienia ryzyka” może wynikać z:
- Słabe zrozumienie funkcji przez zespół rozwoju produktu.
- Niewłaściwa architektura i projekt.
- Za mało czasu na zaprojektowanie.
- Niekompetentność zespołu.
- Niewystarczające zasoby - ludzie, narzędzia i technologia.
„Wpływ ryzyka” to skutek niepowodzenia dla użytkowników i biznesu, jeśli wystąpi. Może to mieć wpływ
- Wpływ na koszty prowadzący do straty.
- Wpływ na działalność prowadzący do utraty biznesu lub udziału w rynku, postępowania sądowe, utrata licencji.
- Wpływ na jakość, powodujący wydanie produktu niespełniającego norm lub niekompetentnego.
- Złe wrażenia użytkownika, powodujące niezadowolenie i utratę klienta.
Głównym obszarem oceny ryzyka związanego z cechą lub produktem mogą być:
- Obszar krytycznego znaczenia biznesowego funkcjonalności.
- Najczęściej używane funkcje i ważne funkcje.
- Obszary podatne na uszkodzenia
- Funkcjonalność mająca wpływ na bezpieczeństwo i ochronę.
- Obszar projektowania kompleksowego i architektury.
- Zmiany wprowadzone w stosunku do poprzednich wersji.
Metodologia analizy ryzyka
Przyjrzyjmy się teraz szczegółowo „metodologii testowania opartego na ryzyku”.
Testowanie oparte na ryzyku wykorzystuje RYZYKO jako kryterium na wszystkich etapach testów cyklu testowego, tj. planowanie testów , projektowanie testów, implementacja testów, wykonanie testu i raportowanie testów. W idealnym przypadku można zaprojektować wiele możliwych kombinacji scenariuszy testowych.
W związku z tym podejście RBT obejmuje ranking testów w oparciu o powagę zagrożeń, aby znaleźć najbardziej wadliwy lub ryzykowny obszar niepowodzenia, który ma duży wpływ na biznes.
Głównym celem analizy ryzyka jest rozróżnienie między 'Wysoka wartość' elementy takie jak cechy produktu, funkcjonalności, wymagania, historie użytkownika i przypadki testowe oraz „ Niska wartość' i dlatego później, aby bardziej skupić się na przypadkach testowych „o wysokiej wartości”, mniej skupiając się na przypadkach testowych „o niskiej wartości”. Jest to pierwszy krok analizy ryzyka przed rozpoczęciem testów opartych na ryzyku.
Główne zadanie kategoryzacji lub grupowania przypadków testowych w kategorie o wysokiej i niskiej wartości oraz przypisanie wartości priorytetu do każdego z tych przypadków testowych obejmuje następujące kroki:
Krok 1) Korzystanie z siatki 3X3
Analiza ryzyka jest przeprowadzana przy użyciu siatki 3X3, w której każda funkcjonalność, niefunkcjonalność i powiązane przypadki testowe są oceniane przez zespół interesariuszy pod kątem „Prawdopodobieństwoof failure ”i„ Impact of failure ”.
Prawdopodobieństwo awarii każdej funkcji w produkcji jest ogólnie dostępne dla grupy „Ekspertów Technicznych” i są one klasyfikowane jako „Prawdopodobne awarie, bardzo prawdopodobne i mało prawdopodobne” wzdłuż osi pionowej siatki.
jak otwierać pliki swf w Adobe Flash Player
Podobnie „wpływ awarii” tych cech i funkcjonalności na produkcję jest doświadczany przez klienta końcowego, jeśli nie są testowane, jest oceniany przez grupę ' Specjaliści biznesowi ”i są podzieleni na kategorie„ Niewielkie, Widoczne i Przerwy ”wzdłuż poziomej osi siatki.
Krok 2) Prawdopodobieństwo i wpływ niepowodzenia
Wszystkie przypadki testowe są umieszczone w ćwiartkach siatki 3 X 3 w oparciu o zidentyfikowane wartości prawdopodobieństwa i wpływu awarii, które są pokazane jako kropki na poniższym rysunku.
Oczywiście wysokie prawdopodobieństwo awarii i duży wpływ awarii (przerwania) są zgrupowane w prawym górnym rogu siatki, co ma duże znaczenie i stąd stwierdza się, że testy `` wysokiej wartości '' i `` niskiej wartości '' są zgrupowane w lewy dolny róg, który ma najmniejsze lub żadne znaczenie dla klienta, w którym można skupić się na tych funkcjach lub przypadkach testowych.
Krok 3) Testowanie siatki priorytetów
Na podstawie powyższego umiejscowienia przypadków testowych w siatce, testy są uszeregowane pod względem ważności i oznaczone priorytetami 1, 2, 3, 4 i 5 oraz są oznaczane przy każdym z nich. Najważniejsze testy znajdują się w 1śwsiatki, którym przypisano priorytet 1 i podobnie mniej ważne, są klasyfikowane jako 2, 3, 4 i 5.
Na koniec wszystkie przypadki testowe są sortowane na podstawie ich numerów priorytetów i odbierane do wykonania w kolejności ważności. Te o wysokim priorytecie są pobierane do wykonania jako pierwsze, a te o niskim priorytecie są wykonywane później lub bez zakresu.
Krok 4) Szczegóły testowania
Kolejnym krokiem jest ustalenie poziomu szczegółowości testowania dla zdefiniowanego zakresu testowania. Głębokość zakresu badań można określić na podstawie powyższego rankingu zgodnie z poniższą tabelą.
Testy o wysokim priorytecie z rankingiem 1 są poddawane dokładniejszym testom, w związku z czym eksperci są wysyłani do testowania tych funkcji o wysokim stopniu krytyczności i powiązanych z nimi przypadków testowych. Podobnie przypadki testowe z priorytetem 2, 3 i 4. Można podjąć decyzję o usunięciu zakresu funkcji i testów z priorytetem 5 na podstawie dostępnego czasu i zasobów.
W związku z tym podejście poziomu szczegółowości testowania polegające na ustalaniu priorytetów funkcji i przypadków testowych nie tylko pomaga testerom zidentyfikować `` testy o wysokiej wartości '', ale także pomaga im zdecydować o ich `` poziomie szczegółowości testowania '' na podstawie tych priorytetów i pomaga im przeprowadzać lepsze testy i zmniejsza koszty testowania dzięki procesowi optymalizacji.
Jakie znaczenie ma RBT w Agile i DevOps?
Teraz, po zrozumieniu podejścia opartego na testowaniu opartym na ryzyku, polegającego na przeprowadzaniu testów w oparciu o priorytetyzację testów w zależności od `` ryzyka niepowodzenia '' konkretnej funkcji i jej `` wpływu na klienta '' na żywo, można oczywiście poruszyć kwestię znaczenie podejścia testowania opartego na ryzyku w praktykach zwinnych i DevOps.
„Automatyzuj wszystko”, „Testuj wszystko”, „Testuj w sposób ciągły”, „Testuj wielokrotnie” to kluczowe pojęcia związane z tymi praktykami.
Za każdym razem, gdy następuje zmiana w kodzie lub wydanie, wszystkie zaprojektowane testy są uruchamiane automatycznie Ciągła integracja (CI) / Ciągłe dostarczanie (CD) rurociągów szybko i wielokrotnie, niezależnie od ich priorytetów.
Jaka jest zatem relacja między RBT a DevOps? Gdzie RBT pasowałby i stałby się istotny w Agile i DevOps ???
# 1) Tak, jak powiedziałem wcześniej, nie jest tak, że każda branża i każdy produkt ma 100% pokrycie automatyzacji wykonywania testów. Tak więc, jeśli w ogóle zespół musi dokonać wyboru priorytetów dla wykonania testów z wyboru ręcznych przypadków testowych i chciałby zaoszczędzić energię i wysiłek zasobów testowych na inne działania, to RBT jest najlepszym wyborem.
Podejście oparte na ryzyku jest również lepszym rozwiązaniem w przypadku uruchamiania testów automatycznych o wysokim priorytecie i testowania najwcześniej.
#dwa) Zespół ds. Kontroli jakości może skuteczniej przyjąć podejście RBT podczas analizy wymagań, analizując wymagania i dostarczając z wyprzedzeniem sprawozdania dotyczące prawdopodobnych zagrożeń związanych z produktami i funkcjami, tak aby zespół programowy mógł proaktywnie podjąć odpowiednie działania w celu złagodzenia tego problemu.
# 3) Podejście RBT może być skutecznie wykorzystywane przy projektowaniu przypadków testowych i scenariuszy opartych na wysokim ryzyku, aby można było bardziej skoncentrować się na cechach i funkcjach wysokiego ryzyka.
# 4) Zidentyfikowanie obszarów „wysokiego ryzyka” umożliwia zespołowi kontroli jakości skoncentrowanie wysiłków związanych z testowaniem na tych obszarach, aby testować „dokładniej” za pomocą „wysoko wykwalifikowanych testerów”.
# 5) „Szybka porażka”, jak wszyscy wiemy, jest koncepcją „Agile” i „DevOps”, w przypadku których podejście RBT pomaga zidentyfikować obszary „wysokiego ryzyka” w oprogramowaniu, wcześnie zidentyfikować defekty i pozwolić im szybko zawieść i zawodzić najpierw i pozwól zespołowi to naprawić.
# 6) Ostatecznym celem Agile / DevOps jest „Koncentracja na kliencie”, a zatem podejście RBT umożliwia QA skupienie się na doświadczeniu klienta, a nie tylko na znajdowaniu usterek.
Korzyści z testowania opartego na ryzyku
Zrozumieliśmy już cel i zastosowanie podejścia RBT do analizy wymagań, projektowania i wykonywania scenariuszy testowych. Istnieje kilka zalet RBT.
Możemy skonsolidować i wymienić zalety testowania opartego na ryzyku jako:
- Pomaga w bardziej wydajnym i zoptymalizowanym wykorzystaniu zasobów testowych.
- Pomaga w ułatwianiu zadań związanych z zapewnianiem jakości, testowaniem, projektowaniem i opracowywaniem testów oraz przygotowywaniem testów poprzez ustalanie priorytetów.
- Pomaga w lepszym zarządzaniu zasobami zapewniania jakości poprzez przydzielanie kluczowych zasobów do obszarów wymagających szczególnej uwagi.
- Pomaga w efektywnym wykorzystaniu zasobów i kieruje ich czas i energię na lepsze rzeczy w projekcie.
- Pomaga zespołowi kontroli jakości w planowaniu działań testowych w oparciu o ocenę ryzyka i identyfikację obszarów niestabilnych i wysokiego ryzyka.
- Pomaga zespołowi w optymalizacji testów, które mają być przeprowadzone, w zależności od ich ważności, a tym samym do ograniczenia zakresu testów o niskiej wartości w porozumieniu z interesariuszami.
- Ogólnie rzecz biorąc, pomaga w redukcji kosztów poprzez zoptymalizowane i ograniczone czynności testowe.
- Podejście RBT umożliwia zespołowi kontroli jakości najpierw przetestowanie obszarów wysokiego ryzyka i pozwala produktowi „szybko zawieść” i szybko naprawić.
- Podejście RBT pomaga w zapewnieniu jasności w „ Pokrycie testowe ” oraz „Zakres testu” dla całej grupy Interesariuszy.
- Zespół może skupić się bardziej na obszarach wysokiego ryzyka, a mniej na obszarze niskiego ryzyka.
- RBT umożliwia zespołowi podjęcie decyzji z dużym wyprzedzeniem o wdrożeniu najskuteczniejszego sposobu ograniczenia ryzyka produktowego.
- RBT pomaga uniknąć skutków niewłaściwego wdrożenia środków zaradczych.
- Testowanie oparte na ryzyku pozwala zespołowi na podjęcie odpowiednich działań w celu złagodzenia lub zaplanowania awaryjnego lub wprowadzenia obejścia w celu przezwyciężenia awarii lub zmniejszenia jej wpływu, jeśli ryzyko wystąpi w czasie rzeczywistym.
- RBT pomaga zminimalizować ryzyko szczątkowe w uwolnieniu.
- Pomaga w osiągnięciu „ulepszonej jakości” dzięki mniej kosztownym wadom produkcyjnym.
- Ostatecznie pomaga w „Poprawie jakości obsługi klienta” i „Zadowoleniu klienta”.
Następnie dowiemy się, jak zarządzać ryzykiem w fazie planowania testów i wykonywania testów w cyklu życia testowania oprogramowania.
Zarządzanie ryzykiem podczas planowania testów
Jak zarządzać ryzykiem podczas fazy planowania testów:
Życie jest pełne ryzyka, podobnie jak projekt oprogramowania. W każdej chwili wszystko może się nie udać. Zawsze jesteśmy gotowi, aby wszystko naprawić - ale co z upewnieniem się, że nic nie pójdzie nie tak, a kiedy już, będziemy dokładnie wiedzieć, co robić? Wejdź do zarządzania ryzykiem - to część projektu testowania oprogramowania, która przygotowuje nas do zapobiegania ryzyku, zrozumienia go, znalezienia i pokonania go.
Ryzyko to po prostu problem, który prawdopodobnie wystąpi, a gdy wystąpi, spowoduje stratę.
Strata może oznaczać wszystko - pieniądze, czas, wysiłek lub kompromis w jakości. Strata nigdy nie jest dobra. Bez względu na to, jak mocno go podkręcimy, nie jest to pozytywne - i nigdy nie będzie. W związku z tym Zarządzanie ryzykiem jest integralną częścią projektów oprogramowania, aby mieć pewność, że radzimy sobie z ryzykiem i zapobiegamy stratom / je ograniczamy.
Testowanie oparte na ryzyku : Ponieważ jesteśmy społecznością zapewniania jakości, pozwól nam być specyficznym dla ryzyka i związanego z nim procesu wyłącznie w naszym świecie kontroli jakości. Ryzyka są oceniane i zarządzane w przybliżeniu w dwóch etapach naszego Cykl życia testu oprogramowania . STLC można podzielić na 3 fazy - planowanie testów, projektowanie testów i wykonywanie testów.
Proces zarządzania ryzykiem występuje dwukrotnie, podczas:
- Planowanie testów
- Projektowanie przypadków testowych (koniec) lub czasami w fazie wykonywania testów
Jest to obowiązkowe w przypadku 1, ale w przypadku 2 jest to sytuacja bardziej „oparta na potrzebach”.
Dwuczęściowa seria artykułów:
Mimo że podstawowy proces jest taki sam, plik rodzaje zagrożeń adresowane w obu tych obszarach są zupełnie inne. Aby oddać im sprawiedliwość indywidualnie, będziemy traktować je inaczej jako dwuczęściową serię.
Ta sekcja będzie dotyczyła „Zarządzanie ryzykiem podczas planowania testów”.
Proces zarządzania ryzykiem
Ogólny proces zarządzania ryzykiem obejmuje 3 ważne etapy:
- Identyfikacja ryzyka
- Analiza wpływu ryzyka
- Ograniczenie ryzyka
Przykłady testowania ryzyka i łagodzenia skutków:
# 1) Identyfikacja ryzyka
Jak się mówi, pierwszym krokiem do rozwiązania problemu jest jego identyfikacja. Ten etap obejmuje sporządzenie listy wszystkiego, co może potencjalnie pojawić się i zakłócić normalny przepływ wydarzeń.
Głównym rezultatem tego kroku jest lista zagrożeń.
Ten etap testowania oparty na ryzyku jest zwykle prowadzony przez kierownika / menedżera / przedstawiciela kontroli jakości. Jednak sam kierownik nie będzie w stanie wymyślić całej listy - wkład całego zespołu ds. Kontroli jakości ma ogromny wpływ. Można powiedzieć, że jest to wspólne działanie prowadzone przez kierownika ds. Zapewnienia jakości.
Ponadto ryzyko zidentyfikowane podczas fazy planowania testów ma bardziej „zarządczy” charakter - co oznacza, że przyjrzymy się wszystkim, co może wpłynąć na harmonogram projektu QA, nakłady pracy, budżet, zmiany w infrastrukturze itp. nie AUT, ale sposób, w jaki będzie przebiegała faza kontroli jakości.
Ryzyka podczas planowania testów: przykłady testów opartych na ryzyku
Poniżej znajduje się przykładowa lista zagrożeń, które mogą zostać wymienione podczas fazy planowania testów. Należy pamiętać, że AUT i jego funkcjonalność nie są tutaj przedmiotem zainteresowania.
- Harmonogram testów jest napięty. Jeśli rozpoczęcie testów jest opóźnione z powodu zadań projektowych, test nie może zostać przedłużony poza zaplanowaną datę rozpoczęcia UAT.
- Za mało zasobów, zbyt późne wdrażanie zasobów (proces trwa około 15 dni).
- Wady stwierdza się na późnym etapie cyklu lub w późnym cyklu; defekty wykryte późno są najprawdopodobniej spowodowane niejasnymi specyfikacjami i ich usuwanie jest czasochłonne.
- Zakres nie został całkowicie zdefiniowany
- Klęski żywiołowe
- Niedostępność Independent Środowisko testowe i dostępność
- Opóźnione testowanie z powodu nowych problemów
W tym momencie możesz wybrać tak dokładny, jak chcesz, w zależności od ilości dostępnego czasu.
Gdy wszystkie ryzyka zostaną wymienione, przechodzimy do oceny ryzyka / analizy wpływu ryzyka.
# 2) Ocena ryzyka / analiza wpływu ryzyka
Czy twoja analiza ryzyka jest podobna do tej? :)
Analiza ryzyka w testowaniu oprogramowania : Na tym etapie wszystkie ryzyka są określane ilościowo i priorytetyzowane. Prawdopodobieństwo (prawdopodobieństwo wystąpienia) i wpływ każdego ryzyka (kwota straty, jaką spowodowałoby to w przypadku materializacji tego ryzyka) określane są w sposób systematyczny.
Wysoka Średnia Niska , przypisuje się zarówno prawdopodobieństwo, jak i wpływ każdego ryzyka. Ryzyka o „wysokim” prawdopodobieństwie i „dużym” wpływie są uwzględniane w pierwszej kolejności, a następnie następuje kolejność.
Tabela analizy wpływu ryzyka:
Po wykonaniu tych kroków tabela analizy wpływu ryzyka dla wyżej wymienionych zagrożeń wyglądałaby mniej więcej tak (wszystkie wartości są hipotetyczne i służą tylko do zrozumienia):
Ryzyko | Prawdopodobieństwo | Wpływ |
---|---|---|
7. Opóźnione testowanie z powodu nowych problemów | Średni | Wysoki |
1. Harmonogram testów jest napięty. Jeśli rozpoczęcie testów jest opóźnione z powodu zadań projektowych, test nie może zostać przedłużony poza zaplanowaną datę rozpoczęcia UAT. | Wysoki | Wysoki |
2. Za mało zasobów, zbyt późne wejście na pokład (proces trwa około 15 dni). | Średni | Wysoki |
3. Wady stwierdza się na późnym etapie cyklu lub w późnym cyklu; defekty wykryte późno są najprawdopodobniej spowodowane niejasnymi specyfikacjami i ich usuwanie jest czasochłonne. | Średni | Wysoki |
4. Zakres nie zdefiniowany całkowicie | Średni | Średni |
5. Klęski żywiołowe | Niska | Średni |
6. Niedostępność niezależnego środowiska testowego i dostępność | Średni | Wysoki |
# 3) Ograniczanie ryzyka
Ostatnim krokiem w procesie testowania opartego na ryzyku (RBT) jest znalezienie rozwiązań umożliwiających zaplanowanie postępowania w każdej z tych sytuacji. Plany te mogą się różnić w zależności od firmy, projektu do projektu, a nawet osoby.
Techniki ograniczania ryzyka:
Oto przykład tego, w co przekształca się tabela ryzyka po zakończeniu tej fazy:
Ryzyko | Prob. | Wpływ | Plan ograniczania ryzyka |
---|---|---|---|
Opóźnione testowanie z powodu nowych problemów | Średni | Wysoki | Podczas testowania istnieje duża szansa, że zostaną zidentyfikowane „nowe” defekty, które mogą stać się problemem, którego rozwiązanie zajmie trochę czasu. Istnieją usterki, które mogą zostać podniesione podczas testowania z powodu niejasnej specyfikacji dokumentu. Te wady mogą doprowadzić do problemu, który będzie wymagał czasu, aby go rozwiązać. Jeśli te problemy staną się showstoppers, będzie to miało duży wpływ na ogólny harmonogram projektu. W przypadku wykrycia nowych defektów stosowane są procedury zarządzania defektami i zarządzania problemami, aby natychmiast rozwiązać problem. |
HARMONOGRAM Harmonogram testów jest napięty. Jeśli rozpoczęcie testów jest opóźnione z powodu zadań projektowych, test nie może zostać przedłużony poza zaplanowaną datę rozpoczęcia UAT. | Wysoki | Wysoki | • Zespół testujący może kontrolować zadania przygotowawcze (z wyprzedzeniem) i wczesną komunikację z zaangażowanymi stronami. • Do harmonogramu na nieprzewidziane sytuacje dodano pewien bufor, chociaż nie tak dużo, jak zalecają najlepsze praktyki. |
ZASOBY Za mało zasobów, zbyt późne wejście na pokład (proces trwa około 15 dni. | Średni | Wysoki | Urlop i wakacje zostały oszacowane i włączone do harmonogramu; odchylenia od oszacowania mogą wynikać z opóźnień w testowaniu. |
WADY Wady stwierdza się na późnym etapie cyklu lub w późnym cyklu; defekty wykryte późno są najprawdopodobniej spowodowane niejasnymi specyfikacjami i ich usuwanie jest czasochłonne. | Średni | Wysoki | Wdrożono plan zarządzania defektami, aby zapewnić szybką komunikację i rozwiązywanie problemów. |
ZAKRES Zakres całkowicie zdefiniowany | Średni | Średni | Zakres jest dobrze zdefiniowany, ale zmiany w funkcjonalności nie są jeszcze sfinalizowane lub ciągle się zmieniają. |
Klęski żywiołowe | Niska | Średni | Zespoły i obowiązki zostały rozdzielone na dwa różne obszary geograficzne. W przypadku katastrofalnego zdarzenia w jednym z obszarów, w innych obszarach będą zasoby potrzebne do kontynuowania (choć w wolniejszym tempie) czynności testowych. |
Niedostępność niezależnego środowiska testowego i dostępność | Średni | Wysoki | Brak dostępności środowiska wpływa na harmonogram i spowoduje opóźnione rozpoczęcie wykonywania Testów. |
Kilka punktów do zapamiętania:
- Im szybciej zarządzanie ryzykiem rozpocznie się w fazie planowania projektu QA, tym lepiej.
- Ze wszystkich 3 kroków, Identyfikacja ryzyka jest najważniejsza . Jeśli czegoś nie ma na liście i rozważa dalsze kroki, ryzyko pozostaje nierozwiązane.
- Spróbuj znaleźć idealne ramy czasowe dla tej czynności. Pamiętaj, że zbyt długie planowanie pozostawia zbyt mało czasu na działanie.
- Ponadto po zakończeniu procesu zarządzania ryzykiem, jeśli pojawi się nowa sytuacja, plan zarządzania ryzykiem może zostać zmieniony lub zaktualizowany w celu odzwierciedlenia najbardziej aktualnego stanu.
- Dane historyczne może być bardzo przydatne dla powodzenia tego procesu.
Wniosek
To prowadzi nas do końca zarządzania ryzykiem w fazie planowania testów. Mimo że podstawowe kroki i zasady są podobne, proces zarządzania ryzykiem jest bardziej skoncentrowany na AUT, gdy ma to miejsce na etapie projektowania / wykonywania testów.
W naszej następnej sekcji omówimy - Zarządzanie ryzykiem w fazie wykonywania testów.
Zarządzanie ryzykiem w fazie wykonywania testów (z przykładem)
Podczas naszej podróży do zrozumienia procesu zarządzania ryzykiem rozmawialiśmy o tym, jak przebiega on wyłącznie w Faza planowania testów testów opartych na ryzyku . Zrozumieliśmy również ogólny proces, który obejmuje - identyfikację ryzyka, ocenę ryzyka i plan ograniczania ryzyka.
Jak zarządzać ryzykiem na etapie projektowania testów lub wykonywania testów:
Jest jeszcze jedna forma Zarządzanie ryzykiem (czasami nazywane także Testowanie oparte na ryzyku ), który występuje na etapie projektowania testów lub wykonywania testów, w zależności od sytuacji. O jakiej sytuacji mówimy? Spróbujmy najpierw to zrozumieć.
Wszyscy wiemy, że nasza praca testowa jest reaktywna. Brak wymagań (lub zdefiniowany zakres), nie możemy przeprowadzić analizy wykonalności i napisać scenariuszy testowych ani zaplanować działań testowych.
Podobnie, gdy kod nie jest gotowy, nie mamy nic do testowania, bez względu na to, ile prac przygotowawczych mogliśmy być gotowi w zakresie przypadków testowych, danych testowych itp. Ponadto testowanie jest jedynym krokiem, jaki pozostał przed uruchomieniem produktu. relacja na żywo.
Zarządzanie ryzykiem - ze szczególnym uwzględnieniem AUT
Zrozummy to lepiej na przykładzie:
Gdyby testy rozpoczęły się w ten dzień, 1 styczniaświ musiał trwać do 14 styczniath- po zakończeniu testów data uruchomienia produktu jest zwykle ustalana natychmiast. Powiedzmy - 15 styczniathze względu na prostotę. Teraz w idealnym świecie wszystko potoczy się dokładnie tak, jak zaplanowano. Ale wszyscy znamy rzeczywistość.
W tym przypadku załóżmy, że z jakiegoś powodu testy zaczęły się dopiero 7 styczniath, co oznacza, że straciliśmy połowę czasu na testowanie. Ale potrzebujemy 14 dni na dokładne przetestowanie produktu. Moglibyśmy jednak przesunąć datę uruchomienia o 7 dni dalej; zwykle nie jest to możliwe. Ponieważ produkt ma trafić na rynek w określonym terminie, a wszelkie opóźnienia nie są korzystne dla firmy.
Dlatego zazwyczaj zespoły testujące muszą wchłonąć opóźnienia, jakoś skompensować, pracować z dostępnym czasem i upewnić się, że produkt jest dobrze przetestowany. Ciężka praca, prawda?
W tym miejscu ponownie stosuje się proces zarządzania ryzykiem.
- Teraz jeśli opóźnienia są przewidywane z wyprzedzeniem jeszcze przed rozpoczęciem testów - proces odbywa się w fazie projektowania testów.
- Gdyby opóźnienia występują podczas Faza wykonania testu który rozpoczął się normalnie - proces jest śledzony w fazie wykonywania testu.
- Kroki i metoda są takie same bez względu na to, na jakim etapie się to dzieje.
Jaki to proces?
Zarządzanie ryzykiem ma na celu określenie, które obszary AUT (testowana aplikacja) wymagają maksymalnego skupienia. Są to zazwyczaj obszary funkcjonalne (moduły lub komponenty), które mają kluczowe znaczenie dla powodzenia produktu końcowego i są najbardziej podatne na awarie.
Przeczytaj także=> Analiza trybów i skutków awarii (FMEA) jest techniką zarządzania ryzykiem
Kto to wykonuje?
Ponieważ chodzi o AUT, wiedza o tym jest nie tylko z QA, ale ze wszystkimi innymi zespołami - Dev, BA, Client, zespołami zarządzającymi projektami itp. Dlatego jest to zbiorowy wysiłek, kierowany przez zespół testujący.
Jak przebiega testowanie baz ryzyka?
Krok 1) Identyfikacja ryzyka
Zidentyfikuj wszystkie obszary funkcjonalne AUT. Będzie to po prostu obejmować sporządzenie listy.
Krok 2) Ocena ryzyka
Na tym etapie wszystkie ryzyka są określane ilościowo i priorytetyzowane. Kwantyfikacja polega po prostu na przypisaniu liczby do każdego ryzyka na liście, która wskaże priorytet, z jakim należy się do niego odnieść.
Ustala się prawdopodobieństwo (prawdopodobieństwo wystąpienia) i wpływ każdego ryzyka (kwota straty, jaką spowodowałoby ono, gdy to ryzyko się zmaterializuje).
Typową metodą jest nadawanie ocen. Na przykład, Prawdopodobieństwo może przyjmować wartości od 1 do 5. 1 oznacza prawdopodobieństwo wystąpienia zdarzenia niskie (w ogóle nie jest prawdopodobne), a 5 jest wysokie (z pewnością wystąpi).
Podobnie Impactowi można przypisać ocenę 1-5. 1 oznacza niewielki wpływ (nawet jeśli to ryzyko się urzeczywistni, strata jest minimalna), a 5 oznacza duży wpływ (duże straty, gdy wystąpią).
Krok 3)
Przygotuj tabelę i roześlij ją do wszystkich przedstawicieli zespołu - deweloperów, BA, klienta, PM, QA i innych odpowiednich osób.
Krok 4)
Poinstruuj każdy zespół, aby wpisał wartości na podstawie ich oceny prawdopodobieństwa i wpływu.
Ponieważ wartości prawdopodobieństwa i wpływu są liczbowe, ułatwi to obliczenie wartości „współczynnika ryzyka”.
Czynnik ryzyka = prawdopodobieństwo X Wpływ. Im wyższy współczynnik ryzyka, tym poważny problem.
Przykład:
Należy pamiętać, że w tym momencie jest to po prostu wynik oceny jednego zespołu. W przypadku projektu, w którym zaangażowanych jest 5 różnych zespołów, zespół ds. Kontroli jakości miałby 5 różnych tabel.
Krok 5)
Weź średnią wartości współczynnika ryzyka. Na przykład, jeśli jest 5 zespołów, dla każdego modułu dodaj wszystkie wartości czynników ryzyka i podziel je przez 5. To są ostateczne wartości, z którymi będziemy mieć do czynienia. Powiedzmy, że są to uśrednione czynniki ryzyka:
Im większy jest czynnik ryzyka, tym bardziej moduł musi być testowany.
java dodając elementy do tablicy
Zatem moduły 5 i 2 są najważniejsze dla sukcesu firmy. Udostępnij wyniki wszystkim zespołom.
Krok 6)
Plan łagodzenia ryzyka : To jest krok, który zmienia się z projektu na projekt. Zidentyfikowaliśmy, że moduły 5 i 2 to te, na których należy się najbardziej skoncentrować.
Przykładyplanu może być:
- Moduły 5 i 2 zostaną dokładnie przetestowane, upewniając się, że wszystkie związane z nimi przypadki testowe zostały przetestowane. Pozostałe moduły zostaną przetestowane na podstawie eksploracyjnej.
- Najpierw przetestowane zostaną moduły 5 i 2, a następnie w zależności od dostępnego czasu zajmiemy się innymi.
Po wykonaniu planu wszystkie zespoły osiągają porozumienie i postępują zgodnie z nim, aby przetestować produkt, biorąc pod uwagę czynnik ryzyka.
Otóż to!
Kilka ważnych punktów, na które należy zwrócić uwagę:
- Ponieważ jest to zbiorowe działanie, które trwa pod uwagę wszystkich opinii ; szanse na to, że będzie on dokładny i skuteczny, są większe.
- To jest nie jest to formalna metoda i nie musi być częścią każdego projektu kontroli jakości.
- Czasami, nawet jeśli zespół zdecyduje się nie rysować tabel i przypisywać wartości: a prosta sesja burzy mózgów z każdym obecnym może dać zespołowi ds. kontroli jakości dobre wskazówki dotyczące dalszego postępowania.
- Plik wkład zespołu programistów jest bardzo ważne, ponieważ to oni tworzą produkt, więc będą wiedzieć, co może zadziałać, a co może wymagać dodatkowego sprawdzenia. Uważaj na to.
- Mimo że proces ten składa się z wielu etapów, ich wykonanie nie zajmuje dużo czasu . Zwłaszcza, jeśli wszystkie zespoły mogą siedzieć razem i pracować jednocześnie.
- Pamiętaj o tym procesie i jego wyniku tylko alternatywa . Uzyskanie jak największej ilości czasu na testowanie to najlepszy sposób na wykonanie czynności zapewniania jakości.
Wniosek
Podejście do testowania opartego na ryzyku jasno wskazuje, że tester koncentruje się nie tylko na dalszym badaniu defektów, niezależnie od ich wagi i priorytetu. Teraz sytuacja się zmieniła i testerzy muszą działać mądrze i muszą zrozumieć wyraźną „potrzebę klienta i potrzeby użytkownika”.
Muszą dokładnie przestudiować produkt i zrozumieć, która funkcja jest najczęściej wykorzystywana w produkcji, która jest najbardziej krytyczną ścieżką generowania przychodów oraz jak chronić i chronić klientów przed problemami produkcyjnymi i zagrożeniami biznesowymi.
Dlatego podejście RBT jasno edukuje 3 testerów, że samo testowanie wszystkiego lub obszerne testy nie oznaczają, że testowanie jest zakończone lub że produkt nie zawiera żadnych usterek. Skuteczne testowanie w określonym czasie i upewnianie się, że krytyczne i główne wpływy biznesowe są zniwelowane, co jest bardzo ważne dla testera.
Dlatego testowanie oparte na ryzyku jest najbardziej wydajnym narzędziem dla zespołu ds. Kontroli jakości, które prowadzi interesariuszy projektu w oparciu o ryzyko projektowe. Podejście RBT pomaga zespołowi kontroli jakości w ciągłej identyfikacji ryzyka i jego rozwiązaniu, które może zagrozić osiągnięciu ogólnych celów i założeń projektu, a także pomaga w osiągnięciu ostatecznego celu Grupy zapewniania jakości.
P.S. W całym dokumencie używane są zamiennie słowa QA i Testing.
O autorze: Ten artykuł został napisany przez wielu członków zespołu STH - Gayathri Subrahmanyam i Swati S.
Gayathri jest MŚP zajmującym się testowaniem oprogramowania z ponad dwudziestoletnim doświadczeniem w testowaniu oprogramowania i szeroko przyjął podejście „testowania opartego na ryzyku” jako część procesu industrializacji testów w kilku zadaniach i zdał sobie sprawę z korzyści płynących z optymalizacji zasobów testowych i testowania jakości.
Czy testowanie oparte na ryzyku było dla Ciebie wyzwaniem? Czy masz jakieś ciekawe fakty do dodania do naszego samouczka? Zapraszam do wyrażenia swoich przemyśleń w sekcji komentarzy poniżej !!
=> Odwiedź tutaj, aby zapoznać się z pełną serią samouczków dotyczących planu testów
rekomendowane lektury
- Proces ciągłej integracji: jak poprawić jakość oprogramowania i zmniejszyć ryzyko
- Analiza trybu awarii i skutków (FMEA) - jak analizować ryzyko w celu uzyskania lepszej jakości oprogramowania i zadowolonych klientów!
- Kompletny przewodnik po testowaniu opartym na ryzyku: zarządzanie ryzykiem w testowaniu oprogramowania
- 10 najlepszych narzędzi i technik oceny i zarządzania ryzykiem
- Rodzaje zagrożeń w projektach oprogramowania
- Kilka interesujących pytań do rozmowy kwalifikacyjnej dotyczącej testowania oprogramowania
- Wybór testowania oprogramowania jako swojej kariery
- Opinie i recenzje dotyczące kursu testowania oprogramowania