Що таке ризики і як вони впливають на якість роботи

Сфера тестування є складною та багаторівневою системою, до складу якої входить величезна кількість різноманітних елементів. Окрім очевидних базових складових тестування, одним із менш очевидних, однак не менш головних аспектів сфери QA є ризик.

Поняття ризику

Ризик – це діючий фактор, або ж фактор процесу, що розвивається, який має потенційно негативний вплив на процес.

Якщо говорити простими словами, ризик – це те, що потенційно може ускладнити ситуацію. Варто розмежовувати поняття ризику та проблеми. Ризик – це те, що може статися, тобто можливе. Проблема – це те, що вже відбувається та несе за собою негативний вплив, тобто це ризик, який вже має місце. Таким чином, головна задача відносно ризиків – вчасно їх визначити, спрогнозувати, та вжити максимум заходів щодо мінімізації їх настання, тобто зробити все, щоб теоретичний ризик не став фактичною проблемою.

Загалом, у сфері тестування ризики можна умовно розділити на дві групи: ризики продукту та ризики проєкту. До першої групи можна віднести усе, що пов’язане саме з об’єктом тестування напряму, як-от:

• неточність/поверхневість специфікації або ж навпаки, занадто складна та заплутана специфікація;
• зміна специфікації у процесі розробки/тестування;
• ускладнення функціональних складових продукту;
• ризики, пов'язані з безпекою продукту;
• втрати даних тощо.

До ризиків проєкту можна умовно віднести усі інші:

• недостатність оцінки трудовитрат проєкту;
• ризики, пов’язані з раптовим зниженням робочої потужності проєкту (звільнення/хвороба/інші причини раптової відсутності співробітників);
• комунікаційні ризики (повільний відгук замовника на запитання/уточнення, недостатня комунікаційна реакція членів проєктного колективу та інші);
• ризики тестової інфраструктури (раптова відсутність інтернет-з’єднання чи електропостачання тривалий час, позапланова недоступність девайсів тощо);
• ризик ігнорування ризиків (недостатньо реалістична оцінка сценаріїв з боку кожного члена тестового колективу).

Окрім того, усі ризики сфери тестування можна розділити на керовані та некеровані. До керованих відносять усі ті теоретичні негативні прояви, які майже повністю можна нівелювати. Наприклад, комунікативний ризик можна мінімізувати напередодні проєкту, окресливши для кожного з учасників обов’язкові правила комунікацій у колективі, додаткові канали зв’язку, другорядні джерела отримання інформації тощо.

До некерованих ризиків, відповідно, відносять ті можливі негативні прояви, якими неможливо або надто складно керувати напряму. Наприклад, складно прогнозувати, чи буде впродовж проєкту хворіти розробник, чи матиме місце позапланове відключення енергопостачання. Такі ризики можна лише поверхнево охопити та розробити «план Б» у разі їх настання. Наприклад, система резервного копіювання ключових даних або ж навіть система автономного забезпечення акумульованою енергією може мати місце, якщо вимкнення живлення є критичним для проєкту.

Таким чином, процес тестування з урахуванням можливих негативних проявів, названий тестуванням на основі ризиків, є на сьогодні однією із найважливіших галузей усієї сфери тестування. Починаючи з аналізу тестової документації та закінчуючи заключними модулями тестування останніх версій готового продукту, що підтримуються, увесь процес тестування необхідно планувати та реалізовувати пліч-о-пліч із дослідженням та аналізом середовища на вірогідність усіх видів ризиків та розробкою заходів з їх нівелювання.

Процес управління ризиками складається з таких етапів:

1. Виявлення ризиків.

Перший крок – створення списку всього, що теоретично може піти не так. Скласти його QA-фахівцям допомагає аналіз вимог, мозкові штурми, консультації з експертами, досвід попередніх проєктів тощо. Основна мета на даному етапі – виявити якнайбільше потенційних загроз.

2. Оцінка ризиків.

Після того, як список складено, команда може переходити до наступного кроку аналізу ризиків. Відповідальні фахівці оцінюють кожну потенційну загрозу на основі двох факторів: ймовірність виникнення та можливу шкоду, яку буде завдано. На даному етапі часто використовують матрицю ризиків.

3. Розробка плану реагування.

