Наше деловое партнерство www.banwar.org

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

Думаю всі знають, що повноцінний процес розробки тест-кейсів будується на документації. Ми аналізуємо, виділяємо вимоги з документації і потім покриваємо вимоги позитивними і негативними тест-кейсами. Цей підхід в тестуванні називається test-case based, тобто тестування на основі тест-кейсів. Багато хто звик так працювати обгрунтовуючи це тим, що так ми можемо звести до мінімуму виникнення дефектів на бою.

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

Ми продовжуємо відштовхуватися від вимог, а отже, і тест-кейсів, які їх покривають.

Але в 1994 році Джеймс Бах став говорити про новий підхід до управління тестуванням, заснованого на проблемах. Це одне з перших згадок того, що можна тестувати програмне забезпечення відштовхуючись від проблем, з якими можна зіткнутися при впровадженні програмного продукту.

Вперше, Джеймс Бах в своїй статті «The Challenge of« Good Enough »Software» починає говорити про те, що якщо ми мінімізуємо або виключимо всі проблеми, які можуть бути пов'язані з якістю нашого продукту, то за замовчуванням якість нашого продукту буде високим.

І в цілому він мав рацію, тому що якщо ми поставимо себе на місце користувача системи і подивимося з його боку, з якими проблемами він може зіткнутися при роботі з продуктом і виключимо їх, то у користувача не буде проблем, а отже, він буде задоволений роботою продукту.

Після вже в 1996, Рональд Хігьера і Яків Хаймес випускають свою працю «Software Risk Managment», в якому описують методології управління ризиками для ПО. Напевно саме ця робота і послужила відправною точкою для підходу Risk-Based Testing, тому що буквально через 3 роки Джеймс Бах починає говорити про незрозумілою теорії в вакуумі «Еврестіческом методі тестуванні на основі ризиків», в якому з'являється відсилання до критеріїв якості,

Основні критерії можуть бути внутрішніми і зовнішніми.

До внутрішніх відносяться:

• Уразливості: Які недоліки і збої можуть мати компоненти системи?
• Загрози: Які вхідні дані або ситуації можуть бути причиною збою в роботі компонента системи?
• Втрати: Хто або що може привести до потенційних фейл і до чого це призведе?

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

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

Таким чином відміну внутрішніх ризиків від зовнішніх в тому, що внутрішній ризики відповідають на питання:

«Які ризики можуть бути пов'язані саме з внутрішньою складовою нашого продукту?»

«Який вплив (подія) на наш продукт може привести до ризику виникнення проблем?»

Складно? ніхто не говорив що буде легко! 🙂

Перейдемо до зовнішніх ризиків.

Розділити їх можна на 3 складових:

• Модель якості продукту
• загальні ризики
• доменні ризики

Модель якості - це найбільш знайома всім система якості ПО по ISO 25010.

Основними критеріями якості служать 8 характеристик якості продукту.

Ці характеристики призначені, що максимально всебічно покрити вимоги до якості продукту, а значить, на кожну характеристику можуть лягати певні ризики при її невиконанні.

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

Ну і останнє, це доменні ризики.

Доменні ризики - це ризики, пов'язані з працездатністю ПО, тому що для того, щоб визначити їх, ми можемо просто продовжити речення:

«Ми можемо зіткнутися з проблемами, які пов'язані з ....»

Це може бути і інсталяція додатка, і завантаження файлів, зміна налаштувань і інше.

На цьому можна вважати, ми трохи розібралися з теорією управління ризиками і тепер перейдемо до підходів, які можуть застосовуватися в risk-based testing.

Як ви вже зрозуміли, модель тестування, заснована на ризиках, дозволяє тестувати функціонал, грунтуючись на ймовірності виникнення проблем. Це дуже характерно для гнучких методологій, таких як Scrum, де на на зустрічі з формування беклога спринту, спільна команда проекту може обговорити всі можливі проблеми, пов'язані з реалізацією функціоналу системи і визначити набір перевірок для їх виключення.

