failure mode effects analysis how analyze risks
Fejltilstand og effektanalyse (FMEA) er en risikostyringsteknik.
Hvis det implementeres korrekt, kan dette være en god tilføjelse til det bedste Kvalitetssikringsprocesser der skal følges. I denne artikel er vores mål at introducere dig til denne risikoanalyseteknik, som i sidste ende er meget nyttig til forbedring af softwarekvaliteten.
Hvad du lærer:
- Fejltilstand og effektanalyse
- Hvad er risikoanalyse?
- Eksempel på analyse af effektfejltilstand
- FMEA og graden af testning
- Konklusion
- Anbefalet læsning
Fejltilstand og effektanalyse
FMEA bruges hovedsageligt af øverste ledelse eller interessenter. I praksis får testerne lidt indsigt i denne teknik. Men nu ændrer tendensen sig, og jeg føler, at hvis testerne forstår dette koncept ordentligt, kan de køre deres tankeproces af skriver prøvesager til et niveau op ved at bruge denne teknik til at:
- Forstå interessentens mål om at teste applikationen.
- Forstå forretningen.
- Udled testscenarier på højt niveau baseret på forretnings- og ledelsesinteresse.
- Udled effektive testtilfælde, der giver bedre dækning til de risikobetonede områder.
- Prioriter testsagerne.
- Beslut hvad du skal teste og hvad man skal udsætte i enhver fase.
Baggrund
RISIKOANALYSE er et afgørende aspekt af Test Management . Spørgsmålet opstår derefter - Hvad er risikoanalyse? Og hvorfor er det vigtigt? For at forstå dette er det vigtigt at forstå - hvad er RISIKO?
Se også => Typer af risici i softwareprojekter.
hvilken proces kræver automatiske builds og test for at verificere software under udvikling
RISIKO som dets bogstavelige betydning er en mulighed for et negativt eller uønsket resultat eller begivenhed. Risici, hvis de ikke håndteres eller håndteres korrekt, kan føre til dårlig kvalitet, utilfredse kunder og undertiden tab af forretning.
Risiko har to attributter:
- Sandsynlighed
- Indvirkning
Sandsynlighed betyder chancerne for, at en bestemt risiko opstår, og påvirkning betyder omfanget af risikoen.
Hvad er risikoanalyse?
Risikoanalyse er en mekanisme, hvormed de identificerede potentielle risici analyseres og undersøges grundigt for at finde sandsynligheden og effekten. Det tilrådes at måle de to attributter og baseret på det resultat, vi identificerer:
- Hvad skal jeg teste først?
- Hvad skal jeg teste mere?
- Hvad ikke at teste (denne gang)?
Der er mange metoder til at udføre risikoanalysen, og de klassificeres bredt i to typer:
- Uformelle teknikker : Disse er baseret på erfaring, dømmekraft og intuition.
- Formelle teknikker : Identificering og afvejning af risikoattributter.
F lidelse M ode og ER ffekter TIL nalyse (FMEA): Dette er en formel metode til at foretage en risikoanalyse. I de følgende afsnit vil jeg diskutere mere om FMEA og prøv at uddybe det med eksemplet.
FMEA er en formel teknik til risikoanalyse. Det er et systematisk og kvantitativt værktøj i form af et regneark, der hjælper medlemmerne med at analysere, hvad der kan gå galt. For at gøre FMEA kræver vi de rigtige mennesker på bordet. Det kræver en repræsentant fra alle samfundslag inklusive kunder.
Beskrivelse
FMEA starter og fortsætter med Brainstorming-sessioner. Deltagerne skal identificere alle komponenter, moduler, afhængigheder, begrænsninger, der kan mislykkes i et produktionsmiljø og til sidst føre til dårlig kvalitet, pålidelighed og kan resultere i tab af forretning.
Under FMEA identificerer vi ikke kun omfanget af tabet, men vi prøver også at identificere årsagen til disse fejl. For at måle FMEA kræver vi 3 attributter:
- Alvorlighed af svigt (S)
- Prioritet af svigt (P)
- Sandsynlighed af svigt (L)
Vi sætter hver af disse attributter i en skala vist nedenfor:
Alvorlighedsskala:
Beskrivelse | Klasse | vægt |
Tab af data, hardware eller sikkerhedsproblemer | Presserende | en |
Tab af funktionalitet uden en løsning | Høj | to |
Tab af funktionalitet med en løsning | Medium | 3 |
Delvis tab af funktionalitet | Lav | 4 |
Kosmetisk eller trivielt | Ingen | 5 |
Prioritetsskala:
Beskrivelse | Klasse | vægt |
Komplet tab af systemværdi | Presserende | en |
Uacceptabelt tab af systemværdi | Høj | to |
Eventuelt reduktion i systemværdien | Medium | 3 |
Acceptabel reduktion af systemværdien | Lav | 4 |
En ubetydelig reduktion i systemværdien | Ingen | 5 |
Sandsynlighedsskala:
Beskrivelse | Klasse | vægt |
Visst at påvirke alle brugere | Presserende | en |
Sandsynligvis at påvirke nogle brugere | Meget høj | to |
Mulig indvirkning på nogle brugere | Høj | 3 |
Begrænset påvirkning af nogle få brugere | Lav | 4 |
Ufattelig i faktisk brug | Ingen | 5 |
Alle disse tre attributter (sværhedsgrad, prioritet og sandsynlighed) måles individuelt i skala og ganges derefter for at få en Risikoprioritetsnummer (RPN).
dvs. Risikoprioritetsnummer ( RPN) = S * P * L
Baseret på denne RPN-værdi bestemmer vi testens omfang. Mindre er RPN, højere er risikoen.
Lad os prøve at forstå det med et eksempel:
Eksempel på analyse af effektfejltilstand
(Dette er kun et hypotetisk eksempel for et forståelsesformål. Faktisk implementering og funktioner kan variere)
Lad os overveje et simpelt eksempel på en bankapplikation, der har 4 funktioner.
- Funktion 1: Træk dig tilbage
- Funktion 2: Depositum
- Funktion 3: Boliglån
- Funktion 4: Faste indskud.
Der oprettes et risikoanalyseteam, der består af bankchefen, UAT Test Manager (repræsenterer slutbruger), teknisk arkitekt, testarkitekt, netværksadministrator, DBA og en projektleder.
Efter en række brainstormingsessioner kom teamet op med følgende risici:
- Kompleks forretningslogik i tilfælde af beregning af renten på boliglånet.
- Systemet mislykkes ved 200 samtidige brugere.
- Systemet håndterer ikke dokumenter, der er mere end 6 MB.
Lad os nu prøve at beregne sværhedsgraden, prioriteten og sandsynligheden for disse identificerede risici.
Alvorlighed:
c ++ eksempel på regulært udtryk
Funktion | Klasse | vægt |
Kompleks forretningslogik i tilfælde af beregning af renten på boliglån | Meget høj | to |
Systemet mislykkes ved 200 samtidige brugere | Høj | 3 |
Systemet håndterer ikke dokumenter, der er mere end 6 MB | Meget høj | to |
Prioritet:
Funktion | Klasse | vægt |
Kompleks forretningslogik i tilfælde af beregning af renten på boliglån | Meget høj | to |
Systemet mislykkes ved 200 samtidige brugere | Høj | 3 |
Systemet håndterer ikke dokumenter, der er mere end 6 MB | Høj | 3 |
Sandsynlighed:
Funktion | Klasse | vægt |
Kompleks forretningslogik i tilfælde af beregning af renten på boliglån | Høj | 3 |
Systemet mislykkes ved 200 samtidige brugere | Høj | 3 |
Systemet håndterer ikke dokumenter, der er mere end 6 MB | Lav | 4 |
Lad os nu samle alle disse attributter:
Funktion | Alvorlighed | Prioritet | Sandsynlighed |
Kompleks forretningslogik i tilfælde af beregning af renten på boliglån | to | to | 3 |
Systemet mislykkes ved 200 samtidige brugere | 3 | 3 | 3 |
Systemet håndterer ikke dokumenter, der er mere end 6 MB | to | 3 | 4 |
Lad os nu beregne risikoprioritetsnummeret (RPN = Alvorlighed * Prioritet * Sandsynlighed)
Funktion | Alvorlighed | Prioritet | Sandsynlighed | RPN |
Kompleks forretningslogik i tilfælde af beregning af renten på boliglån | to | to | 3 | 12 |
Systemet mislykkes ved 200 samtidige brugere | 3 | 3 | 3 | 27 |
Systemet håndterer ikke dokumenter, der er mere end 6 MB | to | 3 | 4 | 24 |
Nu er nøglen: Lavere er RPN - Højere er risikoen.
Så her for dette særlige eksempel har Feature 1 (kompleks forretningslogik i tilfælde af beregning af renten på boliglånet) den højeste risiko, og funktion 2 (System mislykkes ved 200 samtidige brugere) har den laveste risiko.
Hvordan bruges dette til at udlede testsager?
Siden Funktion 1 er mest risikable funktion skal testsagerne være stringente og mere dybtgående. Skriv testcases for at dække komplet funktionalitet og påvirke moduler af funktionen. Brug alle mulige testteknikker til testsager ( Ækvivalenspartitionering og BVA , Årsag og virkning graf , Diagram over tilstandsovergang ) for at udlede testsagerne.
Testcases skal ikke kun være funktionelle, men også ikke-funktionelle ( Belastningstest , Stress og volumen test osv.). Dybest set er vi nødt til at udføre udtømmende test af denne særlige funktion, så baser dine testsager i overensstemmelse hermed. Overvej også alle de afhængige moduler til denne vigtige funktion.
Funktion 2 er MINDSTE RISIKO-funktion , så baser dine testsager på den største funktionalitet. Bare testsager på højt niveau for at validere, at funktionen fungerer som forventet, skal være tilstrækkelig.
Funktion 3 er en MODERERET RISIKO-funktion , så baser dine testsager for at dække alle de vigtigste og afhængige funktioner. Skriv nogle BVA-testsager for også at validere et par negative scenarier. Omfanget af testsagerne skal være mellem højrisiko- og lavrisikofaktor. Om nødvendigt inkluder også få ikke-funktionelle testtilfælde.
FMEA og graden af testning
Baseret på RPN-værdien bestemmer vi omfanget eller graden af test, der skal udføres.
Normalt hvis:
- RPN er mellem 1-10, vi udfører omfattende test (dækker ind og ud af funktionen / modulet)
- RPN er mellem 11-30, vi laver afbalanceret test (dækker alle de vigtigste funktioner i funktionen / modulet)
- RPN er mellem 31-70, vi foretager test af muligheder (dækker funktionens / modulets grundlæggende funktionalitet)
- RPN er mere end 70 - Ingen test, eller når tiden tillader det, kun rapportering om uregelmæssigheder.
Disse intervaller eller tal er ikke begrænset til dem, jeg nævnte ovenfor. De kan variere alt efter projektets art.
Ressourcer: Hent FMEA-software og FMEA-skabelon .
Konklusion
Risikoanalyse ved hjælp af FMEA kræver tid og erfaring. Ønskede resultater kan kun opnås ved lige deltagelse fra alle ansvarlige teammedlemmer. Selvom denne teknik er formel, kræver den en række brainstorming-sessioner, og det er lige så vigtigt at dokumentere alle de identificerede risici.
hvordan man kører en jar-fil i windows
Da de fleste af applikationerne er eksklusive, afhænger skalaen til måling af parametrene for FMEA (dvs. Prioritet, Alvorlighed og Sandsynlighed) også af applikationen. Hvis det gøres korrekt, er der mange fordele ved FMEA-teknikken. Det kan bruges til at identificere potentielle risici og kan på basis af dette team planlægge en effektiv afbødningsstrategi.
Om forfatteren: Dette er en gæsteartikel af Shilpa Chatterjee Roy. Hun arbejder i softwaretestfeltet i de sidste 8,5 år inden for forskellige domæner.
Hvis du har brugt denne teknik, er du velkommen til at kommentere din oplevelse nedenfor.
Anbefalet læsning
- Typer af risici i softwareprojekter
- Hvad er kvalitetsattributterne?
- Test dine analysefunktioner og tænkekraft - Software-testøvelser (del 2)
- Gensidig forståelse i testning: En nøgle til levering af kvalitetssoftware
- Hvad er softwarekvalitetssikring (SQA): En guide til begyndere
- Kontinuerlig integrationsproces: Sådan forbedres softwarekvaliteten og reducerer risikoen
- Forskellen mellem kvalitetssikring og kvalitetskontrol (QA vs QC)
- Top 8 BEDSTE Loghåndteringssoftware | Loganalyseværktøjsanmeldelse 2021