Meny

Felläge och effektanalys (FMEA) - Hur man analyserar risker för bättre programvarukvalitet och nöjda kunder!

failure mode effects analysis how analyze risks

Prova Vårt Instrument För Att Eliminera Problem

Felläge och effektanalys (FMEA) är en teknik för riskhantering.

Om det implementeras ordentligt kan detta vara ett bra komplement till det bästa Kvalitetssäkringsprocesser att bli följd. I den här artikeln är vårt mål att introducera dig till denna riskanalysteknik som i slutändan är mycket användbar för att förbättra mjukvarukvaliteten.

Felläge och effektanalys (FMEA)

Vad du kommer att lära dig:

Felläge och effektanalys

FMEA används oftast av den översta ledningen eller intressenter. I praktiken får testarna liten inblick i denna teknik. Men nu förändras trenden och jag känner att om testarna förstår detta koncept ordentligt kan de driva deras tankeprocess av skriva testfall till en nivå upp genom att använda denna teknik för att:

  • Förstå intressentens mål att testa ansökan.
  • Förstå verksamheten.
  • Hämta testscenarier på hög nivå baserat på affärs- och ledningsintressen.
  • Få effektiva testfall som ger bättre täckning till de riskbenägna områdena.
  • Prioritera testfallet.
  • Bestäm vad du ska testa och vad man ska skjuta upp i vilken fas som helst.

Bakgrund

RISKANALYS är en avgörande aspekt av Testhantering . Frågan uppstår då - Vad är riskanalys? Och varför är det viktigt? För att förstå detta är det viktigt att förstå - vad är RISK?

riskanalys

Se även => Typer av risker i programvaruprojekt.

hur öppnar jag swf-filer

RISK som dess bokstavliga betydelse är en möjlighet till ett negativt eller oönskat resultat eller händelse. Risker om de inte hanteras eller hanteras ordentligt kan leda till dålig kvalitet, missnöjda kunder och ibland förlust av affärer.

Risk har två attribut:

  • Sannolikhet
  • Påverkan

Sannolikhet betyder risken för att en viss risk inträffar och påverkan betyder omfattningen av riskens effekt.

Vad är riskanalys?

Riskanalys är en mekanism genom vilken de identifierade potentiella riskerna analyseras och studeras grundligt för att hitta sannolikheten och effekten. Det rekommenderas att mäta de två attributen och baserat på resultatet identifierar vi:

  • Vad ska jag testa först?
  • Vad ska jag testa mer?
  • Vad ska man inte testa (den här gången)?

Det finns många metoder för att göra riskanalysen och de klassificeras i stort sett i två typer:

  • Informella tekniker : Dessa är baserade på erfarenhet, omdöme och intuition.
  • Formella tekniker : Identifiera och väga riskattribut.

F sjukdom M ode och ÄR ffekter TILL nalys (FMEA): Detta är en formell metod för att göra en riskanalys. I följande avsnitt kommer jag att diskutera mer om FMEA och försök att utarbeta det med exemplet.

FMEA är en formell teknik för att göra riskanalys. Det är ett systematiskt och kvantitativt verktyg i form av ett Spread Sheet som hjälper medlemmarna att analysera vad som kan bli fel. För att göra FMEA kräver vi rätt personer på bordet. Det kräver en representant från alla delar av branschen inklusive kunder.

Beskrivning

FMEA börjar och fortsätter med Brainstorming-sessioner. Deltagarna måste identifiera alla komponenter, moduler, beroenden, begränsningar som kan misslyckas i en produktionsmiljö och så småningom leda till dålig kvalitet, tillförlitlighet och kan leda till förlust av affärer.

Under FMEA identifierar vi inte bara omfattningen av förlusten utan försöker också identifiera orsaken till dessa fel. För att mäta FMEA behöver vi tre attribut:

  • Allvarlighetsgrad of the Failure (S)
  • Prioritet av misslyckandet (P)
  • Sannolikhet av misslyckandet (L)

Vi lägger var och en av dessa attribut i en skala som visas nedan:

Allvarlighetsskala:

Beskrivning Klass Skala
Förlust av data, hårdvara eller säkerhetsfrågor Brådskande 1
Förlust av funktionalitet utan en lösning Hög två
Förlust av funktionalitet med en lösning Medium 3
Delvis förlust av funktionalitet Låg 4
Kosmetisk eller trivial Ingen 5

Prioritetsskala:

Beskrivning Klass Skala
Fullständig förlust av systemvärde Brådskande 1
Oacceptabelt förlust av systemvärde Hög två
Eventuellt minskning av systemvärdet Medium 3
Acceptabel minskning av systemvärdet Låg 4
En försumbar minskning av systemvärdet Ingen 5

Sannolikhetsskala:

Beskrivning Klass Skala
Visst påverkar alla användare Brådskande 1
Sannolikt att det påverkar vissa användare Väldigt högt två
Möjlig inverkan på vissa användare Hög 3
Begränsad påverkan för ett fåtal användare Låg 4
Oföreställbar vid faktisk användning Ingen 5

Alla dessa tre attribut (svårighetsgrad, prioritet och sannolikhet) mäts individuellt i skala och multipliceras sedan för att få en Riskprioritetsnummer (RPN).

dvs. Riskprioritetsnummer ( RPN) = S * P * L

Baserat på detta RPN-värde bestämmer vi testets omfattning. Mindre är RPN, högre är risken.

Låt oss försöka förstå det med ett exempel:

Exempel på analys av fellägeeffektanalys

(Detta är ett hypotetiskt exempel endast för ett förståeligt ändamål. Verklig implementering och funktioner kan variera)

Låt oss överväga ett enkelt exempel på en bankapplikation som har fyra funktioner.

  • Funktion 1: Dra tillbaka
  • Funktion 2: Deposition
  • Funktion 3: Bostadslån
  • Funktion 4: Fasta insättningar.

