guide root cause analysis steps
Този урок обяснява какво е анализ на основната причина и различни техники за анализ на основната причина като анализ на рибената кост и техника 5 защо:
RCA (анализ на основната причина) е структуриран и ефективен процес за намиране на основната причина за проблеми в екипа на Софтуерния проект. Ако се извършва системно, това може да подобри производителността и качеството на резултатите и процесите, не само на ниво екип, но и в цялата организация.
Този урок ще ви помогне да определите и рационализирате процеса на анализ на основната причина във вашия екип или организация.
Този урок е предназначен за мениджъри на доставки, Scrum Masters, мениджъри на проекти, мениджъри по качеството, екип за разработка, тестов екип, екип за управление на информация, екип за качество, екип за поддръжка и др., За да разберат основите на анализа на основната причина и предоставя шаблони и примери за него .
Какво ще научите:
- Какво е анализ на основната причина?
- Процес на анализ на основната причина
- Техники за анализ на основната причина
- Фактори, причиняващи дефекти
- Заключение
Какво е анализ на основната причина?
RCA (анализ на основната причина) е механизъм за анализ на дефектите, за да се установи причината за тях. Ние размишляваме, четем и копаем дефекта, за да установим дали дефектът се дължи на „ пропускане на тестване ',' мис за развитие ”Или беше„ изискване или дизайн липсва ”.
Когато RCA се извършва точно, това помага да се предотвратят дефекти в по-късните версии или фази. Ако установим, че дефектът се дължи на дизайнерска мис , можем да прегледаме проектните документи и да вземем подходящи мерки. По същия начин, ако установим, че дефектът се дължи на пропускане на тестване , можем да прегледаме нашите тестови случаи или показатели и да ги актуализираме съответно.
RCA не трябва да се ограничава само до тестване на дефектите. Можем да направим RCA и при производствени дефекти. Въз основа на решението на RCA, ние можем да подобрим нашите Тестово легло и включете тези производствени билети като регресионни тестове. Това ще гарантира, че дефектът или подобни видове дефекти не се повтарят.
Процес на анализ на основната причина
RCA не се използва само за дефекти, отчетени от сайт на клиента, но също така и за дефекти на UAT, дефекти на тестване на единица, проблеми на бизнес и оперативен процес, ежедневни житейски проблеми и т.н. Следователно се използва в множество индустрии като Софтуерен сектор, производство, здравеопазване, банков сектор и др.
Провеждането на анализ на основната причина е подобно на работата на лекаря, който лекува пациент. Лекарят първо ще разбере симптомите. След това той ще се позове на лабораторни тестове, за да анализира първопричината на заболяването.
Ако основната причина за заболяването все още е неизвестна, лекарят ще насочи към тестове за сканиране, за да разбере допълнително. Той ще продължи диагностиката и ще проучва, докато се стесни до първопричината за болестта на пациента. Същата логика се отнася и за анализ на основната причина, извършван във всяка индустрия.
И така, RCA е насочен към намиране на основната причина и не към лечение на симптома, като следва определен набор от стъпки и свързани инструменти. Той се различава от анализа на дефекти, отстраняване на неизправности и други методи за решаване на проблеми, тъй като тези методи се опитват да намерят решението за конкретния проблем, но RCA се опитва да намери основната причина.
Произход на името Анализ на основната причина:
(изображение източник )
Листата, стволът и корените са най-важните части на дървото. Листата (Симптом) и стволът (Проблем), които са над земята, са видими, но корените (Причина), които са под земята, не се виждат и корените растат по-дълбоко и могат да се разпространят по-далеч повече, отколкото очакваме. Следователно процесът на изкопаване до дъното на проблема се нарича анализ на основната причина.
Предимства на анализа на основната причина
Изброените по-долу са някои от предимствата, които ще получите:
- Предотвратете повторната поява на същия проблем в бъдеще.
- В крайна сметка намалете броя на дефектите, съобщени с течение на времето.
- Намалява разходите за развитие и спестява време.
- Подобрете процеса на разработване на софтуер и по този начин подпомогнете бързата доставка на пазара.
- Подобрява удовлетвореността на клиентите.
- Повишаване на производителността.
- Намерете скрити проблеми в системата.
- Помага за непрекъснато усъвършенстване.
Видове основни причини
# 1) Човешка причина: Човешка грешка.
Примери:
- Под квалифициран.
- Инструкции, които не са спазени надлежно.
- Извършена ненужна операция.
# 2) Организационна причина: Процес, който хората използват, за да вземат решения, които не са били правилни.
Примери:
- На членовете на екипа бяха дадени неясни инструкции от ръководителя на екипа.
- Избиране на грешен човек за задача.
- Не са налични инструменти за мониторинг за оценка на качеството.
# 3) Физическа причина: Всеки физически елемент се провали по някакъв начин.
Примери:
- Компютърът продължава да се рестартира.
- Сървърът не се зарежда.
- Странни или силни звуци в системата.
Стъпки за извършване на анализ на основната причина
За ефективен анализ на първопричината е необходим структуриран и логичен подход. Следователно е необходимо да следвате поредица от стъпки.
# 1) Форма RCA Екип
Всеки екип трябва да има посветен Мениджър за анализ на основна причина (RCA Manager) който ще събере подробностите от екипа за поддръжка и ще започне процеса за стартиране на RCA. Той ще координира и разпределя ресурси, които трябва да присъстват на заседанията на RCA в зависимост от заявения проблем.
Екипите, които присъстват на срещата, трябва да разполагат с персонал от всеки екип (Изискване, дизайн, тестване, документация, качество, поддръжка и поддръжка), който е най-запознат с проблема. В екипа трябва да има хора, които също са пряко свързани с дефекта. Например, инженерът за поддръжка, който даде незабавна корекция на клиента.
Споделете подробностите за проблема с екипа, преди да присъствате на срещата, за да могат да направят първоначален анализ и да се подготвят. Членовете на екипа също събират информация, свързана с дефекта. В зависимост от доклада за инцидента, всеки екип ще проследи какво се е объркало w.r.t до този сценарий в съответните им фази. Подготвеността ще увеличи ефективността на предстоящата дискусия.
# 2) Определете проблема
Съберете подробностите за проблема като доклади за инциденти, доказателства за проблема (екранна снимка, дневници, отчети и т.н.), след това проучете / анализирайте проблема, като зададете следните въпроси:
- Какъв е проблемът?
- Каква е последователността на събитията, довели до проблема?
- Какви системи бяха включени?
- От колко време съществува проблемът?
- Какво е въздействието на проблема?
- Кой участва и определи кой трябва да бъде интервюиран?
Използвайте правилата „SMART“, за да дефинирате проблема си:
- С ТОЧНО
- М ЛЕСНО
- ДА СЕ ОРИЕНТИРАНО С ЦЕНЦИЯ
- R ЕЛЕВАНТНА
- т СВЪРЗАНО С ИМЕ
# 3) Идентифицирайте основната причина
Провеждане на Мозъчен мозък сесия в екипа на RCA, сформиран за идентифициране на причините. Използвай Диаграма на рибената кост или 5 Защо анализ метод или и двете, за да се стигне до първопричината / причините.
Мениджърът на RCA трябва да модерира срещата и да определи правилата за мозъчната атака. Например, правилата могат да бъдат:
- Не бива да се допуска критикуване / обвиняване на други.
- Не съдете идеите на другите. Никакви идеи не са лоши, те насърчават диви идеи.
- Надграждайте върху идеите за другите. Помислете как можете да надграждате идеите на другите и да ги направите по-добри.
- Дайте на всеки участник време да сподели своите виждания.
- Насърчавайте нестандартното мислене.
- Остани съсредоточен.
Всички идеи трябва да бъдат записани. RCA мениджърът трябва да назначи член, който да записва протокола от срещата и актуализиране на RCA шаблони.
# 4) Прилагане на коригиращо действие (RCCA)
Коригиращото действие включва определяне на решението чрез идентифициране на истинската основна причина. За да се улесни това, трябва да присъства мениджър на доставката, който може да реши в кои версии трябва да се приложи корекцията и каква да бъде датата на доставка.
RCCA трябва да се прилага по такъв начин, че тази основна причина да не се появява отново в бъдеще. Поправката, дадена от екипа за поддръжка, ще бъде временна за сайта на клиента, където е докладван проблемът. Когато тази корекция се обедини в текуща версия, направете правилен анализ на въздействието, за да сте сигурни, че няма съществуваща функция е нарушена.
Дайте стъпките за валидиране на корекцията и наблюдавайте внедреното решение, за да проверите дали решението е ефективно.
# 5) Прилагане на превантивни действия за основна причина (RCPA)
Екипът трябва да изготви план за това как подобен проблем може да бъде предотвратен в бъдеще. Например, Актуализирайте ръководството с инструкции, подобрете набора от умения, актуализирайте контролния списък за оценка на екипа и др. Следвайте правилните документи за превантивни действия и наблюдавайте дали екипът се придържа към предприетите превантивни действия.
Моля, обърнете се към това изследователска работа относно „Анализ и предотвратяване на дефекти за подобряване на качеството на софтуерния процес“, публикуван в Международен вестник за софтуерно инженерство и приложения за да получите представа за видовете дефекти, съобщени във всяка софтуерна фаза, и препоръчани превантивни действия за тях.
Информацията, получена от RCA, може да се използва като входна информация Режим на отказ и анализ на ефекта (FMEA ) за идентифициране на точки, където решението може да се провали.
Прилагане Анализ на Парето с причините, идентифицирани по време на RCA за период, да речем полугодишен или тримесечен, което ще помогне да се идентифицират основните причини, които допринасят за дефектите и да се съсредоточи върху превантивните действия за тях.
Техники за анализ на основната причина
# 1) Анализ на рибена кост
Диаграмата Fishbone е визуален инструмент за анализ на първопричината, за да се идентифицират възможните причини за идентифицираните проблеми и следователно се нарича още Диаграма на причините и последствията. Тя ви позволява да стигнете до истинската основна причина за проблема, вместо да разрешите симптома му.
Нарича се още диаграмата Ishikawa, както е създадена от Д-р Каору Ишикава (японски статистик за контрол на качеството). Известна е също като диаграма „Рибена кост“ или „Фишикава“.
Анализът на рибена кост се използва във фазата на анализ на шест сигма DMAIC подход за решаване на проблеми. Това е един от 7 основни инструмента за контрол на качеството .
Стъпки за създаване на диаграма Fishbone:
Диаграмата на рибената кост наподобява скелета на риба с проблема, формиращ главата на рибата и причиняващ образуването на гръбначния стълб и костите на рибата.
Следвайте стъпките по-долу, за да създадете диаграма на рибена кост:
- Напиши проблем в глава на рибата .
- Идентифицирайте категория причини и пишете на края на всяка кост (кауза категория 1, кауза категория 2 ...... кауза категория N)
- Идентифицирайте първични причини под всяка категория и го маркирайте като основна причина 1, основна причина 2, основна причина N.
- Разширете причините до средно, висше и повече нива според случая.
Пример за това как диаграмата на рибената кост се прилага към софтуерен дефект (вижте по-долу).
Налични са много безплатни, както и платени инструменти за създаване на диаграма на рибена кост. Диаграмата Fishbone в този урок е създадена с помощта на „ Създайте онлайн инструмент . Повече подробности за шаблоните и инструментите на fishbone ще бъдат обяснени в следващия ни урок.
# 2) Техниката 5 защо
5 Защо Техниката е разработена от Сакичи Тойода и се използва в Toyota в тяхната производствена индустрия. Тази техника се отнася до поредица от въпроси, при които на всеки отговор се отговаря с въпрос „Защо“. Тя може да бъде свързана с това как детето ще задава въпроси на възрастните. Въз основа на отговора, който възрастните дават, те ще задават въпроси „Защо“ отново и отново, докато се задоволят.
5 Защо техниката се използва самостоятелно или като част от анализа на рибената кост, за да се разбере до основната причина за проблема. Броят на стъпките не е ограничен до 5. Може да бъде по-малък или по-голям от 5, докато диагнозата на проблема пристигне. 5 Защо са относително по-проста техника и по-бърз начин да се стигне до първопричините. Той улеснява бързата диагностика, за да се изключат симптомите и да се стигне до основната причина.
Успехът на техниката зависи от познанията на човека. Може да има различни отговори на един и същ Защо въпрос. И така, изборът на правилната посока и фокусът в срещата е важен.
Стъпки за създаване на диаграма 5 Whys
Започнете дискусията за мозъчна атака, като дефинирате проблема. След това следвайте с последващи Защо и техните отговори.
Пример за това как се прилага диаграма 5 Whys към софтуерен дефект:
5 Защо шаблонът и изображенията се рисуват с помощта на онлайн софтуер Creately.
Фактори, причиняващи дефекти
Има много фактори, които провокират появата на дефекти:
- Неясни / липсващи / неправилни изисквания
- Неправилен дизайн
- Неправилно кодиране
- Недостатъчно тестване
- Проблеми с околната среда (хардуер, софтуер или конфигурации)
Тези фактори трябва винаги да се имат предвид при извършване на RCA процеса.
RCA започва и продължава с мозъчна атака върху дефекта. Единственият въпрос, който си задаваме, докато правим RCA, е „ЗАЩО?“ и какво?' Можем да разгледаме всяка фаза от жизнения цикъл, за да проследим, където дефектът продължава.
Нека започнем с въпроса „ЗАЩО?“ въпроси, (списъкът не е ограничен). Можете да започнете от външната фаза и да преминете към вътрешната фаза на SDLC.
как да обърна реда на масив в java
- „ЗАЩО“ Дефектът не беше хванат по време на Тест за здрав разум в производство?
- „ЗАЩО“ Дефектът не беше хванат по време на Тестване?
- „ЗАЩО“ Дефектът не беше засечен по време на прегледа на тестовия случай?
- „ЗАЩО“ Дефектът не беше хванат Единично тестване ?
- „ЗАЩО“ Дефектът не беше засечен по време на „Преглед на дизайна“?
- „ЗАЩО“ Дефектът не беше хванат по време на фазата на изискване?
Отговорът на този въпрос ще ви даде точната фаза, където дефектът съществува. След като веднъж идентифицирате фазата и причината, идва част „КАКВО“.
„КАКВО ще направите, за да избегнете това в бъдеще?
Отговорът на този „КАКЪВ“ въпрос, ако се приложи и се погрижи за него, ще предотврати появата на същия дефект или вида на дефекта отново. Вземете подходящи мерки за подобряване на идентифицирания процес, така че дефектът или причината за дефекта да не се повтарят.
Въз основа на резултатите от RCA можете да определите коя от фазите има проблемни области.
Например, ако определите, че повечето от RCA на дефектите се дължат на изискване пропускам , тогава можете да подобрите фазата на събиране / разбиране на изискванията, като въведете повече рецензии или разходки.
По същия начин, ако установите, че повечето дефекти се дължат на пропускане на тестване , трябва да подобрите процеса на тестване. Можете да въведете показатели като Метрики за проследяване на изискванията , Тествайте показатели за покритие или можете да проверите проверка на процеса на преглед или друга стъпка, която смятате, че би подобрила ефективността на тестването.
Заключение
Отговорността на целия екип е да седи и анализира дефектите и да допринася за подобряването на продукта и процеса.
В този урок имате основно разбиране за RCA, стъпки, които трябва да се следват за извършване на ефективен RCA и различни инструменти, които да се използват, като Fishbone анализ и 5 Защо техника. В предстоящите уроци ще бъдат разгледани различни RCA шаблони, примери и случаи на употреба за това как да се приложи.
Препоръчително четене
- Анализ на резултатите от теста и отчети - Тестване на товара с LoadRunner
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Тествайте своите възможности за анализ и сила на мислене - Упражнения за тестване на софтуер (част 2)
- Какво е техника за изпитване на базата на дефекти?
- Какво е анализ на граничната стойност и разделяне на еквивалентността?
- Изтегляне на eBook за тестване на Primer
- Какво представлява жизнения цикъл на дефекти / грешки при тестване на софтуер? Урок за жизнения цикъл на дефекти
- Тестване на натоварване с уроци за HP LoadRunner