Техніки тест-дизайну на реальних прикладах

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Всім привіт, мене звати Емма, я QA Lead в компанії Gearheart. У попередній статті ми розглянули різницю між тест-аналізом та тест-дизайном, визначили покроковий алгоритм тест-аналізу на рівні продукту та на рівні фічі. У цій статті ми детально розглянемо базові техніки тест-дизайну.

ISTQB (міжнародна організація, що займається сертифікацією тестувальників) класифікує техніки тест-дизайну так:

• Black-box техніки — базуються на аналізі документації, яка описує вимоги щодо роботи системи (requirements, specifications, use cases, user stories), без прив’язки до її внутрішньої структури.
• White-box техніки — ґрунтуються на аналізі архітектури системи, її внутрішньої структури та коду тестового об’єкта.
• Experience-based техніки — використовують знання та досвід розробників, тестувальників і користувачів для проектування тестів.

Ми розглянемо найпоширеніші техніки з black-box групи. Опис деяких технік навмисно спрощений та певні деталі пропущені для кращого розуміння, але практична користь при цьому зберігається. Якщо ви хочете зануритись глибше, рекомендую переглянути матеріали для ISTQB Test Analyst сертифікації.

Умовно техніки тест-дизайну можна розділити на дві категорії:

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

Техніки для перевірки даних

Equivalence Partitioning

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

Подивимось, як застосувати цю техніку на прикладі такої фічі як Create Account в Slack застосунку.

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

• Full Name;
• Password;
• Email Newsletter.

Кожен параметр має певні вимоги щодо того, які значення він повинен приймати:

• Full Name:
  • 1 — 50 characters;
  • Required.
• Password:
  • 6 — 30 characters;
  • Required.
• Email Newsletter:
  • Yes — by default;
  • No.

Згідно з вимогами, параметр Full Name має приймати від 1 до 50 символів, і ми можемо зробити припущення, що будь-яке значення із символами від 1 до 50 буде оброблятися однаково, тобто буде виконуватися один і той самий код.

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

Такий клас називається валідним, оскільки містить коректні значення, які система повинна сприймати. Існують також невалідні класи, що містять значення, які система повинна відхилити. Невалідні класи для Full Name параметра містять значення більше 50 символів і менше одного символу, тобто порожнє.

Для параметра Password маємо такі еквівалентні класи:

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

Зверніть увагу, що для параметра Password додатково присутня перевірка порожнього значення, незважаючи на те що воно входить в один клас разом зі значенням 5, значення «0» рекомендують завжди перевіряти окремо.

Оскільки параметри Full Name та Password мають текстовий тип даних, крім довжини значення, ми також повинні враховувати сам вміст даних, що може містити:

• літери;
• числа;
• символи;

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

• латиниця;
• кирилиця;
• ієрогліфи.

Припустимо, у нас є наступні додаткові вимоги:

• Full Name параметр приймає всі алфавіти та числа, не приймає символи.
• Password параметр приймає лише комбінацію латинських літер, чисел і символів.

Ось як тепер виглядатиме наш набір тестових даних:

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

Застосування

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

Класи можуть існувати в багатьох місцях і не обмежені діапазонами чисел. Наприклад як у випадку з параметром Email Newsletter, що має Boolean значення — Yes (true) знаходиться в одному класі, а No (false) — в іншому. Крім того, розбиття на класи може застосовуватися не тільки до вхідних даних, але і тестових середовищ, типів і версій операційних систем, браузерів, конфігурацій тощо.

Види дефектів

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

Недоліки

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

Boundary Value Analysis

Boundary Value Analysis (BVA) техніка використовується в поєднанні з Equivalence Partitioning. Існує гіпотеза, що часто дефекти виникають при обробці значень, які знаходяться на границях еквівалентних класів, тому рекомендують додатково перевіряти коректність роботи таких значень.

Існує два підходи до BVA-техніки

1. Two-value boundary

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

Наприклад, для еквівалентного класу від 1,00 до 10,00:

• Значення нижньої границі — 1,00 і 0,99.
• Значення верхньої границі — 10.00 та 10.01.

2. Three-value boundary

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

Наприклад, для еквівалентного класу від 1.00 до 10.00:

• Значення нижньої границі — 0,99, 1,00 і 1,01.
• Значення верхньої границі — 9,99, 10,00 та 10,01.

Three-value boundary підхід забезпечує більш глибоке тестове покриття, хоча і займає більше часу. Рішення про те, який підхід використовувати має прийматись на основі ризиків, пов’язаних з об’єктом, що тестується.

Застосуймо two-value boundary підхід для параметрів реєстраційної форми, яку ми розглядали вище:

Full Name

Валідний клас: 1–50

• значення нижньої границі: 1 і 0;
• значення верхньої границі: 50 і 51.

Невалідний клас: 0

• в класі тільки одне значення — 0.

