Feilmodus og effektanalyse (FMEA) - Hvordan analysere risikoen for bedre programvarekvalitet og fornøyde kunder!

failure mode effects analysis how analyze risks

Feilmodus og effektanalyse (FMEA) er en risikostyringsteknikk.

Hvis det implementeres riktig, kan dette være et flott tillegg til det beste Kvalitetssikringsprosesser som skal følges. I denne artikkelen er vårt mål å introdusere deg for denne risikoanalyseteknikken, som til slutt er veldig nyttig for å forbedre programvarekvaliteten.

Hva du vil lære:

• Feilmodus og effektanalyse
• Hva er risikoanalyse?
• Feilmodus Effektanalyseeksempel
• FMEA og grad av testing
• Konklusjon
• Anbefalt lesing

Feilmodus og effektanalyse

FMEA brukes mest av øvre ledelse eller interessenter. I praksis får testerne lite innblikk i denne teknikken. Men nå er trenden i endring, og jeg føler at hvis testerne forstår dette konseptet ordentlig, kan de drive tankeprosessen deres av skrive prøvesaker til ett nivå opp ved å bruke denne teknikken til å:

• Forstå interessentens mål om å teste applikasjonen.
• Forstå virksomheten.
• Utled testnivåer på høyt nivå basert på forretnings- og ledelsesinteresse.
• Utled effektive testtilfeller som gir bedre dekning til de risikoutsatte områdene.
• Prioriter testtilfellene.
• Bestem hva du skal teste og hva du skal utsette i enhver fase.
  

Bakgrunn

gode nettsteder for å se anime gratis

RISIKOANALYSE er et avgjørende aspekt av Testledelse . Spørsmålet oppstår da - Hva er risikoanalyse? Og hvorfor er det viktig? For å forstå dette er det viktig å forstå - hva er RISIKO?

Se også => Typer av risikoer i programvareprosjekter.

RISIKO som sin bokstavelige betydning er en mulighet for et negativt eller uønsket utfall eller en hendelse. Risiko hvis den ikke håndteres eller håndteres riktig, kan føre til dårlig kvalitet, misfornøyde kunder og noen ganger tap av virksomhet.

Risiko har to attributter:

• Sannsynlighet
• innvirkning

Sannsynlighet betyr sjansene for at en bestemt risiko oppstår og påvirkning betyr omfanget av risikoen.

Hva er risikoanalyse?

Risikoanalyse er en mekanisme der de identifiserte potensielle risikoene blir analysert og studert grundig for å finne sannsynlighet og innvirkning. Det anbefales å måle de to attributtene, og basert på resultatet identifiserer vi:

• Hva skal jeg teste først?
• Hva skal jeg teste mer?
• Hva ikke å teste (Denne gangen)?

Det er mange metoder for å gjøre risikoanalysen, og de er stort sett klassifisert i to typer:

• Uformelle teknikker : Disse er basert på erfaring, skjønn og intuisjon.
• Formelle teknikker : Identifisere og veie risikoattributter.

F sykdom M ode og ER fekter TIL nalyse (FMEA): Dette er en formell metode for å gjøre en risikoanalyse. I de følgende avsnittene vil jeg diskutere mer om FMEA og prøv å utdype det med eksemplet.

FMEA er en formell teknikk for å gjøre risikoanalyse. Det er et systematisk og kvantitativt verktøy i form av et regneark som hjelper medlemmene med å analysere hva som kan bli galt. For å gjøre FMEA krever vi de rette personene på bordet. Det krever en representant fra alle bransjer, inkludert kunder.

Beskrivelse

FMEA starter og fortsetter med idédugnad. Deltakerne må identifisere alle komponentene, modulene, avhengighetene, begrensningene som kan mislykkes i et produksjonsmiljø og til slutt føre til dårlig kvalitet, pålitelighet og kan føre til tap av virksomhet.

Under FMEA identifiserer vi ikke bare omfanget av tapet, men prøver også å identifisere årsaken til disse feilene. For å måle FMEA trenger vi tre attributter:

• Alvorlighetsgrad av svikt (S)
• Prioritet av feilen (P)
• Sannsynlighet av svikt (L)

Vi setter hver av disse attributtene i en skala vist nedenfor:

Alvorlighetsskala:

Prioritetsskala:

Sannsynlighetsskala:

Alle disse tre attributtene (alvorlighetsgrad, prioritet og sannsynlighet) måles individuelt i skala og deretter multipliseres for å få en Risikoprioritetsnummer (RPN).

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

Basert på denne RPN-verdien bestemmer vi omfanget av testingen. Mindre er RPN, høyere er risikoen.

La oss prøve å forstå det med et eksempel:

Feilmodus Effektanalyseeksempel

(Dette er et hypotetisk eksempel bare for et forståelsesformål. Faktisk implementering og funksjoner kan variere)

La oss se på et enkelt eksempel på en banksøknad som har fire funksjoner.

• Funksjon 1: Ta ut
• Funksjon 2: Innskudd
• Funksjon 3: Hjemmelån
• Funksjon 4: Faste innskudd.

Det blir dannet et risikoanalyseteam som består av banksjefen, UAT Test Manager (som representerer sluttbruker), teknisk arkitekt, testarkitekt, nettverksadministrator, DBA og en prosjektleder.

