Ціль і зміст тестового плану
У плані тестування описано тестування для проєктів розробки ПЗ. На планування впливають політика тестування та стратегія тестування організації, життєві цикли розробки та методи, що використовуються, сфера тестування, цілі, ризики, обмеження, можливість тестування та доступність ресурсів.
Планування тестування — це безперервна діяльність, яка виконується протягом життєвого циклу продукту. Зворотній зв’язок від тестової діяльності слід використовувати для визначення мінливих ризиків, щоб можна було скоригувати планування.
Планування може бути задокументовано в генеральному плані тестування та в окремих планах тестування для рівнів тестування, таких як тестування системи та приймальне тестування, або для окремих типів тестування, таких як тестування зручності використання та тестування продуктивності чи тестування безпеки.
Заходи з планування тестування можуть включати наступне:
- Визначення обсягу, цілей і ризиків тестування
- Визначення загального підходу до тестування
- Інтеграція та координація тестової діяльності в діяльність життєвого циклу програмного забезпечення
- Прийняття рішень щодо того, що саме тестувати, визначення ресурсів, необхідних для виконання різноманітних тестових дій, і способів проведення тестових дій
- Планування аналізу, проєктування, реалізації, виконання та оцінювання тестів на певні дати (наприклад, у послідовній розробці) або в контексті кожної ітерації (наприклад, у ітераційній розробці)
- Вибір метрик для моніторингу та контролю тестів
- Бюджет для тестової діяльності
- Визначення рівня деталізації та структури тестової документації
Приблизний зміст тестового плану
- Ідентифікатор плану тестування
- Вступ
- Тестові елементи
- Функції для перевірки
- Функції, які не підлягають тестуванню
- Підхід
- Критерії проходження/непроходження
- Критерії призупинення/відновлення
- Потреби середовища
- Потреби в кадрах і навчанні
- Обов’язки
- Розклад
- Планування ризиків і непередбачених ситуацій
- Дозволи
- Глосарій
Стратегія тестування та підхід
Стратегія тестування забезпечує узагальнений опис процесу тестування, зазвичай на рівні продукту або організації. Поширені типи тестових стратегій включають:
| Аналітичний | Цей тип стратегії тестування базується на аналізі певного фактора (наприклад, вимоги чи ризику). Тестування на основі ризику є прикладом аналітичного підходу, коли тести розробляються та пріоритезуються на основі рівня ризику. |
| На основі моделі | У цьому типі стратегії тестування тести розробляються на основі певної моделі певного необхідного аспекту продукту, такого як функція, бізнес-процес, внутрішня структура або нефункціональна характеристика (наприклад, надійність). Приклади таких моделей включають моделі бізнес-процесів, моделі станів тощо. |
| Методичний | Цей тип стратегії тестування базується на систематичному використанні деякого попередньо визначеного набору тестів або умов тестування, таких як класифікація поширених або ймовірних типів несправностей, перелік важливих характеристик якості . |
| Сумісність із процесом (або стандартом) | Цей тип стратегії тестування передбачає аналіз, розробку та впровадження тестів на основі зовнішніх правил і стандартів, таких як ті, що визначені галузевими стандартами, документацією процесу, або будь-яким процесом чи стандартом. |
| Консультативний | Цей тип тестової стратегії керується головним чином порадами, вказівками чи інструкціями зацікавлених сторін, експертів у бізнес-сфері чи експертів із технологій, які можуть перебувати поза командою тестування або поза самою організацією. |
| Неприхильний до регресії | Цей тип тестової стратегії мотивується бажанням уникнути регресії наявних можливостей. Ця стратегія тестування включає повторне використання існуючого тестового програмного забезпечення (особливо тест-кейсів і тестових даних), широку автоматизацію регресійних тестів і стандартні набори тестів. |
| Реактивний | У цьому типі стратегії тестування реагує на компонент або систему, що тестується, і на події, що відбуваються під час виконання тесту. Тести розроблені та впроваджені та можуть бути негайно виконані у відповідь на знання, отримані за результатами попередніх тестів. |
Відповідна стратегія тестування часто створюється шляхом поєднання кількох із цих типів стратегій тестування. Наприклад, тестування на основі оцінки ризику (аналітична стратегія) можна поєднати з дослідницьким тестуванням (реактивна стратегія); вони доповнюють один одного і можуть досягти більш ефективного тестування, якщо використовувати разом.
Тоді як стратегія тестування надає узагальнений опис процесу тестування, підхід до тестування адаптує стратегію тестування для конкретного проєкту. Тестовий підхід є відправною точкою для вибору методів тестування, рівнів тестування та типів тестування, а також для визначення критеріїв входу та критеріїв виходу.
Розробка стратегії базується на рішеннях, прийнятих щодо складності та цілей проєкту, типу продукту, що розробляється, та аналізу ризиків продукту. Обраний підхід залежить від контексту та може враховувати такі фактори, як ризики, безпека, доступні ресурси та навички, технологія, характер системи, цілі тестування та правила.
Критерії входу та виходу
Щоб здійснювати ефективний контроль за якістю програмного забезпечення та тестування, доцільно мати критерії, які визначають, коли певна тестова діяльність повинна початися та коли ця діяльність буде завершена.
Критерії входу (також називаються визначенням готовності в гнучкій розробці) визначають передумови для виконання певної тестової діяльності. Якщо критерії входу не виконані, ймовірно, що діяльність виявиться складнішою, тривалішою, дорожчою та ризикованішою.
Критерії виходу (також називаються визначенням виконаного в Agile-розробці) визначають, яких умов необхідно досягти, щоб оголосити рівень тестування або набір тестів завершеними. Критерії входу та виходу повинні бути визначені для кожного рівня тестування та типу тестування та відрізнятимуться залежно від цілей тестів.
Типові критерії входу включають:
- Наявність вимог, історій користувачів або моделей, які можна протестувати (наприклад, при дотриманні стратегії тестування на основі моделі)
- Наявність тестових завдань, які відповідають критеріям виходу для будь-яких попередніх рівнів тестування
- Наявність тестового середовища
- Наявність необхідних засобів тестування
- Наявність тестових даних та інших необхідних ресурсів
Типові критерії виходу включають:
- Заплановані випробування виконано
- Було досягнуто визначеного рівня покриття (наприклад, вимог, історій користувачів, критеріїв прийнятності, ризиків, коду)
- Кількість невирішених дефектів знаходиться в узгодженому ліміті
- Кількість оцінених дефектів, що залишилися, досить низька
- Оцінені рівні надійності, ефективності продуктивності, зручності використання, безпеки та інших відповідних характеристик якості є достатніми
Навіть якщо критерії виходу не виконуються, тестова діяльність також часто згортається через витрачений бюджет, завершення запланованого часу або тиск для виведення продукту на ринок. Припинення тестування за таких обставин може бути прийнятним, якщо зацікавлені сторони проєкту та власники бізнесу переглянули та прийняли ризик запуску без подальшого тестування.
Техніки оцінки
Оцінка тестових зусиль передбачає прогнозування обсягу пов’язаної з тестуванням роботи, необхідної для досягнення цілей тестового проєкту. Важливо пояснити зацікавленим сторонам, що оцінка ґрунтується на низці припущень і завжди має певну похибку. Оцінка для малих завдань зазвичай більш точна, ніж для великих. Тому, оцінюючи велике завдання, його можна розкласти на набір менших завдань, які потім, у свою чергу, можна оцінити.
| Оцінка на основі коефіцієнтів | У цій техніці, заснованій на показниках, цифри збираються з попередніх проєктів в організації, що дає змогу отримати «стандартні» коефіцієнти для подібних проєктів. Коефіцієнти власних проєктів організації (наприклад, взяті з історичних даних) зазвичай є найкращим джерелом для використання в процесі оцінки. Потім ці стандартні співвідношення можна використовувати для оцінки зусиль тестування для нового проєкту. Наприклад, якщо в попередньому проєкті співвідношення зусиль на розробку та тестування було 3:2, а в поточному проєкті зусилля на розробку очікується в 600 людино-днів, зусилля на тестування можна оцінити як 400 людино-днів. |
| Екстраполяція | У цьому методі, заснованому на показниках, вимірювання проводяться якомога раніше в поточному проєкті для збору даних. Маючи достатньо спостережень, зусилля, необхідні для роботи, що залишилася, можна приблизно оцінити шляхом екстраполяції цих даних (зазвичай шляхом застосування математичної моделі). Цей метод дуже підходить для ітераційних SDLC. Наприклад, команда може екстраполювати тестові зусилля в майбутній ітерації як усереднене значення з останніх трьох ітерацій. |
| Delphi | У цій ітераційній експертній техніці експерти роблять оцінки на основі досвіду. Кожен експерт окремо оцінює зусилля. Результати збираються, і якщо є відхилення, що виходять за межі узгоджених меж, експерти обговорюють свої поточні оцінки. Потім кожного експерта просять зробити нову оцінку на основі цього відгуку, знову окремо. Цей процес повторюється, поки не буде досягнуто консенсусу. Planning Poker — це варіант Wideband Delphi, який зазвичай використовується в розробці програмного забезпечення Agile. У Planning Poker оцінки зазвичай робляться за допомогою карток із числами, які представляють розмір зусиль. |
| Трибальна оцінка | У цій експертній методиці експерти роблять три оцінки: найбільш оптимістичну оцінку (a), найбільш ймовірну оцінку (m) і найбільш песимістичну оцінку (b). Остаточна оцінка (E) є їх середнім зваженим арифметичним. У найпопулярнішому варіанті цієї методики оцінка обчислюється як E = (a + 4*m + b) / 6. Перевагою цієї методики є те, що вона дозволяє експертам розрахувати похибку вимірювання: SD = (b – a) / 6. Наприклад, якщо оцінки (в людино-годинах) такі: a=6, m=9 і b=18, тоді остаточна оцінка становить 10±2 людино-години (тобто від 8 до 12 людино-годин), оскільки E = (6 + 4*9 + 18) / 6 = 10 і SD = (18 – 6) / 6 = 2. |
Тестові набори (Test Suites)
Тестові набори (test suites) – це колекція тестів, які зазвичай групуються разом для виконання в рамках тестування програмного забезпечення або системи. Кожен тест в тестовому наборі зазвичай призначений для перевірки певної функціональності, аспекту або властивості програми.
Основна мета тестових наборів – забезпечити повноту та вичерпність тестування програмного продукту шляхом включення різноманітних тестів, які перевіряють різні аспекти функціональності, продуктивності, безпеки та інших характеристик програмного забезпечення.
Тестові набори використовуються для організації і виконання тестів з метою перевірки правильності роботи програми або системи відповідно до специфікацій і очікувань. Вони можуть бути використані як для ручного, так і для автоматизованого тестування.
Користуючись тестовими наборами, розробники можуть організувати тестування, здійснювати контроль версій тестів, спрощувати виконання тестів на різних платформах або середовищах, а також автоматизувати процеси тестування для ефективності і надійності розробки програмного забезпечення.
Тестові набори зазвичай розробляються в рамках процесу розробки програмного забезпечення і зазвичай постійно оновлюються з розвитком програми, додаванням нових функцій або виправленням помилок. Вони є важливою частиною стратегії тестування програмного продукту для забезпечення його якості і надійності.
Пріоритезація тест-кейсів
Після того, як тестові кейси та процедури тестування визначені та зібрані в набори тестів, ці набори тестів можна впорядкувати в розклад виконання тестів, який визначає порядок їх виконання. При визначенні пріоритетів тестових випадків можна враховувати різні фактори. Найпоширенішими стратегіями пріоритезації тестових випадків є такі:
| Пріоритезація на основі ризиків, де порядок виконання тестів базується на результатах аналізу ризиків. Спочатку виконуються тестові випадки, що охоплюють найважливіші ризики. |
| Пріоритезація на основі покриття, де порядок виконання тесту базується на покритті (наприклад, покриття рішень). Тестові кейси, які досягають найвищого рівня покриття, виконуються першими. В іншому варіанті, що називається додатковим пріоритетом покриття, спочатку виконується тест кейс, який досягає найвищого покриття; кожен наступний тестовий кейс є тим, який досягає найвищого додаткового покриття. |
| Пріоритезація на основі вимог, де порядок виконання тестів базується на пріоритетах вимог, що відстежуються до відповідних тестів. Пріоритети вимог визначаються зацікавленими сторонами. Спочатку виконуються тестові кейси, пов’язані з найважливішими вимогами. |
В ідеалі тестові кейси повинні бути впорядковані для виконання на основі їх рівнів пріоритету, використовуючи, наприклад, одну із згаданих вище стратегій визначення пріоритетів.
Однак ця практика може не спрацювати, якщо тестові кейси або функції, що перевіряються, мають залежності. Якщо тест із вищим пріоритетом залежить від тесту з нижчим пріоритетом, тест із нижчим пріоритетом має бути виконаний першим.
Порядок виконання тесту також повинен враховувати наявність ресурсів. Наприклад, потрібні інструменти тестування, тестове середовище або люди, які можуть бути доступні лише протягом певного періоду часу.
Тестова піраміда
Тестова піраміда — це модель, яка показує, що різні тести можуть мати різну деталізацію. Модель тестової піраміди підтримує команду в автоматизації тестування та в розподілі тестових зусиль, показуючи, що різні цілі підтримуються різними рівнями автоматизації тестування.
Шари пірамід представляють групи тестів. Чим вищий рівень, тим менша деталізація тесту, ізоляція тесту та час виконання тесту. Тести на нижньому рівні невеликі, ізольовані, швидкі та перевіряють невелику частину функціональності, тому зазвичай їх потрібно багато, щоб досягти прийнятного покриття. Верхній рівень представляє складні наскрізні тести високого рівня. Ці тести, як правило, повільніші, ніж тести нижчих рівнів, і зазвичай вони перевіряють велику частину функціональних можливостей, тому зазвичай потрібно лише кілька з них, щоб досягти прийнятного покриття.
Кількість і назва шарів може відрізнятися. Наприклад, оригінальна модель тестової піраміди (Кон 2009) визначає три рівні: «модульні тести», «сервісні тести» та «тести інтерфейсу користувача». Інша популярна модель визначає тести компонентів, тести інтеграції (інтеграції компонентів) і наскрізні тести. Також можна використовувати інші рівні тестування.
Тетові квадранти
Тестові квадранти, визначені Брайаном Маріком (Marick 2003, Crispin 2008), групують рівні тестування з відповідними типами тестування, діяльністю, технікою тестування та робочими продуктами в розробці програмного забезпечення Agile.
Модель підтримує керування тестуванням у візуалізації, щоб гарантувати, що всі відповідні типи тестів і рівні тестів включені в SDLC, і в розумінні того, що деякі типи тестів більш релевантні для певних рівнів тестування, ніж інші. Ця модель також надає спосіб диференціації та опису типів тестів для всіх зацікавлених сторін, включаючи розробників, тестувальників і представників бізнесу.
У цій моделі тести можуть стосуватися бізнесу або технологій. Тести також можуть підтримувати команду (тобто керувати розробкою) або критикувати продукт (тобто вимірювати його поведінку проти очікувань). Поєднання цих двох точок зору визначає чотири квадранти:
- Квадрант Q1 (звернення до технологій, підтримка команди). Цей квадрант містить компонентні тести та тести інтеграції компонентів. Ці тести мають бути автоматизовані та включені в процес CI.
- Квадрант Q2 (бізнес, підтримка команди). Цей квадрант містить функціональні тести, тести історій користувача, прототипи користувацького досвіду, тестування API та моделювання. Ці тести перевіряють критерії прийнятності та можуть бути ручними або автоматизованими.
- Квадрант Q3 (бізнес, критика продукту). Цей квадрант містить дослідницьке тестування, тестування зручності використання, користувацьке приймальне тестування. Ці тести орієнтовані на користувача і часто ручні.
- Квадрант Q4 (розгляд технології, критика продукту). Цей квадрант містить димові тести та нефункціональні тести (крім тестів зручності використання). Ці тести часто автоматизовані.
В цьому відео поговоримо про тестовий план і планування:
00:00 Ціль і зміст тестового плану
05:20 Стратегія тестування та підхід
10:16 Критерії входу та виходу
14:34 Техніки оцінки
21:18 Тестові набори (Test Suites)
22:54 Пріоритезація тест-кейсів
26:18 Тестова піраміда
28:12 Тетові квадранти