Аналіз причин (RCA - Root Cause Analysis)
Аналіз першопричини (root cause analysis): Аналіз, спрямований на ідентифікацію причин дефектів. При застосуванні заходів для усунення першопричини, можна сподіватися мінімізацію частоти появи дефектів певного типу. (ISTQB)
Причина (root cause): Джерело дефекту, при видаленні якого частота подібних дефектів скорочується, або подібні дефекти зникають повністю. (CMMI)
Будь-який процес, неважливо, розробка це або тестування, супровід, управління якістю і т.д., завжди має бути циклічним. Існують чотири основні підходи до роботи з процесами, і найпопулярніший з них, це вже загальновизнаний цикл Демінга. Саме на його основі будується робота процесу та всі інші методології, такі як DMAIC (6 сигм), IDEAL, EFQM, які завжди говорять нам про те, що потрібно не лише вимагати виконання процесу, а й постійно його аналізувати та безперервно вдосконалювати. Ці моделі дозволяють нам зрозуміти, як ми повинні працювати з процесом, і, найголовніше, ми повинні завжди бачити проблеми нашого процесу і намагатися їх вирішити.
Говорячи про тестування, існують 2 основні підходи до вдосконалення процесу тестування, це MBI та ABI.
MBI або Model Based Improvement – підхід до вдосконалення процесу тестування, який ґрунтується на референтних моделях удосконалення процесу тестування. Моделі можуть бути процесні, такі як TMMi, TPI та контекстні, такі як STEP або CTP. Ці моделі дозволяють нам на основі практик будувати процес тестування за конкретними кроками, тим самим розвиваючи процес тестування рівномірно і послідовно.
Але чи підходять нам такі моделі для аудитів існуючих процесів?
Основна проблема в тому, що кожен процес тестування відрізняється в залежності від організації, що ставить під сумнів застосування тих практик, які дає нам модельний підхід. Ну і багато фахівців, які проводили саме аудит процесу тестування, можливо чули фразу, що ставить у глухий кут всі результати вашої роботи: “Я можу зараз взяти ваші результати, принести їх в іншу компанію і вони теж там будуть застосовні. Нема конкретики!” І все це тому, що багато керівників, тест-менеджерів, особливо в Росії, не розуміють різницю між аудитом і оцінкою рівня зрілості процесу тестування.
Аудит – це аналіз поточного стану процесу з метою вирішення конкретних проблем, що не дозволяють процесу виконувати поставлені завдання.
Оцінка зрілості – це аналіз поточного стану процесу з метою розуміння його зрілості щодо загальноприйнятих моделей процесу тестування. Оцінка рівня зрілості часто може вирішувати взагалі проблем, т.к. її завдання лише оцінити процес.
Тому, говорячи про модельний підхід MBI розумно його застосовувати лише для виконання завдань з оцінки рівня зрілості процесу тестування та написання стратегії розвитку процесу тестування на тривалий термін. У всіх інших випадках, а особливо коли вам потрібно вирішити якусь проблему, MBI не допоможе вам. Для цього існує підхід ABI.
ABI або Analytical Based Improvement – це підхід до вдосконалення процесу тестування, що ґрунтується на аналітичних підходах аналізу процесу.
Головна відмінність модельного підходу від аналітичного в тому, що коли ми аналізуємо процес по MBI, то ми аналізуємо процес зверху вниз, тобто спочатку ми дивимося на процес в цілому, тому ділимо його на області, етапи і т.д., тим самим поступово занурюючись у деталі процесу. Аналітичний підхід працює навпаки, ми спочатку занурюємося в деталі нашого процесу і вже потім йдучи, як по ланцюжку, вгору, доходимо до вирішення нашої головної проблеми.
Існують кілька аналітичних підходів до вдосконалення процесів, але жодного разу не бачив їх застосування до процесу тестування, т.к. вони містять саме модель аналізу і можуть бути застосовні, у тому числі, і у виробництві фабрики, розслідуванні аварій, побудові мостів і багато в чому іншому.
Поставте собі питання, як часто до вас приходив ваш керівник зі словами, чи у нас є така проблема в процесі і її потрібно вирішити? Що ви робите? Ви шукаєте причину цієї проблеми та намагаєтеся її усунути. Але дуже часто буває так, що начебто ви вирішуєте причину, але процес все одно не працює як слід. І все це тому, що ви обрали для вирішення не те вузьке місце!
Тому для проведення аудиту процесу тестування, з метою вирішення конкретних проблем, варто звернути свою увагу на Root Cause Analysis.
Аналіз першопричин (RCA) – це систематичний процес виявлення прихованих першопричин проблем чи подій та підходу до їх усунення. В основі RCA лежить основна ідея про те, що ефективне управління вимагає більшого, ніж просто «гасіння пожеж» проблем, що виникають, але і пошук способів їх запобігання. Таким чином, RCA являє собою деревоподібну ієрархічну структуру залежності причин, як з проблемою, так і між собою.
Стандартно, до проблем процесу тестування, я відношу лише ті проблеми, які пов'язані з класичним трикутником – ціна/якість/строки. Чому це так? Будь-який процес ІТ, у тому числі й тестування, має забезпечувати бізнес організації. ІТ – це помічник бізнесу, тому, коли вам бізнес говорить, що вони не встигають впроваджувати всі заплановані фічі, продукти, то це не проблема бізнесу (що вони генерують багато завдань), а проблема тестування. Все інше, що не пов'язане з цим “трикутником проблем” є причинами виникнення проблем, які найчастіше бувають незрозумілими та ховаються від нас.
Процес аудиту з RCA складається з 5 етапів:
Визначити проблему та її вплив на загальні цілі;
Зібрати всю інформацію та дані;
Визначити будь-які інциденти (issues), які сприяли виникненню проблеми;
Визначити першопричини;
Визначити рекомендації у разі повторення проблем у майбутньому;
реалізувати необхідні рішення;
Отже, що таке проблема? Проблема - це питання чи завдання, що потребує вирішення. Проблеми у роботі ми знаходимо постійно, критичність проблеми ми визначаємо симптомами, тобто. ознаками існування проблеми. Припустимо, ми ідентифікували проблему як постійне зрушення термінів впровадження релізу. Ознакою існування у проблеми у разі може бути систематичність її виникнення. Я думаю, ви розумієте різницю, один раз у вас відбувся зсув за 6 релізів, або вже 6-й раз поспіль. У другому випадку проблема вже починає мати критичний характер. Вирішувати всі проблеми неможливо, тому якщо у Вас є велика кількість проблем, то ви можете вибрати найбільш важливі з них за ступенем впливу та частотою виникнення.
Маючи проблему, ми можемо розпочинати пошук ймовірнісних причин. Найпростіший спосіб визначення причин – метод брейншторму всіх залучених до процесу учасників. Ви можете зібрати з усіх фахівців їхню думку щодо того, які вони бачать причини виникнення проблеми і після цього вибрати з них найчастіше звані співробітниками.
Наступний і дуже важливий крок – це аналіз імовірнісних причин.
Існує декілька підходів до проведення аналізу, таких як діаграми залежностей або розсіювання, афінна діаграма, але найпоширенішим підходом до проведення аналізу є діаграма Парето.
Шляхом брейншторма ми визначили 5 основних причин виникнення проблеми, пов'язаної зі зсувом термінів застосування. Після цього наше завдання зрозуміти, які з цих причин найбільше впливають на нашу проблему. Використовуючи принцип Парето, ми визначаємо кількість людино-днів, які ми втрачаємо через виникнення тієї чи іншої проблеми.
В результаті аналізу ми бачимо, що тільки перші 2 причини на 60% впливають на зсув термінів впровадження, що значно більше, ніж інші 3 причини сумарно.
Наступним етапом є проведення причинно-наслідкового аналізу (ПСА) з метою виявлення корінних причин та їх залежностей один з одним. Для цього використовується діаграма причинно-наслідкового аналізу, основне завдання якої полягає в тому, що йдучи від проблеми по ланцюжку ми занурюємося на кожному рівні в причини виникнення причин, тим самим доходячи до справжньої або корінної причини виникнення проблем. В результаті, вирішивши корінну причину, ми автоматично вирішуємо всі інші причини, що призводить до мінімізації впливу або повного усунення нашої проблеми.
Для виконання ПСА ми наносимо на наше дерево всі наші причини, визначені раніше принципом Парето. Після цього ми їх пріоритезуємо та визначаємо їхню взаємозалежність. Наприклад, говорячи про тестові середовища, а саме проблеми, пов'язані з підбором тестових даних, це призводить до виникнення дефектів "тестування", що збільшує терміни виконання робіт з тестування ПЗ. Відповідно, вирішивши цю причину, ми автоматично зможемо знизити вплив причин, пов'язаних з дефектами. Тому ми можемо вирішувати не 3 причини, а лише 2, тим самим скорочуючи витрати на оптимізацію процесу тестування.
Та й останній етап - це вироблення рішень. Провівши аналіз RCA рішення будуть цілком зрозумілі, але дуже важливо, щоб ці рішення дійсно були націлені на конкретну причину і були здійснені всією командою, на яку лягає їх реалізація.
Найбільш зрозумілою книгою, що розглядає модель RCA, я вважаю Андерсон Бьєрн – «Аналіз основної причини. Спрощені інструменти та методи», в якій на звичайних прикладах життя розглядаються різні можливості застосування моделі RCA.
Тому, якщо Вам поставили завдання оптимізувати процес тестування, але для цього вам потрібно вирішити якісь поточні проблеми, то вам потрібен аудит із застосуванням ABI, т.к. саме ABI дозволяють точково вирішувати проблеми і будь-які ваші рекомендації матимуть не рекомендаційний характер, а детальний, спрямований на оптимізацію саме для вашого проекту чи процесу.
Джерело:
Дод. матеріал:
Last updated