gratis menighetsadministrasjonsprogramvare fullversjon

Etter en serie idédugnader kom teamet opp med følgende risikoer:

• Kompleks forretningslogikk i tilfelle beregning av renten på boliglånet.
• Systemet mislykkes med 200 samtidige brukere.
• Systemet klarer ikke å håndtere dokumenter som er mer enn 6 MB.

La oss nå prøve å beregne alvorlighetsgraden, prioriteten og sannsynligheten for disse identifiserte risikoene.

Alvorlighetsgrad:

Prioritet:

Sannsynlighet:

La oss nå sette sammen alle disse attributtene:

La oss nå beregne risikoprioritetsnummeret (RPN = alvorlighetsgrad * prioritet * sannsynlighet)

Nå er nøkkelen: Lavere er RPN - Høyere er risikoen.

Så her for dette spesifikke eksemplet har Feature 1 (kompleks forretningslogikk i tilfelle beregning av renten på boliglånet) den høyeste risikoen og funksjon 2 (System mislykkes ved 200 brukere samtidig) har den laveste risikoen.

Hvordan bruker jeg dette for å utlede testtilfeller?

Siden Funksjon 1 er den mest risikable funksjonen skal prøvesakene være grundige og grundigere. Skriv testtilfellene for å dekke full funksjonalitet og påvirke moduler av funksjonen. Bruk alle slags teknikker for skrivesaker ( Equivalence Partitioning og BVA , Årsak og virkning graf , Statlig overgangsdiagram ) for å utlede prøvesakene.

Testtilfellene skal ikke bare være funksjonelle, men også ikke-funksjonelle ( Lastetest , Stress og volumtest osv.). I utgangspunktet må vi gjøre uttømmende testing av denne funksjonen, så baser testsakene dine deretter. Vurder også alle avhengige moduler på denne viktige funksjonen.

Funksjon 2 er den MINST RISIKO-funksjon , så baser testsakene dine på den viktigste funksjonaliteten. Bare testnivåer på høyt nivå for å validere at funksjonen fungerer som forventet, burde være tilstrekkelig.

Funksjon 3 er en MODERAT RISIKO-funksjon , så baser testtilfellene dine for å dekke alle de viktigste og avhengige funksjonalitetene. Skriv noen BVA-testtilfeller for å validere noen få negative scenarier også. Omfanget av testtilfellene bør være mellom høy risiko og lav risikofaktor. Hvis nødvendig, inkluder også få ikke-funksjonelle testtilfeller.

FMEA og grad av testing

Basert på RPN-verdien, bestemmer vi omfanget eller graden av testing som skal utføres.

Normalt hvis:

• RPN er mellom 1-10, vi gjør omfattende testing (dekker inn og ut av funksjonen / modulen)
• RPN er mellom 11-30, vi gjør balansert testing (dekker alle hovedfunksjonalitetene til funksjonen / modulen)
• RPN er mellom 31-70, vi gjør Opportunity testing (dekker den grunnleggende funksjonaliteten til funksjonen / modulen)
• RPN er mer enn 70 - Ingen testing eller når tiden tillater det, bare rapportering av uregelmessigheter.

Disse områdene eller tallene er ikke begrenset til de jeg nevnte ovenfor. De kan variere avhengig av prosjektets art.

Ressurser: nedlasting FMEA-programvare og FMEA-mal .

Konklusjon

Risikoanalyse ved bruk av FMEA krever tid og erfaring. Ønskede resultater kan bare oppnås ved like deltakelse fra alle ansvarlige teammedlemmer. Selv om denne teknikken er formell, krever den en serie idédugnad, og det er like viktig å dokumentere alle identifiserte risikoer.

hvordan du returnerer strengarray i java

Siden de fleste applikasjonene er eksklusive, er skalaen for å måle parametrene til FMEA (dvs. Prioritet, Alvorlighet og Sannsynlighet) også avhengig av applikasjonen. Hvis det gjøres på riktig måte, er det mange fordeler med FMEA-teknikken. Den kan brukes til å identifisere potensielle risikoer, og basert på dette teamet kan planlegge en effektiv avbøtingsstrategi.

Om forfatteren: Dette er en gjesteartikkel av Shilpa Chatterjee Roy. Hun jobber innen programvaretesting de siste 8,5 årene på forskjellige domener.

Hvis du har brukt denne teknikken, kan du gjerne kommentere opplevelsen din nedenfor.

Anbefalt lesing

• Typer av risikoer i programvareprosjekter
• Hva er kvalitetsattributtene?
• Test dine analysefunksjoner og tenkekraft - Programvare-testøvelser (del 2)
• Gjensidig forståelse i testing: en nøkkel for å levere kvalitetsprogramvare
• Hva er programvarekvalitetssikring (SQA): en guide for nybegynnere
• Kontinuerlig integrasjonsprosess: Hvordan forbedre programvarekvaliteten og redusere risikoen
• Forskjellen mellom kvalitetssikring og kvalitetskontroll (QA vs QC)
• Topp 8 BESTE Loggstyringsprogramvare | Logganalyseverktøy gjennomgang 2021