guide root cause analysis steps
Denne opplæringen forklarer hva som er grunnårsaksanalyse og forskjellige teknikker for rotårsaksanalyse som fiskebenanalyse og 5 hvorfor teknikk:
RCA (Root Cause Analysis) er en strukturert og effektiv prosess for å finne årsaken til problemer i et Software Project-team. Hvis det utføres systematisk, kan det forbedre ytelsen og kvaliteten på resultatene og prosessene, ikke bare på teamnivå, men også på tvers av organisasjonen.
Denne opplæringen vil hjelpe deg med å definere og effektivisere prosessen med årsaksanalyse i teamet eller organisasjonen.
Denne opplæringen er ment for Delivery Managers, Scrum Masters, Project Managers, Quality Managers, Development Team, Test Team, Information Management Team, Quality Team, Support Team, etc. for å forstå det grunnleggende i Root Cause Analysis og gir maler og eksempler på det. .
Hva du vil lære:
- Hva er årsaksanalyse?
- Root Cause Analysis Process
- Root Cause Analysis Techniques
- Faktorer som forårsaker feil
- Konklusjon
Hva er årsaksanalyse?
RCA (Root Cause Analysis) er en mekanisme for å analysere manglene for å identifisere årsaken. Vi brainstormer, leser og graver feilen for å identifisere om feilen skyldtes “ teste frøken ',' utvikling glipp ”Eller var en“ krav eller design savner ”.
Når RCA er gjort nøyaktig, hjelper det å forhindre feil i senere utgivelser eller faser. Hvis vi finner ut at en mangel skyldtes design glipp , kan vi gå gjennom designdokumentene og kan ta passende tiltak. Tilsvarende hvis vi finner ut at en mangel skyldtes teste frøken , kan vi se gjennom testtilfellene eller beregningene våre, og oppdatere dem deretter.
RCA bør ikke bare være begrenset til å teste feilene. Vi kan også gjøre RCA på produksjonsfeil. Basert på avgjørelsen fra RCA, kan vi forbedre vår Test seng og inkluderer de produksjonsbilletter som regresjonstest tilfeller. Dette vil sikre at mangelen eller lignende mangler ikke gjentas.
Root Cause Analysis Process
RCA brukes ikke bare for mangler rapportert fra et kundeside, men også for UAT-defekter, Unit Testing defects, Business og Operational process-level problems, day-to-day life problems, etc. Dermed brukes den i flere bransjer som Programvaresektor, produksjon, helse, banksektor osv.
Gjennomføring av årsaksanalyse er lik arbeidet til legen som behandler en pasient. Legen vil først forstå symptomene. Deretter vil han referere til laboratorietester for å analysere årsaken til sykdommen.
Hvis årsaken til sykdommen fortsatt er ukjent, vil legen henvise for skanningstester for å forstå nærmere. Han vil fortsette diagnosen og studere til han innsnevrer seg til årsaken til pasientens sykdom. Den samme logikken gjelder for årsaksanalyse utført i enhver bransje.
Så, RCA er rettet mot å finne grunnårsaken og ikke behandle symptomet, ved å følge et bestemt sett med trinn og tilhørende verktøy. Det er forskjellig fra feilanalyse, feilsøking og andre problemløsningsmetoder, ettersom disse metodene prøver å finne løsningen for det spesifikke problemet, men RCA prøver å finne den underliggende årsaken.
Opprinnelse til navnet Root Cause Analysis:
[bilde kilde ]
Blader, stamme og røtter er de viktigste delene av et tre. Blader [Symptom] og stamme [Problem] som er over bakken er synlige, men røtter [Årsak] som er under bakken er ikke synlige og røttene vokser dypere og kan spre seg lenger enn vi forventer. Derfor kalles prosessen med å grave til bunnen av problemet Root Cause Analysis.
Fordeler med rotårsaksanalyse
Nedenfor er noen av fordelene du får:
- Forhindre gjentakelse av det samme problemet i fremtiden.
- Til slutt, reduser antall rapporterte mangler over tid.
- Reduserer utviklingskostnader og sparer tid.
- Forbedre programvareutviklingsprosessen og dermed hjelpe rask levering til markedet.
- Forbedrer kundetilfredshet.
- Øk produktiviteten.
- Finn skjulte problemer i systemet.
- Hjelper kontinuerlig forbedring.
Typer rotårsaker
# 1) Menneskelig årsak: Menneskeskapte feil.
Eksempler:
- Under dyktige.
- Instruksjoner som ikke følges behørig.
- Utførte en unødvendig operasjon.
# 2) Organisatorisk årsak: En prosess som folk bruker for å ta avgjørelser som ikke var riktige.
Eksempler:
- Vage instruksjoner ble gitt fra teamledelsen til teammedlemmene.
- Å velge feil person til en oppgave.
- Overvåkingsverktøy ikke på plass for å vurdere kvaliteten.
# 3) Fysisk årsak: Ethvert fysisk element mislyktes på en eller annen måte.
Eksempler:
- Datamaskinen starter på nytt.
- Serveren starter ikke opp.
- Merkelige eller høye lyder i systemet.
Fremgangsmåte for å gjøre årsaksanalyse
En strukturert og logisk tilnærming er nødvendig for en effektiv rotårsaksanalyse. Derfor er det nødvendig å følge en rekke trinn.
# 1) Form RCA Team
Hvert lag skal ha en dedikert Root Cause Analysis Manager [RCA Manager] som vil samle inn detaljene fra supportteamet og starte oppstartsprosessen for RCA. Han vil koordinere og tildele ressurser som trenger å delta på RCA-møter avhengig av det oppgitte problemet.
Lag som deltar på møtet, bør ha personell fra hvert team [Krav, design, testing, dokumentasjon, kvalitet, support og vedlikehold] som er mest kjent med problemet. Teamet skal også ha folk som er direkte knyttet til mangelen. For eksempel, Supportingeniøren som ga en øyeblikkelig løsning på kunden.
Del problemdetaljene med teamet før du deltar på møtet, slik at de kan gjøre en innledende analyse og komme forberedt. Teammedlemmer samler også informasjon relatert til feilen. Avhengig av hendelsesrapporten, vil hvert lag spore hva som gikk galt med dette scenariet i sine respektive faser. Å være forberedt vil øke effektiviteten i den kommende diskusjonen.
# 2) Definer problemet
Samle inn detaljene i problemet som hendelsesrapporter, bevis (skjermbilde, logger, rapporter osv.), Og studer / analyser deretter problemet ved å stille spørsmålene nedenfor:
- Hva er problemet?
- Hva er hendelsesforløpet som førte til problemet?
- Hvilke systemer var involvert?
- Hvor lenge eksisterte problemet?
- Hva er virkningen av problemet?
- Hvem var involvert og bestemme hvem som skulle intervjues?
Bruk 'SMART' regler for å definere problemet ditt:
- S SPESIFIKK
- M LETTBAR
- TIL CTION-orientert
- R ELEVANT
- T NAVN-BUNDET
# 3) Identifiser rotårsaken
Gjennomføre BRAINSTORMING økt i RCA-teamet som ble dannet for å identifisere årsakene. Bruke Fishbone diagram eller 5 Hvorfor analyse metode eller begge deler for å komme til grunnårsaken / -ene.
RCA-leder bør moderere møtet og sette reglene for idédugnad. For eksempel kan reglene være:
- Kritikk / skylden på andre skal ikke være tillatt.
- Ikke bedøm andres ideer. Ingen ideer er dårlige, de oppmuntrer ville ideer.
- Bygg videre på ideene til andre. Tenk på hvordan du kan bygge videre på andres ideer og gjøre det bedre.
- Gi hver deltaker god tid til å dele sine synspunkter.
- Oppmuntre tanken utenom boksen.
- Behold fokus.
Alle ideer skal registreres. RCA-leder bør tilordne et medlem til å registrere referatet fra møtet og oppdatere RCA-maler.
# 4) Implementere årsak til utbedring (RCCA)
Korrigerende handling innebærer å fikse løsningen ved å identifisere den virkelige årsaken. For å lette dette, må en leveringsleder være til stede som kan bestemme i hvilke versjoner reparasjonen skal implementeres og hva som skal være leveringsdatoen.
RCCA bør implementeres på en slik måte at denne grunnårsaken ikke vil forekomme igjen i fremtiden. Korrigering gitt av supportteamet vil være midlertidig for kundesiden der problemet rapporteres. Når denne løsningen slås sammen til en pågående versjon, må du utføre riktig konsekvensanalyse for å sikre at ingen eksisterende funksjoner blir brutt.
Gi trinnene for å validere reparasjonen og overvåke den implementerte løsningen for å sjekke om løsningen er effektiv.
# 5) Implementere rotårsak forebyggende handling (RCPA)
Teamet må komme med en plan for hvordan en slik lignende sak kan forhindres i fremtiden. For eksempel, Oppdater instruksjonshåndboken, forbedre ferdighetssettet, oppdater sjekklisten for teamvurdering osv. Følg riktige dokumenter om forebyggende handlinger og overvåke om teamet følger de forebyggende tiltakene.
Se dette forskningsoppgave om 'Feilanalyse og forebygging for forbedring av programvareprosesskvalitet' publisert i International Journal of Software Engineering & Applications for å få en ide om hvilke typer feil som er rapportert i hver programvarefase og foreslått forebyggende tiltak for dem.
Informasjonen du får fra RCA kan gå som input til Feilmodus og effektanalyse (FMEA ) for å identifisere punkter der løsningen kan mislykkes.
Implementere Pareto-analyse med årsakene som er identifisert under RCA over en periode, si halvårlig eller kvartalsvis som vil bidra til å identifisere de viktigste årsakene som bidrar til manglene og fokusere på forebyggende handling for dem.
Root Cause Analysis Techniques
# 1) Fiskebenanalyse
Fishbone diagram er et visuelt rotårsak analyseverktøy for å identifisere mulige årsaker til de identifiserte problemene, og det kalles derfor også Cause and Effect diagram. Det lar deg komme ned til den virkelige grunnårsaken til problemet i stedet for å løse symptomet.
Det kalles også Ishikawa Diagram slik det ble opprettet av Dr. Kaoru Ishikawa [en japansk kvalitetskontrollstatistiker]. Det er også kjent som sildbein eller Fishikawa-diagram.
Fiskebenanalyse brukes i analysefasen av seks sigma’s DMAIC tilnærming for problemløsning. Det er en av 7 grunnleggende verktøy for kvalitetskontroll .
Fremgangsmåte for å lage et Fishbone Diagram:
Fishbone diagram ligner skjelettet til en fisk med problemet som danner hodet til fisk og forårsaker dannelse av ryggraden og beinene til fisken.
Følg trinnene nedenfor for å lage et fiskebendiagram:
- Skrive den problem på hodet på fisken .
- Identifiser kategori av årsaker og skriv kl enden av hvert bein [årsak kategori 1, årsak kategori 2 …… årsak kategori N]
- Identifiser primære årsaker under hver kategori og merk den som primær årsak 1, primær årsak 2, primær årsak N.
- Utvid årsakene til sekundære, tertiære og flere nivåer etter behov.
Et eksempel på hvordan et fiskebeindiagram brukes på en programvarefeil (se nedenfor).
Det er mange gratis så vel som betalte verktøy tilgjengelig for å lage et fiskebendiagram. Fishbone-diagrammet i denne opplæringen ble opprettet ved hjelp av ‘ Skapelig ’ online verktøy . Mer informasjon om fiskebeinmaler og verktøy vil bli forklart i vår neste opplæring.
# 2) The 5 Whys-teknikken
5 Hvorfor teknikk ble utviklet av Sakichi Toyoda og ble brukt hos Toyota i produksjonsindustrien. Denne teknikken refererer til en serie spørsmål der hvert svar blir besvart med et hvorfor-spørsmål. Det kan være relatert til hvordan et barn vil stille spørsmål til voksne. Basert på svaret som voksne gir, vil de stille ”hvorfor” spørsmål igjen og igjen til de er fornøyde.
5 Hvorfor teknikk brukes frittstående eller som en del av fiskebenanalyse for å bore ned til årsaken til problemet. Antall trinn er ikke begrenset til 5. Det kan være mindre eller mer enn 5 til diagnosen av problemet har kommet. 5 Hvorfor er relativt en enklere teknikk og raskere måte å komme til grunnårsakene. Det letter rask diagnose for å utelukke symptomene og komme til årsaken.
Suksessen til teknikken avhenger av kunnskapen til personen. Det kan være forskjellige svar på det samme hvorfor-spørsmålet. Så det er viktig å velge riktig retning og fokus i møtet.
Fremgangsmåte for å lage 5 Whys-diagram
Start idédugnadssamtalen ved å definere problemet. Følg deretter med påfølgende hvorfor og deres svar.
Et eksempel på hvordan 5 Whys-diagram brukes på en programvarefeil:
5 Hvorfor mal og bilder tegnes ved hjelp av Creately online-programvare.
Faktorer som forårsaker feil
Det er mange faktorer som provoserer feilene:
- Uklare / manglende / feil krav
- Feil design
- Feil koding
- Utilstrekkelig testing
- Miljøproblemer (maskinvare, programvare eller konfigurasjoner)
Disse faktorene bør alltid holdes i bakhodet når du utfører RCA-prosessen.
RCA starter og fortsetter med idédugnad om feilen. Det eneste spørsmålet vi stiller oss selv når vi gjør RCA, er 'HVORFOR?' og hva?' Vi kan grave i hver fase av livssyklusen for å spore, hvor mangelen vedvarer.
La oss starte med 'HVORFOR?' spørsmål, (listen er ikke begrenset). Du kan starte fra den ytre fasen og bevege deg mot den indre fasen av SDLC.
hvordan åpner jeg en apk-fil
- 'HVORFOR' defekten ikke ble fanget opp under Sanity Test i produksjon?
- “HVORFOR” ble ikke feilen fanget under testing?
- “HVORFOR” ble ikke feilen fanget under prøvesaken?
- “HVORFOR” ble ikke feilen fanget Enhetstesting ?
- “HVORFOR” ble feilen ikke fanget under “Design Review”?
- “HVORFOR” ble ikke feilen fanget i kravfasen?
Svaret på dette spørsmålet vil gi deg den nøyaktige fasen, hvor feilen eksisterer. Når du først har identifisert fasen og årsaken, kommer “HVA” -delen.
“HVA vil du gjøre for å unngå dette i fremtiden?
Svaret på dette 'HVA' -spørsmålet, hvis implementert og ivaretatt, vil forhindre at den samme feilen eller den typen feil oppstår igjen. Ta passende tiltak for å forbedre den identifiserte prosessen slik at mangelen eller årsaken til mangelen ikke gjentas.
Basert på resultatene av RCA kan du bestemme hvilken av fasen som har problemområder.
For eksempel, hvis du finner ut at det meste av RCA av manglene skyldes krav glipp , så kan du forbedre kravinnsamlings- / forståelsesfasen ved å introdusere flere anmeldelser eller gjennomgangsøkter.
Tilsvarende, hvis du finner ut at de fleste feil skyldes teste frøken , må du forbedre testprosessen. Du kan introdusere beregninger som Kravsporbarhetsmålinger , Test Coverage Metrics, eller kan kontrollere kontrollprosessen eller andre trinn som du mener vil forbedre testens effektivitet.
Konklusjon
Det er hele teamets ansvar å sitte og analysere manglene og bidra til produkt- og prosessforbedring.
I denne veiledningen har du en grunnleggende forståelse av RCA, trinn som skal følges for å gjøre en effektiv RCA og forskjellige verktøy som skal brukes, for eksempel Fishbone analyse og 5 Why Technique. I de kommende opplæringene vil det dekkes på forskjellige RCA-maler, eksempler og brukstilfeller om hvordan du implementerer det.
Anbefalt lesing
- Testresultatanalyse og rapporter - Lastetesting med LoadRunner
- Beste verktøy for testing av programvare 2021 [QA Test Automation Tools]
- Test dine analysefunksjoner og tenkekraft - Øvelser i programvaretest (del 2)
- Hva er feilbasert testteknikk?
- Hva er grenseverdianalyse og ekvivalenspartisjonering?
- Testing Primer eBook Download
- Hva er defekt / bug-livssyklus i programvaretesting? Defekt livssyklusopplæring
- Lastetesting med HP LoadRunner-veiledninger