Analiza trybów awarii i skutków (FMEA) - jak analizować ryzyko, aby uzyskać lepszą jakość oprogramowania i zadowolonych klientów!

failure mode effects analysis how analyze risks

Analiza trybów i skutków awarii (FMEA) jest techniką zarządzania ryzykiem.

Jeśli zostanie odpowiednio wdrożony, może być świetnym dodatkiem do najlepszych Procesy zapewnienia jakości być śledzonym. W tym artykule naszym celem jest wprowadzenie w tę technikę analizy ryzyka, która ostatecznie jest bardzo przydatna do poprawy jakości oprogramowania.

Czego się nauczysz:

• Analiza trybów i skutków awarii
• Co to jest analiza ryzyka?
• Przykład analizy skutków trybu awarii
• FMEA i stopień testowania
• Wniosek
• rekomendowane lektury

Analiza trybów i skutków awarii

FMEA jest najczęściej używane przez wyższe kierownictwo lub interesariuszy. W praktyce testerzy mają niewielki wgląd w tę technikę. Ale teraz trend się zmienia i czuję, że jeśli testerzy dobrze rozumieją tę koncepcję, mogą kierować procesem myślowym pisanie przypadków testowych o jeden poziom wyżej, wykorzystując tę ​​technikę do:

• Zrozum cele interesariuszy związane z testowaniem aplikacji.
• Zrozum biznes.
• Opracuj scenariusze testów wysokiego poziomu w oparciu o interesy biznesowe i kierownicze.
• Wyprowadź skuteczne przypadki testowe, które zapewniają lepsze pokrycie obszarów narażonych na ryzyko.
• Ustal priorytety przypadków testowych.
• Zdecyduj, co przetestować i co odłożyć na dowolnym etapie.
  

tło

ANALIZA RYZYKA jest kluczowym aspektem Zarządzanie testami . Powstaje wtedy pytanie - Co to jest analiza ryzyka? Dlaczego jest to ważne? Aby to zrozumieć, konieczne jest zrozumienie - co to jest RYZYKO?

Zobacz także => Rodzaje zagrożeń w projektach oprogramowania.

RYZYKO jako jego dosłowne znaczenie to możliwość negatywnego lub niepożądanego wyniku lub zdarzenia. Ryzyko, jeśli nie jest odpowiednio obsługiwane lub zarządzane, może prowadzić do niskiej jakości, niezadowolenia klientów, a czasem utraty biznesu.

Ryzyko ma 2 atrybuty:

• Prawdopodobieństwo
• Wpływ

Prawdopodobieństwo oznacza szanse wystąpienia określonego ryzyka, a wpływ oznacza zakres skutków ryzyka.

Co to jest analiza ryzyka?

Analiza ryzyka to mechanizm, za pomocą którego zidentyfikowane potencjalne ryzyka są dokładnie analizowane i badane w celu określenia prawdopodobieństwa i wpływu. Wskazane jest zmierzenie tych dwóch atrybutów i na podstawie zidentyfikowanego wyniku:

• Co najpierw przetestować?
• Co testować więcej?
• Czego nie testować (tym razem)?

Istnieje wiele metod przeprowadzania analizy ryzyka i można je ogólnie podzielić na dwa typy:

• Nieformalne techniki : Są oparte na doświadczeniu, osądzie i intuicji.
• Formalne techniki : Identyfikowanie i ważenie atrybutów ryzyka.

fa dolegliwość M oda i JEST ffects DO nalysis (FMEA): Jest to formalna metoda przeprowadzania analizy ryzyka. W następnych sekcjach omówię więcej FMEA i spróbuj rozwinąć ją na przykładzie.

FMEA to formalna technika przeprowadzania analizy ryzyka. Jest to systematyczne i ilościowe narzędzie w postaci arkusza kalkulacyjnego, które pomaga członkom analizować, co może się nie udać. Aby wykonać FMEA, potrzebujemy odpowiednich ludzi na stole. Wymaga przedstawiciela ze wszystkich środowisk, w tym klientów.

