guide root cause analysis steps
Tento výukový program vysvětluje, co je analýza kořenové příčiny a různé techniky analýzy kořenové příčiny, jako je analýza rybí kosti a 5 metod Whys:
RCA (Root Cause Analysis) je strukturovaný a efektivní proces k nalezení hlavní příčiny problémů v týmu softwarového projektu. Pokud se provádí systematicky, může zlepšit výkon a kvalitu výstupů a procesů, a to nejen na úrovni týmu, ale také napříč organizací.
Tento kurz vám pomůže definovat a zefektivnit proces analýzy kořenových příčin ve vašem týmu nebo organizaci.
Tento výukový program je určen pro manažery doručování, Scrum Masters, projektové manažery, manažery kvality, vývojový tým, testovací tým, tým správy informací, tým kvality, tým podpory atd., Aby porozuměli základům analýzy kořenových příčin, a poskytuje jejich šablony a příklady .
Co se naučíte:
- Co je analýza kořenové příčiny?
- Proces analýzy kořenových příčin
- Techniky analýzy kořenových příčin
- Faktory způsobující vady
- Závěr
Co je analýza kořenové příčiny?
RCA (Root Cause Analysis) je mechanismus analýzy defektů k identifikaci jejich příčiny. Poruchu vymyslíme, přečteme a vykopáme, abychom zjistili, zda vada byla způsobena „ testovací slečna „,“ vývojová slečna “Nebo byl„ požadavek nebo návrhy chybí “.
Pokud je RCA provedeno přesně, pomáhá předcházet chybám v pozdějších verzích nebo fázích. Pokud zjistíme, že závada byla způsobena slečna designu , můžeme zkontrolovat konstrukční dokumenty a můžeme přijmout vhodná opatření. Podobně, pokud zjistíme, že závada byla způsobena testovací slečna , můžeme zkontrolovat naše testovací případy nebo metriky a podle toho je aktualizovat.
RCA by se neměl omezovat pouze na testování vad. RCA můžeme udělat i na výrobních vadách. Na základě rozhodnutí RCA můžeme vylepšit naši Testovací postel a zahrnout tyto produkční lístky jako případy regresního testu. Tím zajistíte, aby se závada nebo podobné druhy závad neopakovaly.
Proces analýzy kořenových příčin
RCA se nepoužívá pouze pro závady hlášené ze stránky zákazníka, ale také pro závady UAT, závady testování jednotky, obchodní a provozní problémy na úrovni procesů, každodenní problémy se životem atd. Proto se používá v různých průmyslových odvětvích, jako je Softwarový sektor, výroba, zdravotnictví, bankovní sektor atd.
Provádění analýzy kořenových příčin je podobné práci lékaře, který léčí pacienta. Lékař nejprve pochopí příznaky. Poté se odvolá na laboratorní testy k analýze hlavní příčiny nemoci.
Pokud je hlavní příčina onemocnění stále neznámá, lékař vyhledá skenovací testy, aby lépe porozuměl. Bude pokračovat v diagnostice a studiu, dokud se nezúží na hlavní příčinu nemoci pacienta. Stejná logika platí pro analýzu kořenových příčin prováděnou v jakémkoli odvětví.
RCA je tedy zaměřena na nalezení hlavní příčiny a neléčení příznaku pomocí konkrétní sady kroků a souvisejících nástrojů. Liší se od analýzy defektů, odstraňování problémů a dalších metod řešení problémů, protože se tyto metody snaží najít řešení pro konkrétní problém, ale RCA se snaží najít příčinu.
Původ názvu Kořenová analýza příčin:
(obraz zdroj )
Listy, kmen a kořeny jsou nejdůležitější částí stromu. Listy (Příznak) a kmen (Problém), které jsou nad zemí, jsou viditelné, ale kořeny (Příčina), které jsou pod zemí, nejsou viditelné a kořeny rostou hlouběji a mohou se šířit dále, než očekáváme. Proces kopání do spodní části čísla se proto nazývá Analýza kořenových příčin.
Výhody analýzy hlavních příčin
Níže jsou uvedeny některé z výhod, které získáte:
- Zabraňte opakovanému výskytu stejného problému v budoucnu.
- Nakonec snižte počet vad hlášených v průběhu času.
- Snižuje vývojové náklady a šetří čas.
- Zlepšete proces vývoje softwaru, a tím napomáhejte rychlému dodání na trh.
- Zvyšuje spokojenost zákazníků.
- Zvyšte produktivitu.
- Najděte skryté problémy v systému.
- Pomáhá při neustálém zlepšování.
Druhy hlavních příčin
# 1) Lidská příčina: Chyba způsobená člověkem.
Příklady:
- Pod zručnost.
- Pokyny, které nebyly řádně dodržovány.
- Provedl zbytečnou operaci.
# 2) Organizační příčina: Proces, který lidé používají k přijímání nesprávných rozhodnutí.
Příklady:
- Nejasné pokyny byly dány vedoucím týmu členům týmu.
- Výběr nesprávné osoby pro úkol.
- Pro hodnocení kvality nejsou k dispozici monitorovací nástroje.
# 3) Fyzická příčina: Jakákoli fyzická položka nějakým způsobem selhala.
Příklady:
- Počítač se restartuje.
- Server se nespouští.
- Zvláštní nebo hlasité zvuky v systému.
Kroky k provedení analýzy kořenových příčin
Pro efektivní analýzu hlavních příčin je vyžadován strukturovaný a logický přístup. Proto je nutné provést řadu kroků.
# 1) Vytvořte tým RCA
Každý tým by měl mít vyhrazený Správce analýzy kořenových příčin (RCA Manager) kdo shromáždí podrobnosti od týmu podpory a zahájí proces zahájení pro RCA. Bude koordinovat a přidělovat zdroje, které se potřebují účastnit schůzí RCA v závislosti na uvedeném problému.
Týmy, které se schůzky zúčastní, by měly mít pracovníky z každého týmu (Požadavek, Návrh, Testování, Dokumentace, Kvalita, Podpora a údržba), kteří jsou s problémem nejvíce obeznámeni. Tým by měl mít také lidi, kteří jsou přímo spojeni s vadou. Například, technik podpory, který zákazníka okamžitě opravil.
Sdílejte s týmem podrobnosti problému před účastí na schůzce, aby mohli provést počáteční analýzu a byli připraveni. Členové týmu také shromažďují informace týkající se vady. V závislosti na zprávě o incidentu bude každý tým sledovat, co se v tomto scénáři v příslušných fázích stalo špatně. Připravenost zvýší efektivitu nadcházející diskuse.
# 2) Definujte problém
Shromážděte podrobnosti o problému, jako jsou zprávy o incidentech, důkazy o problému (snímek obrazovky, protokoly, zprávy atd.), Poté problém prostudujte / analyzujte položením následujících otázek:
- Co je za problém?
- Jaký je sled událostí, které vedly k problému?
- O jaké systémy šlo?
- Jak dlouho problém existoval?
- Jaký je dopad problému?
- Kdo byl zapojen a určil, s kým by měl být dotazován?
K definování problému použijte pravidla „SMART“:
- S PECIFICKÉ
- M SNADNÉ
- NA ORIONOVANĚ NA KION
- R ELEVANTNÍ
- T VÁZANÉ JMÉNO
# 3) Zjistěte hlavní příčinu
Proveďte BRAINSTORMING relace v týmu RCA vytvořená za účelem identifikace příčin. Použijte Diagram rybí kosti nebo 5 Proč analýza metoda nebo obojí k dosažení hlavní příčiny / příčin.
Manažer RCA by měl schůzku moderovat a nastavit pravidla pro relaci Brainstorming. Pravidla mohou být například:
- Nesmí být dovoleno kritizovat / obviňovat ostatní.
- Nesuďte nápady ostatních. Žádné nápady nejsou špatné, podporují divoké nápady.
- Stavte na nápadech ostatních. Přemýšlejte o tom, jak můžete stavět na nápadech ostatních a vylepšovat je.
- Poskytněte každému účastníkovi čas na sdílení jeho názorů.
- Podporujte myšlení po vybalení z krabice.
- Zůstaňte soustředěni.
Všechny nápady by měly být zaznamenány. Správce RCA by měl určit člena, který bude zaznamenávat zápisy ze schůzky a aktualizaci šablon RCA.
# 4) Implementujte kořenovou příčinu nápravných opatření (RCCA)
Opravná akce zahrnuje opravu řešení identifikováním skutečné příčiny. Aby to bylo možné usnadnit, musí být přítomen správce doručení, který může rozhodnout, ve kterých všech verzích musí být oprava implementována a jaké by mělo být datum dodání.
RCCA by měl být implementován takovým způsobem, aby se tato hlavní příčina v budoucnu již neobjevila. Oprava poskytnutá týmem podpory bude dočasná pro web zákazníka, kde je problém nahlášen. Když je tato oprava sloučena do probíhající verze, proveďte správnou analýzu dopadů, abyste zajistili, že nebude narušena žádná stávající funkce.
Proveďte kroky k ověření opravy a sledujte implementované řešení a zkontrolujte, zda je řešení účinné.
# 5) Implementujte kořenovou preventivní akci (RCPA)
Tým musí přijít s plánem, jak lze podobnému problému v budoucnu zabránit. Například, Aktualizujte návod k použití, vylepšete sadu dovedností, aktualizujte kontrolní seznam hodnocení týmu atd. Řiďte se příslušnými dokumenty preventivních akcí a sledujte, zda tým dodržuje přijatá preventivní opatření.
Přečtěte si prosím toto výzkumný papír 'Analýza defektů a prevence pro zlepšení kvality softwarových procesů' zveřejněná v International Journal of Software Engineering & Applications získat představu o typech vad hlášených v každé softwarové fázi a navrhnout pro ně preventivní opatření.
Informace získané z RCA mohou jít jako vstup do Analýza poruchových režimů a účinků (FMEA ) k identifikaci bodů, kde řešení může selhat.
Nářadí Paretova analýza s příčinami zjištěnými během RCA za určité období, řekněme pololetně nebo čtvrtletně, které pomohou identifikovat hlavní příčiny, které přispívají k poruchám, a zaměřit se na preventivní opatření pro ně.
Techniky analýzy kořenových příčin
# 1) Analýza rybí kosti
Fishbone diagram je vizuální nástroj pro analýzu příčin, který identifikuje možné příčiny identifikovaných problémů, a proto se také nazývá diagram příčin a následků. To vám umožní dostat se ke skutečné příčině problému, spíše než k řešení jeho příznaku.
Nazývá se také Ishikawův diagram, jak jej vytvořil Dr. Kaoru Ishikawa (japonský statistik kontroly kvality). Je také známý jako Herringbone nebo Fishikawa diagram.
Analýza rybí kosti se používá ve fázi analýzy DMAIC šesti sigma přístup k řešení problémů. Je to jeden z Sedm základních nástrojů kontroly kvality .
Kroky k vytvoření diagramu Fishbone:
Diagram rybí kosti připomíná kostru ryby s problémem formovat hlavu ryby a způsobuje formování páteře a kostí ryby.
Podle následujících kroků vytvořte diagram rybí kosti:
- Napsat problém na hlava ryby .
- Určete kategorie příčin a napište na konec každé kosti (příčina kategorie 1, příčina kategorie 2 …… příčina kategorie N)
- Určete primární příčiny pod každou kategorií a označte ji jako primární příčinu 1, primární příčinu 2, primární příčinu N.
- Rozšiřte příčiny na sekundární, terciární a další úrovně podle potřeby.
Příklad použití diagramu rybí kosti na softwarovou vadu (viz níže).
K vytvoření diagramu rybí kosti je k dispozici spousta bezplatných i placených nástrojů. Diagram Fishbone v tomto tutoriálu byl vytvořen pomocí „ Kreativně “ online nástroj . Další podrobnosti o šablonách a nástrojích rybí kosti budou vysvětleny v našem dalším kurzu.
# 2) Technika 5 Whys
5 Proč byla technika vyvinuta Sakiči Toyoda a byl používán ve společnosti Toyota v jejich zpracovatelském průmyslu. Tato technika odkazuje na řadu otázek, kde na každou odpověď odpovídá otázka Proč. Může to souviset s tím, jak dítě bude klást otázky dospělým. Na základě odpovědi, kterou dospělí dávají, se budou znovu a znovu ptát na otázky „Proč“, dokud nebudou spokojeni.
5 Proč se tato technika používá samostatně nebo jako součást analýzy rybí kosti k podrobnému posouzení příčiny problému. Počet kroků není omezen na 5. Může být menší nebo větší než 5, dokud nedojde k diagnostice problému. 5 Proč jsou relativně jednodušší technika a rychlejší způsob, jak zjistit hlavní příčiny. Usnadňuje rychlou diagnostiku k vyloučení příznaků a zjištění hlavní příčiny.
Úspěch této techniky závisí na znalostech osoby. Na stejnou otázku Proč mohou být různé odpovědi. Je tedy důležité zvolit správný směr a soustředit se na schůzku.
Kroky k vytvoření 5 Whys diagramu
Zahajte debatu o brainstormingu definováním problému. Poté pokračujte následným Proč a jejich odpověďmi.
Příklad použití 5 Whys diagramu na softwarovou vadu:
5 Proč jsou šablony a obrázky kresleny pomocí softwaru Creately online.
Faktory způsobující vady
Existuje mnoho faktorů, které vyvolávají výskyt Vad:
- Nejasné / chybějící / nesprávné požadavky
- Nesprávný design
- Nesprávné kódování
- Nedostatečné testování
- Problémy s prostředím (hardware, software nebo konfigurace)
Při provádění procesu RCA je vždy třeba mít na paměti tyto faktory.
RCA začíná a pokračuje v brainstormingu na defektu. Jedinou otázkou, kterou si při provádění RCA klademe, je „PROČ?“ a „CO?“ Můžeme kopat do každé fáze životního cyklu, abychom sledovali, kde závada přetrvává.
Začněme „PROČ?“ otázky (seznam není omezen). Můžete začít od vnější fáze a posunout se k vnitřní fázi SDLC.
jak napsat testovací případ
- „PROČ“ nebyl defekt chycen během Test příčetnosti ve výrobě?
- „PROČ“ vada nebyla během testování zachycena?
- „PROČ“ chyba nebyla během kontroly testovacího případu zachycena?
- „PROČ“ nebyl Defekt chycen Testování jednotek ?
- „PROČ“ nebyla chyba zachycena během „Design Review“?
- „PROČ“ nebyl vada zachycena během fáze požadavku?
Odpověď na tuto otázku vám poskytne přesnou fázi, kdy závada existuje. Jakmile jednou identifikujete fázi a důvod, pak přijde část „CO“.
'CO uděláte, abyste se tomu v budoucnu vyhnuli?'
Odpověď na tuto otázku „CO“, bude-li implementována a bude o ni postaráno, zabrání tomu, aby se stejná vada nebo druh vady znovu objevil. Přijměte vhodná opatření ke zlepšení zjištěného procesu tak, aby se závada nebo důvod závady neopakoval.
Na základě výsledků RCA můžete určit, která z fází má problémové oblasti.
Například, pokud zjistíte, že většina RCA vad je způsobena požadavek chybí , pak můžete zlepšit fázi shromažďování / porozumění požadavků zavedením dalších recenzí nebo průchozích relací.
Podobně, pokud zjistíte, že většina vad je způsobena testovací slečna , musíte vylepšit proces testování. Můžete zavést metriky jako Metriky sledovatelnosti požadavku , Testovat metriky pokrytí, nebo si můžete nechat zkontrolovat proces kontroly nebo jakýkoli jiný krok, který by podle vás zlepšil účinnost testování.
Závěr
Je odpovědností celého týmu sedět a analyzovat vady a přispívat ke zlepšování produktu a procesu.
V tomto tutoriálu získáte základní znalosti o RCA, kroky, které je třeba dodržet při provádění efektivního RCA a různé nástroje, které se mají použít, jako je Fishbone analýza a 5 Why Technique. V nadcházejících výukových programech se budeme zabývat různými šablonami RCA, příklady a případy použití, jak jej implementovat.
Doporučené čtení
- Analýza výsledků testů a zprávy - testování zátěže pomocí nástroje LoadRunner
- Nejlepší nástroje pro testování softwaru 2021 (QA Test Automation Tools)
- Vyzkoušejte své možnosti analýzy a sílu myšlení - cvičení pro testování softwaru (část 2)
- Co je technika testování na základě vad?
- Co je analýza hraničních hodnot a rozdělení ekvivalence?
- Testování stahování e-knih Primer
- Co je životní cyklus vady / chyby při testování softwaru? Výukový program pro defekt životního cyklu
- Testování zátěže s výukovými programy HP LoadRunner