Category: Тестування ПЗ

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

Покриття коду (Code Coverage)	Визначає ступінь того, наскільки велика частина програмного коду була покрита тестами. Це може бути виміряно у відсотках і включати різні види покриття, такі як покриття операторів, покриття рішень, функціональне покриття тощо.
Щільність дефектів (Defect Density)	Розраховується як кількість виявлених дефектів на одиницю вимірювання, наприклад, на кількість рядків коду. Це дає уявлення про якість коду та ефективність тестового процесу.
Ступінь виконання тестів (Test Execution Progress)	Визначається як відношення кількості виконаних тестів до загальної кількості запланованих тестів. Це дає уявлення про прогрес тестування та може бути корисним для планування та оцінки витрат на тестування.
Кількість неспівпадінь (Mismatch Count)	Кількість випадків, коли фактичні результати тестів відрізняються від очікуваних результатів. Це допомагає виявити невідповідності між функціональністю та вимогами.
Середній час виявлення дефектів (Average Defect Detection Time)	Середній час, який потрібен для виявлення дефектів в процесі тестування після введення коду. Ця метрика може допомагати в оцінці ефективності процесів тестування та розробки.
Інтенсивність виявлення дефектів (Defect Discovery Rate)	Кількість нових дефектів, виявлених протягом певного періоду, такого як тиждень чи місяць. Це дозволяє виявляти тенденції та зміни в якості продукту.
Співвідношення успішних тестів до загальної кількості тестів (Pass Rate)	Визначає, який відсоток тестів пройшов успішно. Це допомагає в оцінці стабільності та готовності продукту до випуску.
Час виконання тестів (Test Execution Time)	Кількість часу, який витрачається на виконання всіх тестів. Це може вказувати на ефективність тестового процесу та можливість оптимізації.
Відсоток покриття ризиків (Risk Coverage Percentage)	Визначає, наскільки ризики, визначені в аналізі ризиків, були охоплені тестами. Це допомагає в управлінні ризиками та забезпеченні високої якості продукту.
Вартість виявлення дефекту (Cost per Defect)	Визначає, скільки коштує виявлення одного дефекту. Це може допомагати в оцінці ефективності тестових процесів та ефективності виправлення дефектів.

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

В цьому відео поговоримо про метрики у тестуванні:
00:00 Покриття коду, Щільність дефектів, Ступінь виконання тестів
02:05 Кількість неспівпадінь, Середній час виявлення дефектів, Інтенсивність виявлення дефектів, Співвідношення успішних тестів до загальної кількості тестів
04:24 Час виконання тестів, Відсоток покриття ризиків, Вартість виявлення дефекту

Матриця покриття тестування

Матриця покриття тестування (Test Coverage Matrix) – це артефакт у сфері тестування програмного забезпечення, який використовується для візуалізації ступеня покриття тестами функціональності програмного продукту або системи. Цей інструмент дозволяє визначити, які частини програми були протестовані, а які залишаються непротестованими.

Основні компоненти матриці покриття тестування можуть включати:

1. Функціональні області або модулі: Розділи програми або системи, які визначаються на основі їхньої функціональності.
2. Тести або тестові сценарії: Конкретні тести або сценарії, які використовуються для перевірки певної функціональності.
3. Стан тестування: Інформація про те, чи пройшов тест для конкретної області чи модуля.

Матриця покриття тестування може бути представлена у вигляді таблиці, де рядки відповідають функціональним областям чи модулям, стовпці – тестам, а комірки містять інформацію про те, чи пройшов тест для конкретної області. Зазвичай використовують маркери, такі як “пройдено,” “не пройдено” або “не протестовано.”

Переваги використання матриці покриття тестування включають:

1. Візуалізація покриття тестами: Зручний спосіб визначення того, які частини програми були протестовані, а які – ні.
2. Виявлення пробілів у тестуванні: Допомагає виявляти області, які не були враховані в тестових сценаріях, і можуть вимагати додаткового тестування.
3. Планування тестових зусиль: Дозволяє команді тестування зосередитися на тестуванні конкретних функціональних областей або модулів, які залишилися непротестованими.
4. Відстеження прогресу тестування: Допомагає визначити, наскільки вдало виконується тестування протягом розвитку проекту.

Одним з підтипів цих матриць є RTM (Requirement Traceability Matrix) – матриця відстеження вимог.

Бізнес вимога №	Технічна вимога №	ID Теси Кейса
BR1	TR1	TC-1
BR2	TR2	TC-2
BR3	TR3	TC-3

Звіти про виконання тестування

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

Зазвичай, звіти про виконання тестування включають такі елементи:

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

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

Документація з автоматизації тестування

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

Основні елементи документації з автоматизації тестування можуть включати:

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

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

В цьому відео поговоримо про:
00:00 Матриця покриття тестування
03:34 Звіти про виконання тестування
05:54 Документація з автоматизації тестування

Ціль і зміст тестового плану

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

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

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

Заходи з планування тестування можуть включати наступне:

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

Приблизний зміст тестового плану

1. Ідентифікатор плану тестування
2. Вступ
3. Тестові елементи
4. Функції для перевірки
5. Функції, які не підлягають тестуванню
6. Підхід
7. Критерії проходження/непроходження
8. Критерії призупинення/відновлення
9. Потреби середовища
10. Потреби в кадрах і навчанні
11. Обов’язки
12. Розклад
13. Планування ризиків і непередбачених ситуацій
14. Дозволи
15. Глосарій

Стратегія тестування та підхід

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

Аналітичний	Цей тип стратегії тестування базується на аналізі певного фактора (наприклад, вимоги чи ризику). Тестування на основі ризику є прикладом аналітичного підходу, коли тести розробляються та пріоритезуються на основі рівня ризику.
На основі моделі	У цьому типі стратегії тестування тести розробляються на основі певної моделі певного необхідного аспекту продукту, такого як функція, бізнес-процес, внутрішня структура або нефункціональна характеристика (наприклад, надійність). Приклади таких моделей включають моделі бізнес-процесів, моделі станів тощо.
Методичний	Цей тип стратегії тестування базується на систематичному використанні деякого попередньо визначеного набору тестів або умов тестування, таких як класифікація поширених або ймовірних типів несправностей, перелік важливих характеристик якості .
Сумісність із процесом (або стандартом)	Цей тип стратегії тестування передбачає аналіз, розробку та впровадження тестів на основі зовнішніх правил і стандартів, таких як ті, що визначені галузевими стандартами, документацією процесу, або будь-яким процесом чи стандартом.
Консультативний	Цей тип тестової стратегії керується головним чином порадами, вказівками чи інструкціями зацікавлених сторін, експертів у бізнес-сфері чи експертів із технологій, які можуть перебувати поза командою тестування або поза самою організацією.
Неприхильний до регресії	Цей тип тестової стратегії мотивується бажанням уникнути регресії наявних можливостей. Ця стратегія тестування включає повторне використання існуючого тестового програмного забезпечення (особливо тест-кейсів і тестових даних), широку автоматизацію регресійних тестів і стандартні набори тестів.
Реактивний	У цьому типі стратегії тестування реагує на компонент або систему, що тестується, і на події, що відбуваються під час виконання тесту. Тести розроблені та впроваджені та можуть бути негайно виконані у відповідь на знання, отримані за результатами попередніх тестів.

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

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

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

Критерії входу та виходу

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

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

Критерії виходу (також називаються визначенням виконаного в 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 Тетові квадранти