Opis

FMEA rozpoczyna się i kontynuuje sesje burzy mózgów. Uczestnicy muszą zidentyfikować wszystkie komponenty, moduły, zależności, ograniczenia, które mogą zawieść w środowisku produkcyjnym i ostatecznie doprowadzić do niskiej jakości, niezawodności i mogą spowodować utratę biznesu.

Podczas FMEA nie tylko identyfikujemy rozmiar szkody, ale także staramy się zidentyfikować przyczyny tych awarii. Aby zmierzyć FMEA, potrzebujemy 3 atrybutów:

• Surowość Awarii (S)
• Priorytet Awarii (P)
• Prawdopodobieństwo Awarii (L)

Każdy z tych atrybutów umieszczamy w poniższej skali:

Skala ważności:

Skala priorytetów:

Skala prawdopodobieństwa:

Wszystkie te trzy atrybuty (dotkliwość, priorytet i prawdopodobieństwo) są indywidualnie mierzone w skali, a następnie mnożone, aby uzyskać Numer priorytetu ryzyka (RPN).

to znaczy Numer priorytetu ryzyka ( RPN) = S * P * L

Na podstawie tej wartości RPN określamy zakres testów. Mniejszy jest RPN, wyższe jest ryzyko.

Spróbujmy to zrozumieć na przykładzie:

Przykład analizy skutków trybu awarii

(To jest hipotetyczny przykład wyłącznie w celu zrozumienia. Rzeczywista implementacja i funkcje mogą się różnić)

Rozważmy prosty przykład aplikacji bankowej, która ma 4 funkcje.

• Cecha 1: Wycofać
• Cecha 2: Kaucja
• Cecha 3: Pożyczka na dom
• Cecha 4: Stałe depozyty.

Tworzony jest Zespół Analizy Ryzyka, w skład którego wchodzą Menedżer Banku, UAT Kierownik testów (reprezentujący użytkownika końcowego), architekt techniczny, architekt testów, administrator sieci, DBA i kierownik projektu.

Po serii burzy mózgów zespół wymyślił plik następujące ryzyka:

• Złożona logika biznesowa w przypadku obliczania oprocentowania kredytu mieszkaniowego.
• System zawiedzie przy 200 jednoczesnych użytkownikach.
• System nie obsługuje dokumentów, których rozmiar przekracza 6 MB.

Spróbujmy teraz obliczyć wagę, priorytet i prawdopodobieństwo tych zidentyfikowanych zagrożeń.

Surowość:

Priorytet:

Prawdopodobieństwo:

Pobieranie biblioteki standardowej c ++

Teraz połączmy wszystkie te atrybuty:

Teraz obliczmy numer priorytetu ryzyka (RPN = waga * priorytet * prawdopodobieństwo)

Teraz kluczem jest: Niższy RPN - wyższe ryzyko.

Zatem w tym konkretnym przykładzie cecha 1 (złożona logika biznesowa w przypadku obliczania oprocentowania kredytu mieszkaniowego) ma najwyższe ryzyko, a funkcja 2 (awaria systemu przy 200 jednoczesnych użytkownikach) ma najniższe ryzyko.

Jak to wykorzystać do wyprowadzenia przypadków testowych?

Od Cecha 1 jest najbardziej ryzykowna funkcja przypadki testowe powinny być rygorystyczne i bardziej szczegółowe. Napisz przypadki testowe, które obejmują pełną funkcjonalność i wpływają na moduły przez funkcję. Używaj wszelkiego rodzaju technik pisania przypadków testowych ( Podział równoważności i BVA , Wykres przyczyny i skutku , Diagram zmian stanów ) do wyprowadzenia przypadków testowych.