Після того, як ризики ідентифіковані та оцінені, необхідно скласти план, як запобігти перетворення ризику у реальну проблему. На основі отриманих даних QA-Lead чи інший відповідальний фахівець може розпочати розробку стратегії тестування. Ті модулі, елементи та функції, неправильна робота яких несе у собі значні ризики, будуть тестуватись максимально ретельно. Результати оцінки також визначають, наскільки досвідчені фахівці працюватимуть над тим чи іншим завданням.

4. Моніторинг ризиків.

На цьому етапі фахівці займаються виявленням нових ризиків, повторною оцінкою знайдених раніше, а також коригуванням плану реагування.

На етапі оцінки ризиків часто використовують матричний метод, який є зручним та достатньо простим варіантом аналізу оточення на вірогідність виникнення ризикових ситуацій. У даній матриці з одного боку розташовується рівень ймовірності виникнення події, а з іншого – ступінь потенційного впливу на проєкт. Це дозволяє розділити всі ризики на групи (див. ілюстрацію 1).

Поділ ризиків на групи

Звичайно, залежно від проєкту така матриця може бути більш детальною. Тоді можливим ризикам будуть присвоюватися більше рівнів ймовірності. Наприклад: часті, можливі, випадкові, рідкісні, дуже рідкісні. Що ж до ступеня потенційного впливу, він може ділитися на катастрофічну, критичну, серйозну, прийнятну, незначну.

Окрім матричного, існують й інші методики оцінки та управління ризиками: легкі (з англ. light-weight) методи (PRAM, PRISMA) та більш формальні (FMEA, FTA).

Легкі методи є дещо більш гнучкими та неформальними. Наприклад, методи PRAM (прагматичний аналіз та управління ризиками) та PRISMA (управління ризиками продукту) успішно і легко комбінують стратегії, що базуються на ризику та вимогах. У цілому, в цих підходах використовують специфікації вимог як вхідні дані, але в процесі можуть брати участь і зацікавлені сторони. Легкі методи аналізу ризиків наголошують на технічних або комерційних ризиках, зважуючи ймовірність виникнення ризику та фактори, що впливають на цю ймовірність.

Моделі FTA (Fault Tree Analysis) поетапно визначають причини, які можуть призвести до дефектів у бізнес-процесах системи. Аналіз проходить від найвищого до найнижчого рівня, візуально нагадуючи деревоподібну систему з розгалуженнями на кожному з рівнів. Даний метод дозволяє глибоко розглянути навіть найменші варіанти виникнення ризиків у розрізі усього процесу тестування.

FMEA (Failure Mode and Effect Analysis) є найбільш популярним підходом до тестування на основі ризиків. Це модель аналізу причин та наслідків відмов системи, яка визначає потенційні дефекти та причини їх виникнення. Робота за такою моделлю означає, що команда проєкту намагається визначити усі компоненти, процеси, модулі, в яких може статися збій. Цей збій з різною часткою ймовірності може призвести до погіршення якості програмного забезпечення.

За використання методу FMEA у ході брейншторму визначаються ризики системи за трьома показниками: серйозність (S), пріоритетність (P), ймовірність (L). Для кожного з можливих ризикових проявів присвоюється значення цих трьох показників від 1 до 5, де 1 – це найвища ступінь важливості/серйозності/прояву, 5 – мінімальна важливість/серйозність/прояв. Потім обчислюється Risk Priority Number (RPN) для кожного ризику та залежно від показників закладається глибина тестування як добуток трьох значень цих показників: RPN = S*P*L.

Далі, залежно від отриманого показника, визначається глибина тестування ризиків:

• якщо значення RPN 1–10, то необхідно провести повне тестування з різноманітними позитивними та негативними перевірками, у тому числі мінорні тести;
• якщо значення RPN 11–30, то слід виконати обов'язкове позитивне тестування та базові негативні перевірки основної функціональності;
• якщо значення RPN 31–70 , то виконують поверхневе тестування функціональності;
• якщо значення RPN понад 70, то виконують тестування за наявності вільного часу.

Переваги моделі FMEA у тому, що вона використовує прозору модель оцінки обсягів тестування, відштовхуючись від ризиків використання ПЗ.

Тестування на основі ризиків дозволяє компаніям ефективно управляти обмеженими ресурсами. Такий підхід допомагає командам QA оптимізувати свою роботу, правильно розставляти пріоритети, знаходити найбільш критичні помилки раніше, а також розуміти ступінь тестового покриття на кожному етапі життєвого циклу розробки програмного забезпечення. Таким чином, головні переваги тестування на основі ризиків – зниження витрат на розробку, скорочення часу виходу на ринок та підвищення якості продукту.