На поточний момент існує безліч технічних підходів у тестуванню, заснованому на ризику, але тим не менше я виділяю наступні:

• Failure Mode and Effect Analysis (FMEA)
• Fault Tree Analysis (FTA)

В цілому, звичайно, це моделі оцінки ризиків продукту, але з розвитком тестування в окремий процес, вони знайшли застосування і в тестуванні.

І першим, і найбільш популярним підходом до risk-based testing є модель FMEA.

FMEA (Failure mode and effect analysis) - модель аналізу причин і наслідків відмов системи, яка визначає потенційні дефекти в системі і причини їх виникнення.

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

Для зміни таких збоїв використовується 3 показника:

• серйозність
• пріоритет
• імовірність

Розглянемо на прикладі. Ми маємо систему, яка автоматизує бізнес процес видачі кредитних продуктів кінцевому користувачеві.

І наша система виконує 3 основні функції:

1. оформлення кредиту
2. закриття кредиту
3. Формування документів для клієнта

В ході брейншторм команда проекту визначає основні ризики системи:

• Некоректний розрахунок процентної ставки по кредиту
• Зайві кошти можуть не перевестися на рахунок клієнта при закритті кредиту
• Система може впасти під навантаженням в 300 користувачів
• Відсутність можливості автоматичного друку документів

Шкала вимірювання може залежати від проектної специфіки, але я розгляну варіант з вимірюванням за шкалою від 1 до 4, де 1 - блокуючий ефект, а 5 - незначний ефект.

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

Серйозність (S):

Імовірність (L):

Після проведеного аналізу виконується розрахунок показника RPN (Risk Priority Number)

RPN = S * P * L

У підсумку ми отримуємо розрахунок пріоритезацію ризиків щодо тестування ПО:

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

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

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

На противагу моделі FMEA часто ставиться модель FTA.

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

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

У класичному розумінні рівні моделі FTA виглядають так:

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

Візуально, це буде виглядати так:

Разом, ми отримуємо фактично повний аналіз проблем, з якими ми можемо зіткнутися в ході тестування функціоналу. Відмінність FTA від FMEA в тому, що FTA більше орієнтована на функціональність системи, а FMEA на бізнес процеси. Саме тому, зважаючи на складність складання FTA, більшість застосовують модель FMEA.

Крім цих моделей прогнозування ризиків, існує ще кілька підходів, таких як:

• ХАССП
• Cost of Exposure technique
• Quality Function Deployment (QFD)

Розбір цих моделей може зайняти ще 20 годин і n-е кількості тексту буде дуже довгим, тому в цій статті я їх розглядати не буду.

Дам лише невеликі визначення.

HACCP (Hazard Analysis and Critical Control Points) - аналіз ризиків і критичні контрольні точки, концепція, що передбачає систематичну ідентифікацію, оцінку і управління небезпечними чинниками, що суттєво впливають на продукт.

Більш докладно концепція ХАССП розглядається в ГОСТ Р 51705.1, але важливо розуміти, що цей документ не пов'язаний з ІТ і застосування цього підходу в тестуванні потребує серйозного доопрацювання.

Cost of Exposure technique - назва говорить сама за себе. Цей підхід мало відомий, але суть його в тому, що будь-які ризики в тестуванні можна порахувати шляхом перемноження значення ймовірності ризику на середню вартість (втрати) при настанні всіх рісков.Такой підхід дуже підходить для тих, хто задає фрази:

«Навіщо платити за тестування 100 рублів, якщо наш дефект буде коштує всього 50 рублів».

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

Ну, і наостанок, розглянемо, QFD (Quality Function Deployment).

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

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

Risk-Based Testing дозволяє скоротити обсяги тестування за рахунок пріоритетності перевірок і їх точної спрямованості. Звичайно ж у моделі є недоліки, але, хто не ризикує, той не перемагає!

Сподіваюся було корисно!