Przypadki testowe powinny być nie tylko funkcjonalne, ale także niefunkcjonalne ( Test obciążenia , Test obciążenia i objętości itp.). Zasadniczo musimy przeprowadzić wyczerpujące testy tej konkretnej funkcji, więc odpowiednio oprzyj swoje przypadki testowe. Weź również pod uwagę wszystkie zależne moduły tej ważnej funkcji.

Cecha 2 jest Funkcja NAJMNIEJ RYZYKA , więc oprzyj swoje przypadki testowe na głównej funkcjonalności. Wystarczające powinny być tylko przypadki testowe wysokiego poziomu, aby sprawdzić, czy funkcja działa zgodnie z oczekiwaniami.

Cecha 3 jest Funkcja UMIARKOWANE RYZYKO , więc oprzyj swoje przypadki testowe tak, aby obejmowały wszystkie główne i zależne funkcje. Napisz kilka przypadków testowych BVA, aby zweryfikować również kilka negatywnych scenariuszy. Zakres przypadków testowych powinien mieścić się w przedziale od wysokiego ryzyka do niskiego ryzyka. W razie potrzeby dołącz również kilka niefunkcjonalnych przypadków testowych.

FMEA i stopień testowania

Na podstawie wartości RPN określamy zakres lub stopień testowania do wykonania.

Zwykle, jeśli:

• RPN mieści się w przedziale 1-10, przeprowadzamy obszerne testy (obejmowanie funkcji / modułu i poza nią)
• RPN jest między 11 a 30, wykonujemy testy zrównoważone (obejmujące wszystkie główne funkcje funkcji / modułu)
• RPN mieści się w przedziale 31-70, przeprowadzamy testy możliwości (obejmujące podstawową funkcjonalność funkcji / modułu)
• RPN wynosi więcej niż 70 - brak testów lub, gdy pozwala na to czas, tylko zgłaszanie anomalii.

Te zakresy lub liczby nie są ograniczone do tych, o których wspomniałem powyżej. Mogą się różnić w zależności od charakteru projektu.

Zasoby: Ściągnij Oprogramowanie FMEA i Szablon FMEA .

Wniosek

Analiza ryzyka z wykorzystaniem FMEA wymaga czasu i doświadczenia. Pożądane rezultaty można osiągnąć tylko poprzez równe uczestnictwo wszystkich odpowiedzialnych członków zespołu. Chociaż ta technika jest formalna, wymaga serii burzy mózgów i równie ważne jest udokumentowanie wszystkich zidentyfikowanych zagrożeń.

Ponieważ większość aplikacji ma charakter wyłączny, skala pomiaru parametrów FMEA (tj.Priorytet, Severity i Likelihood) również zależy od aplikacji. Jeśli zostanie to zrobione odpowiednio, technika FMEA ma wiele zalet. Może być używany do identyfikacji potencjalnych zagrożeń i na podstawie tego zespołu może zaplanować skuteczną strategię mitygacji.

O autorze: To jest artykuł gościnny autorstwa Shilpy Chatterjee Roy. Od 8,5 roku zajmuje się testowaniem oprogramowania w różnych dziedzinach.

Jeśli korzystałeś z tej techniki, możesz poniżej skomentować swoje doświadczenie.

rekomendowane lektury

• Rodzaje zagrożeń w projektach oprogramowania
• Jakie są atrybuty jakości?
• Sprawdź swoje możliwości analityczne i moc myślenia - ćwiczenia z testowania oprogramowania (część 2)
• Wzajemne zrozumienie w testowaniu: klucz do dostarczania wysokiej jakości oprogramowania
• Co to jest gwarancja jakości oprogramowania (SQA): przewodnik dla początkujących
• Proces ciągłej integracji: jak poprawić jakość oprogramowania i zmniejszyć ryzyko
• Różnica między zapewnianiem jakości a kontrolą jakości (QA vs QC)
• Top 8 BEST oprogramowania do zarządzania dziennikami | Przegląd narzędzia do analizy dzienników 2021