Ett riskanalysgrupp bildas som består av bankchefen, UAT Testhanteraren (representerar slutanvändaren), teknisk arkitekt, testarkitekt, nätverksadministratör, DBA och en projektledare.

Efter en serie brainstorming sessioner kom teamet med följande risker:

  • Komplex affärslogik vid beräkning av räntan på bostadslånet.
  • Systemet misslyckas med 200 samtidiga användare.
  • Systemet hanterar inte dokument som är mer än 6 MB.

Låt oss nu försöka beräkna svårighetsgraden, prioriteten och sannolikheten för dessa identifierade risker.

Allvarlighetsgrad:

bästa gratis rengöringsprogramvara för Windows 10
Funktion Klass Skala
Komplex affärslogik vid beräkning av räntan på bostadslån Väldigt högt två
Systemet misslyckas med 200 samtidiga användare Hög 3
Systemet hanterar inte dokument som är mer än 6 MB Väldigt högt två

Prioritet:

Funktion Klass Skala
Komplex affärslogik vid beräkning av räntan på bostadslån Väldigt högt två
Systemet misslyckas med 200 samtidiga användare Hög 3
Systemet hanterar inte dokument som är mer än 6 MB Hög 3

Sannolikhet:

Funktion Klass Skala
Komplex affärslogik vid beräkning av räntan på bostadslån Hög 3
Systemet misslyckas med 200 samtidiga användare Hög 3
Systemet hanterar inte dokument som är mer än 6 MB Låg 4

Låt oss nu sätta ihop alla dessa attribut:

Funktion

Allvarlighetsgrad

Prioritet

Sannolikhet

Komplex affärslogik vid beräkning av räntan på bostadslån två två 3
Systemet misslyckas med 200 samtidiga användare 3 3 3
Systemet hanterar inte dokument som är mer än 6 MB två 3 4

Låt oss nu beräkna riskprioritetsnumret (RPN = svårighetsgrad * prioritet * sannolikhet)

Funktion

Allvarlighetsgrad

Prioritet

Sannolikhet

RPN

Komplex affärslogik vid beräkning av räntan på bostadslån två två 3 12
Systemet misslyckas med 200 samtidiga användare 3 3 3 27
Systemet hanterar inte dokument som är mer än 6 MB två 3 4 24

Nu är nyckeln: Lägre är RPN - Högre är risken.

Så här för detta speciella exempel har Feature 1 (komplex affärslogik vid beräkning av räntan på bostadslånet) den högsta risken och funktion 2 (System misslyckas vid 200 samtidiga användare) har den lägsta risken.

Hur använder jag detta för att få fram testfall?

Eftersom Funktion 1 är riskabla funktionen bör testfallet vara noggrant och mer ingående. Skriv testfallet för att täcka fullständig funktionalitet och påverkar moduler av funktionen. Använd alla typer av testfallstekniker ( Equivalence Partitioning och BVA , Orsak och effektdiagram , Statligt övergångsdiagram ) för att härleda testfallet.

Testfallet bör inte bara vara funktionellt utan också icke-funktionellt ( Ladda test , Stress- och volymtest etc.). I grund och botten måste vi göra en omfattande testning av just den här funktionen, så basera dina testfall i enlighet därmed. Tänk också på alla beroende moduler för den här viktiga funktionen.

Funktion 2 är MINST RISKFunktion , så basera dina testfall på de viktigaste funktionerna. Bara testnivåer på hög nivå för att bekräfta att funktionen fungerar som förväntat borde vara tillräckliga.

Funktion 3 är en MODERATE RISK-funktion , så basera dina testfall för att täcka alla större och beroende funktioner. Skriv några BVA-testfall för att validera några negativa scenarier också. Testfallets omfattning bör ligga mellan hög risk och låg riskfaktor. Om det behövs, inkludera också få icke-funktionella testfall.

FMEA och graden av testning

Baserat på RPN-värdet bestämmer vi omfattningen eller graden av testning som ska göras.

Normalt om:

  • RPN är mellan 1-10, vi gör omfattande testning (täcker in och ut ur funktionen / modulen)
  • RPN är mellan 11-30, vi gör Balanced Testing (täcker alla de viktigaste funktionerna i funktionen / modulen)
  • RPN är mellan 31-70, vi gör Opportunity-testning (täcker funktionens / modulens grundläggande funktionalitet)
  • RPN är mer än 70 - Ingen testning eller när tiden tillåter, bara avvikelserapportering.

Dessa intervall eller siffror är inte begränsade till de som jag nämnde ovan. De kan variera beroende på projektets art.

Resurser: Ladda ner FMEA-programvara och FMEA-mall .

Slutsats

Riskanalys med FMEA kräver tid och erfarenhet. Önskade resultat kan endast uppnås genom lika deltagande från alla ansvariga teammedlemmar. Även om den här tekniken är formell, kräver den en serie brainstorming-sessioner och det är lika viktigt att dokumentera alla identifierade risker.

programvarutestning återupptas för 1 års erfarenhet

Eftersom de flesta applikationer är exklusiva beror även skalan för att mäta parametrarna för FMEA (dvs. Prioritet, svårighetsgrad och sannolikhet) på applikationen. Om det görs på rätt sätt finns det många fördelar med FMEA-tekniken. Den kan användas för att identifiera potentiella risker och baserat på detta team kan man planera en effektiv minskningsstrategi.

Om författaren: Detta är en gästartikel av Shilpa Chatterjee Roy. Hon arbetar inom programvarutestningsområdet de senaste 8,5 åren inom olika domäner.

Om du har använt denna teknik är du välkommen att kommentera din upplevelse nedan.

Rekommenderad läsning

^