Привіт друзі! Минулого тижня ми написали про управління ризиками і багатьом тема “зайшла”. Тому сьогодні підемо далі і спробуємо ідентифікувати та оцінити типові ризики для тестування.
Отже, уявімо, що нам треба розробити чернетку тест плану невеликого проекту, в якому працює лише 1-2 тестери і прописати типові ризики, наприклад такі:
R1️⃣ тестування не буде завершено вчасно
R2️⃣ задачі тестування можуть бути недооцінені
R3️⃣ середовище тестування може бути недоступне
R4️⃣ тестер може захворіти чи звільнитись
R5️⃣ вимоги до продукту можуть бути змінені у фазі тестування
Як і з будь-яким іншим артефактом, кожному ризику дається унікальний ID, щоб легше було його відстежувати і посилатись.
Тепер давайте дамо оцінку цим ризикам, поставивши оцінку ймовірності (likelihood – LH) та руйнівності наслідків (impact – IM) по шкалі від 1 до 5, де 1 – мала імовірність/вплив, а 5 – дуже висока. Після чого одразу визначимо пріоритет (P):
| Likelihood | Impact | Priority | |
| R1️⃣ | 4 | 5 | 20 |
| R2️⃣ | 2 | 3 | 06 |
| R3️⃣ | 3 | 5 | 15 |
| R4️⃣ | 3 | 4 | 12 |
| R5️⃣ | 3 | 3 | 09 |
Як розумієте, пріоритет нам потрібен лише для того, щоб розуміти, в якому порядку ми будемо боротись з ризиками.
Зупинимось на сьогодні. Як бачите, не такі ризики страшні і складні, як про них думають. Головне – їх не ігнорувати.
Вам сподобалось? Наступного разу розберемо шляхи пом’якшення ідентифікованих нами ризиків?