Практичний посібник з шаблонами для QA-команд будь-якого розміру

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

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

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

Що насправді означає ризик-орієнтоване тестування

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

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

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

Ця відмінність має значення, коли проекти тривають довго, бюджети скорочуються, а релізи стискаються. Стратегія, що базується на ризиках, дає вам обґрунтовану відповідь на питання: “Якщо у нас є лише три дні, що ми будемо тестувати?”

Крок 1: Визначте, що може піти не так

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

Проведіть семінар з ідентифікації ризиків

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

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

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

Нанесіть ризики на карту системних областей

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

Крок 2: Оцініть кожен ризик

Стандартна модель оцінює ризики за двома параметрами: ймовірність (наскільки ймовірна ця подія?) та вплив (наскільки погано буде, якщо вона станеться?). Перемноживши ці два показники, ви отримаєте номер пріоритету ризику, який можна використовувати для ранжування елементів.

Ось простий шаблон підрахунку балів:

Зробіть шкалу простою. Матрицю від 1 до 5 легше застосовувати послідовно, ніж матрицю від 1 до 10, а послідовність має більше значення, ніж точність, коли бали за своєю суттю є оцінками.

Калібрувальний вплив

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

• Фінансові ризики (прямі втрати доходів, відшкодування, штрафи)
• Погіршення користувацького досвіду (чи є це основною подорожжю користувача?)
• Регуляторні або комплаєнс-наслідки
• Репутаційна шкода (чи потрапить це в новини, чи згенерує звернення до служби підтримки?)
• Вартість відновлення (скільки часу потрібно, щоб виявити, діагностувати та виправити на виробництві?)

Калібрування ймовірності

Ймовірність - це ймовірність збою протягом цього циклу випуску, а не будь-коли. Нещодавні зміни коду, складність, зовнішні залежності та рівень дефектів в минулому - все це впливає на цей показник. Області, які не змінювалися протягом двох років і мають солідну історію тестування, можуть обґрунтовано отримати 1. Абсолютно нова інтеграція, написана під тиском дедлайнів, ймовірно, заслуговує на 4 або 5.

Крок 3: Визначте рівні тестового покриття

Маючи реєстр ризиків з оцінками, ви можете перевести рівні ризиків у конкретні рішення щодо покриття. Трирівнева модель добре працює для більшості команд:

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

Визначення рівнів має бути узгоджене всією командою до початку тестування, а не вирішуватися в односторонньому порядку QA. Це те, що перетворює план тестування на спільне зобов’язання.

Крок 4: Створіть план тестування за рівнями

Коли ви визначили рівні, структура плану тестування випливає природно. Ви не пишете тест-кейси для кожної функції послідовно - ви розподіляєте зусилля відповідно до карти ризиків, яку ви вже створили.

Розподіляйте час пропорційно

Корисне емпіричне правило: Області T1 повинні отримувати приблизно 60-70% від загального обсягу ваших зусиль з тестування, області T2 - близько 20-30%, а області T3 - решту. Точні пропорції змінюються залежно від профілю ризику конкретного релізу - реліз без змін T1 повинен мати зовсім інший розподіл зусиль, ніж той, що зачіпає основну бізнес-логіку.

Вкажіть критерії входу та виходу для кожного рівня

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

• T1: Виконано всі скриптові тестові кейси, жодного відкритого критичного або високого рівня дефекту, завершено дослідницьку сесію із задокументованими висновками
• T2: Тести шляху пройдено успішно, відкрито не більше двох середніх дефектів з прийнятими обхідними шляхами
• T3: Димовий набір проходить, блокувальників немає

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

План повторного тестування після виправлень

Стратегії, засновані на ризиках, часто недооцінюють зусилля, необхідні для повторного тестування після виправлення дефектів. Враховуйте час на повторне тестування в своїх оцінках T1 і T2 явно. Виправлення в зоні високого ризику повинно викликати цілеспрямовану регресію навколишньої функціональності, а не просто перевірку одного дефекту.

Крок 5: Ведення та оновлення реєстру ризиків

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

Практичні каденції, які добре працюють:

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

Типові помилки, яких слід уникати

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

Поєднання ризику зі складністю

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

Оцінка за комітетами без фасилітатора

Під час групового підрахунку балів можна досягти хибного консенсусу, коли всі дотримуються першого числа, названого вголос. Використовуйте такі методи, як мовчазне незалежне підбиття підсумків перед груповим обговоренням або структуровані підказки щодо розбіжностей (“Хто вважає, що ця цифра має бути вищою? Чому?”), щоб виявити справжні розбіжності.

Ставлення до стратегії як до статичної величини

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

Пропуск документації

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

Коли використовувати спрощену версію

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

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

Збираємо все докупи

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

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

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

Найкраща стратегія тестування - це не та, яка тестує найбільше. Це та, яка тестує правильні речі - і може пояснити, чому.