Невалідний клас: 51 і більше

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

Password

Валідний клас: 6–30

• значення нижньої границі: 6 і 5;
• значення верхньої границі: 30 і 31.

Невалідний клас: 0–5

• значення нижньої границі: 0;
• значення верхньої границі: 5 і 6.

Невалідний клас: 31 і більше

• значення нижньої границі: 31 і 30;
• значення верхньої границі: аналогічно полю Full Name полю, достатньо перевірити лише значення нижньої границі.

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

Ось наш розширений набір тестових даних з граничними значеннями:

Застосування

Boundary Value Analysis техніка є розширенням Equivalence Partitioning техніки, яка застосовується коли елементи еквівалентних класів впорядковані, тобто коли ми можемо сказати, що один елемент більший або менший за інший.

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

У прикладі реєстраційної форми, параметр Email Newsletter має два класи — Yes і No, ми не можемо використовувати BVA для нього, тому що у цих класів нема визначених границь, ми або в класі, або ні.

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

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

Види дефектів

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

Недоліки

Точність цієї методики залежить від точності визначення еквівалентних класів.

Іншим недоліком є ризик приділити занадто багато часу на досить рідкісні юз-кейси і недостатньо часу на решту функціоналу.

Розробка тестів

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

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

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

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

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

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

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

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

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

Pairwise Testing

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

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

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

Застосуймо цю техніку до такої фічі як Notifications Settings у Slack. Скористаємося інструментом Allpairs.

крок. Підготуємо список параметрів зі значеннями.

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

крок. Запускаємо інструмент із підготовленими даними.

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

Ось набір тест-кейсів, які згенерував інструмент:

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

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

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

Застосування

Pairwise Testing техніка корисна для тестування функціоналу з великою кількістю вхідних параметрів з декількома можливими значеннями, але не обмежується нею.

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

Наприклад, на поведінку веб застосунку можуть впливати наступні фактори:

• операційна система;
• браузер;
• мова застосунку;
• спосіб авторизації.

Ми можемо застосувати той самий інструмент для створення тестів.

Ось список параметрів зі значеннями:

Ось згенеровані тести:

Переглядаючи тести, ми бачимо, що в TC 2 і TC 6 трапляються неможливі комбінації — Mac OS і Edge та Windows і Safari. Нам потрібно замінити їх, але так, щоб зберегти інші комбінації параметрів у цих рядках (Language і Authorization).

Для цього можна зробити такі зміни:

• TC 2: щоб зберегти пару Spanish та Email/Password, ми можемо використати TC 13 і замінити Windows на Mac, оскільки Windows має позначку ~, що означає, що це значення не обов’язкове;
• TC 6: щоб зберегти пару Spanish та SSO, ми можемо використати TC 14 — залишити значення Windows, Firefox і Spanish та замінити соціальну мережу на SSO.

Тепер таблиця з тестами виглядатиме так:

Види дефектів

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

Недоліки

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

Техніки для перевірки бізнес-логіки

Наразі ми розглянули техніки тест-дизайну, які корисні для перевірки валідації даних. Далі ми розберемо дві поширені техніки для перевірки бізнес-логіки.

State Transition Testing

State Transition Testing — техніка, яка використовується для перевірки здатності тестового об’єкта входити та виходити з визначених станів використовуючи валідні переходи.

Розгляньмо кроки цієї техніки:

крок. Визначаємо стани об’єкта:

• стани відображають різні стадії, на яких може перебувати об’єкт протягом свого життєвого циклу;
• кожен об’єкт може мати різний стан залежно від того, що ми з ним робимо;
• стан може змінюватися з плином часу, через обробку даних або дій, що виконуються над об’єктом;
• об’єкт не може перебувати відразу в двох станах, і в той же час він завжди існує хоча б в одному;
• приклад: об’єкт User може мати такі стани, як Invited, Active, Deleted.

крок. Визначаємо дії об’єкта:

• дії призводять до того, що тестовий об’єкт переходить з поточного стану в новий або залишається в тому самому стані;
• діями можуть бути дії користувача, реакція системи або інші зовнішні стимули;
• приклад: дії для об’єкта User можуть бути такі як, Invite, Register, Delete.

крок. Визначаємо переходи:

• перехід означає зміну стану, яка відбувається після виконання дії;
• приклад: об’єкт User може перейти зі стану Invited в Active, коли користувач завершить процес реєстрації.

Техніка State Transition Testing може бути представлена у вигляді діаграми або у вигляді таблиці. Ми розглянемо обидва варіанти.

Повернемося до Slack і застосуємо цю техніку до об’єкта Message. Спочатку визначимо можливі стани та дії об’єкта:

Тепер ми готові намалювати діаграму станів та переходів, де еліпси відображають стани, а стрілки — дії:

На основі отриманої діаграми ми можемо скласти тест кейси. Для мінімального покриття рекомендовано перевіряти всі переходи між станами:

• TC 1: Draft — Sent — Deleted
• TC 2: Draft — Scheduled — Sent
• TC 3: Draft — Scheduled — Deleted
• TC 4: Draft — Deleted

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

• Current State: список усіх станів об’єкта.
• Action: список усіх дій об’єкта, який дублюється для кожного стану.
• New State: стан об’єкта після завершення дії.
• Expected Result: описує як система повинна реагувати на дію.

Ось як таблиця переходу станів може виглядати для об’єкта Message:

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

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

Перевірка невалідних переходів повинна бути обов’язковою для safety-critical програмного забезпечення, а також це хороший старт для security тестування.

Застосування

State Transition Testing техніка підходить для тестування програмного забезпечення, де об’єкти мають визначені стани та дії, які спричиняють переходи між цими станами. Також ця техніка є чудовим інструментом для документування системних вимог, які описують стани та пов’язані з ними переходи.

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

Види дефектів

До типових дефектів належать:

• неможливість досягти деяких станів;
• неможливість виконання валідних переходів;
• можливість виконання невалідних переходів.

Недоліки

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

Decision Table

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

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

крок. Складаємо список умов.

У нас є такі умови, які впливають на сповіщення:

• Notification settings are on or off.
• Do not disturb mode is on or off.
• The channel is muted or not.

крок. Складаємо список пов’язаних дій.

Існують різні типи сповіщень, які можуть відображатись користувачу:

• Banner preview;
• Bold channel name;
• Red dot on the application icon.

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

крок. Визначаємо кількість стовпців в таблиці.

Для розрахунку кількості стовпців, нам потрібно перемножити кількість значень кожної умови. У нашому прикладі ми маємо три умови, кожна з яких має два можливих значення (on і off), отримаємо 2×2 х 2 = 8 стовпців.

крок. Заповнюємо стовпці.

Спочатку заповнюємо рядки з умовами за таким шаблоном:

• Перша умова: половина стовпців — Так, половина — Ні.
• Наступна умова: чверть Так, чверть Ні, чверть Так і чверть Ні.
• Остання умова: чергуємо Так і Ні.

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

Зрештою ми отримали таблицю, де кожен стовпець є правилом (decision rule), яке визначає унікальну комбінацію умов, що призводить до виконання певних дій. Таким чином, кожен стовпець стає тест кейсом, де в умовах вказуються вхідні дані, а в діях — очікуваний результат.

Таблиці рішень, в яких всі умови мають булеві значення (yes/no, true/false), як у прикладі вище, називаються limited-entry таблицями. Якщо умови можуть приймати декілька значень, такі таблиці називаються extended-entry таблицями.

Розгляньмо таку фічу, як Transfer Money, де комісія за транзакцію залежить від умов:

• Card type: standard, business, premium;
• Transaction amount: less than 1k, between 1k and 10k, more than 10k;
• Foreign exchange: yes or no.

І зрештою можуть виконуватись такі дії:

• Transaction fee;
• Conversion fee.

Далі розраховуємо кількість стовпців в таблиці. Перша умова має три значення, друга умова має три діапазони значень, і остання умова має два значення, перемножуємо 3×3 x 2 і отримуємо 18 стовпців.

Тепер заповнюємо дії, де розмір комісії залежить від комбінації умов:

Як зазначалось вище, ми можемо використовувати кожен стовпець як тест кейс, проте ви можете помітити, що умова Transaction Amount має діапазон значень у кожному стовпці, і під час тестування нам потрібно буде використовувати конкретні значення. Щоб обрати тестові дані для кожного діапазону, ми можемо застосувати вже знайомі нам техніки Equivalence Partitioning та Boundary Value Analysis.

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

• TC 1: Card Type: Standard, Transaction Amount: 500, Foreign Exchange: Yes;
• TC 2: Card Type: Standard, Transaction Amount: 1, Foreign Exchange: Yes;
• TC 3: Card Type: Standard, Transaction Amount: 999, Foreign Exchange: Yes;
• TC 4: Card Type: Standard, Transaction Amount: 0, Foreign Exchange: Yes.

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

Зменшити кількість правил в таблиці рішень допоможуть такі рекомендації:

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

Застосування

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

Цей метод особливо корисний, коли вимоги документуються у вигляді блок-схем або бізнес-правил з твердженнями на кшталт «якщо A і B істинні, то виконайте дію C».

Види дефектів

Типові дефекти включають неправильну обробку певних комбінацій умов, що може призвести до наступних проблем:

• виконуються неправильні дії;
• правильні дії не виконуються;
• умови взаємодіють некоректно.

Недоліки

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

Висновок

Отже ми розглянули базові техніки тест-дизайну, приклади їх застосування, недоліки та типові дефекти.

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

Рецензент статті — Геннадій Міщевський.