Методичка QA START UP

In God we trust, the rest we test…
Модуль I. ОСНОВНІ ПОНЯТТЯ В ТЕСТУВАННІ

ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Заняття 1.
ВВЕДЕННЯ В ОСНОВИ ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
1. ЩО ТАКЕ ТЕСТУВАННЯ 6
2. ТЕСТУВАННЯ І ЯКІСТЬ 7
3. ПРИЧИНИ ВИНИКНЕННЯ ДЕФЕКТІВ 8
4. ПРИНЦИПИ ТЕСТУВАННЯ 11
5. ВИДИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 12
6. КЛІЄНТ-СЕРВЕРНА АРХІТЕКТУРА 13
Питання до заняття 14
Заняття 2.
РОЗРОБКА ПЗ. ПРОЦЕС ТЕСТУВАННЯ, ЙОГО МЕТОДИ ТА РІВНІ
1. РОЗРОБКА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 15
2. ФУНДАМЕНТАЛЬНИЙ ПРОЦЕС ТЕСТУВАННЯ 17
3. МЕТОДОЛОГІЯ ТЕСТУВАННЯ 20
4. РІВНІ ТЕСТУВАННЯ 21
Заняття 3.
МЕТОДОЛОГІЇ РОЗРОБКИ ПЗ. ВИДИ ТЕСТУВАННЯ
1. МЕТОДОЛОГІЇ РОЗРОБКИ ПЗ 26
2. ВИДИ ТЕСТУВАННЯ 45
Модуль ІІ. ПЛАНУВАННЯ ПРОЦЕСУ ТЕСТУВАННЯ

Заняття 4.
GUI ЕЛЕМЕНТИ ТА ОГЛЯД ВИМОГ
1. ЕЛЕМЕНТИ ГРАФІЧНОГО ІНТЕРФЕЙСУ (GUI ЕЛЕМЕНТИ) 62
2. ВИДИ ВИМОГ ТА ЇХ ХАРАКТЕРИСТИКИ 68
Заняття 5.
ПЛАНУВАННЯ ПРОЦЕСУ ТЕСТУВАННЯ
1. ПЛАНУВАННЯ ПРОЦЕСУ ТЕСТУВАННЯ 78
2. ОГЛЯД СТРУКТУРИ ТЕСТ ПЛАНУ 79
3. ТЕСТОВЕ ПОКРИТТЯ (TEST COVERAGE) 85
 
 
 
 
 
 

Модуль ІІІ. АНАЛІЗ, РОЗРОБКА І ВИКОНАННЯ ТЕСТІВ

Заняття 6.
ОГЛЯД ЧЕК-ЛИСТА, ТЕСТ КЕЙСУ ТА РИСК ЛОГУ
1. ДЕТАЛЬНИЙ ОГЛЯД ЧЕК-ЛИСТА (CHECK LIST) 90
2. ДЕТАЛЬНИЙ ОГЛЯД ТЕСТ КЕЙСУ (TEST CASE) 91
3. ДЕТАЛЬНИЙ ОГЛЯД РИСК ЛОГУ (RISK LOG) 96
4. ПОЗИТИВНЕ ТА НЕГАТИВНЕ ТЕСТУВАННЯ 97
5. ТЕСТ НАБІР І ТЕСТОВИЙ СЦЕНАРІЙ 99
Заняття 7.
ТЕХНІКИ ТЕСТУВАННЯ
1. СТАТИЧНЕ ТА ДИНАМІЧНЕ ТЕСТУВАННЯ 100
2. СТАТИЧНІ ТЕХНІКИ ТЕСТУВАННЯ 102
3. ДИНАМІЧНІ ТЕХНІКИ ТЕСТУВАННЯ 107
Заняття 8.
ПОНЯТТЯ ДЕФЕКТУ
1. ЩО ТАКЕ ДЕФЕКТ? 123
2. ДЕТАЛЬНИЙ ОГЛЯД ЗВІТУ ПРО ДЕФЕКТ 124
3. ЖИТТЄВИЙ ЦИКЛ ДЕФЕКТУ 129
Модуль IV. ЗАВЕРШЕННЯ ПРОЦЕСУ ТЕСТУВАННЯ

ТА ЗВІТНІСТЬ
Заняття 11.
ФІНАЛЬНІ ДІЇ У ПРОЦЕСІ ТЕСТУВАННЯ
1. ЗАВЕРШЕННЯ ПРОЦЕСУ ТЕСТУВАННЯ 132
2. ДЕТАЛЬНИЙ ОГЛЯД ЗВІТНИХ ДОКУМЕНТІВ 133
Заняття 12.
КОНФІГУРАЦІЙНИЙ МЕНЕДЖМЕНТ, РИЗИКИ ТА МЕТРИКИ
ПРОЦЕСУ ТЕСТУВАННЯ
1. КОНФІГУРАЦІЙНИЙ МЕНЕДЖМЕНТ 134
2. МЕТРИКИ ТЕСТУВАННЯ 136
3. РИЗИКИ У ТЕСТУВАННІ 139
IT GLOSSARY 143
 
 
 
 
 

 
 
Модуль I.
ОСНОВНІ ПОНЯТТЯ В ТЕСТУВАННІ
ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Заняття 1.
ВВЕДЕННЯ В ОСНОВИ ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
1. ЩО ТАКЕ ТЕСТУВАННЯ
2. ТЕСТУВАННЯ І ЯКІСТЬ
3. ПРИЧИНИ ВИНИКНЕННЯ ДЕФЕКТІВ
4. ПРИНЦИПИ ТЕСТУВАННЯ
5. ВИДИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
6. КЛІЄНТ-СЕРВЕРНА АРХІТЕКТУРА
Питання до заняття
Незважаючи на те, що роль тестування на перший погляд може здатися не дуже

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

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

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

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

проблем під час функціонування. Це буде сприяти підвищенню якості системи
програмного забезпечення, якщо знайдені дефекти виправлені раніше, ніж система
введена в експлуатацію.
Mодуль1. ОСНОВНІ ПОНЯТТЯ В ТЕСТУВАННІ ПО

1. ВВЕДЕННЯ В ОСНОВИ ТЕСТУВАННЯ ПО
1. ЩО ТАКЕ ТЕСТУВАННЯ
«Тестування програм може бути використано для
демонстрації наявності помилок, але воно ніколи не покаже
їх відсутність.» — Дейкстра, 1970 р.
Тестуванням можна назвати процес, який містить у собі всі активності життєвого
циклу ПЗ, як динамічні, так і статичні, які стосуються планування, підготовки та
оцінки програмного продукту і пов’язаних з цим результатів робіт, з метою
визначити, що вони відповідають описаним вимогам, показати, що вони
підходять для заявлених цілей та для визначення дефектів.
Тестування ПЗ (testing) – це процес дослідження, випробування програмного

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

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

забезпечення на основі знайдених дефектів, як для функціональних, так і не
функціональних вимог ПЗ.
Активності в тестуванні існують як до, так і після виконання самих тестів.
До активностей тестування відносять наступне:
• планування та управління
• вибір елементів для тестування (test items)
• розробка тестових сценаріїв (test scenario/test case)
• виконання тестів (tests execution)
• перевірка результатів
• оцінка критеріїв виходу (exit criteria)
• створення звітів про процес тестування та про систему, яка була протестована
• закриття або кінцеві дії після того, як фаза тестування була виконана
(closure activities)
 
 


Тестування є складовою частиною процесу відладки програмного забезпечення

(ПЗ), після виявлення помилок, дефекти в програмному коді мають бути усунуті
розробниками.
Усі вищеперераховані поняття будуть розглянуті в наступних модулях.
2. ТЕСТУВАННЯ І ЯКІСТЬ
Тестуванням можна назвати процес, який містить у собі всі активності життєвого
циклу ПЗ, як динамічні, так і статичні, які стосуються планування, підготовки та
оцінки програмного продукту і пов’язаних з цим результатів робіт, з метою
визначити, що вони відповідають описаним вимогам, показати, що вони
підходять для заявлених цілей та для визначення дефектів.
Якість (quality) – ступінь, з якої компонент, система або процес відповідає

закріпленим вимогам і/або очікуванням і потребам користувача або замовника.
[IEEE 610]
Якісний продукт – це продукт, який успішно пройшов процеси верифікації та
валідації.
Верифікація – це процес підтвердження відповідності кінцевого продукту,
обумовлений еталонними вимогами(відповідає на питання: Чи правильно ми
робимо продукт?)
Валідація – це процес підтвердження відповідності кінцевого продукту
потребам користувача та можливість його застосування для визначених
задач (відповідає на питання: Чи правильний продукт ми робимо?)
Тестування оцінює якісний рівень продукту за трьома ключовими факторами:

1. Кількість непокритих функцій у системі
2. Кількість виконаних тестів
3. Кількість знайдених дефектів
Тестування може створити впевненість у якості програмного забезпечення за

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


Тест, який розроблений відповідним чином, успішно пройдений, зменшує загальний

рівень ризику в системі. Коли під час тестування виявляють помилки, якість систем
програмного забезпечення збільшується, якщо ці дефекти виправлені. Іншими
словами, основна мета тестування – забезпечення якості продукту, яка може
вимірюватися за трьома вищезазначеними факторами.
3. ПРИЧИНИ ВИНИКНЕННЯ ДЕФЕКТІВ

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

дуже гостро. Дефекти ПЗ можуть призвести до фінансових збитків, втрати іміджу
компанії та навіть людських жертв.
ДЕФЕКТ (DEFECT/FAULT/BUG) – вада компоненту або системи, яка може

спричинити невиконання необхідної функції компонентом або системою.
Наприклад, неправильне твердження або визначення даних. Дефект під час
виконання може призвести до несправності компоненту або системи.
ПОМИЛКА (ERROR/MISTAKE) – дія людини, яка призводить до неправильного

результату.
ЗБІЙ (FAILURE) – відхилення компоненту або системи від очікуваного виконання,

експлуатації або результату.
Складність Людський фактор: Обмежений час: Зміна

коду непорозуміння термінові зміни технологій
ПРИЧИНИ ВИНИКНЕННЯ ДЕФЕКТІВ (DEFECT, FAULT, BUG)
Низький рівень технологічного процесу:

• Погана практика кодування • дефекти допоміжних інструментів
• відсутність контролю версій • відсутність кваліфікаційного тестування
Рис. 1.1. Причини виникнення дефектів
8
 
 
 
 

 
 
 


ЛЮДСЬКИЙ ФАКТОР
Людині характерно помилятися. Як не дивно, ми все ж не знайшли альтернативу
тому, хто міг би створювати програмне забезпечення краще, ніж люди. Таким
чином, ми так само покладаємось на людський розум при розробці програмного
забезпечення і, в свою чергу, припускаємо ймовірність помилок у ньому.
НЕПОРОЗУМІННЯ
Відсутність або не результативна комунікація під час розробки програмного
забезпечення може відбутися на різноманітних рівнях (етап підготовки вимог,
етап інтерпретації/реалізації вимог і т.д.). Як результат, отримуємо розмиті або
неповні вимоги та ситуацію, у якій розробники не знають, яке рішення та
реалізація є необхідними відповідно до вимог, що призводить до помилок.
Можлива також ситуація, коли розробник намагається змінити код, який
створений іншим розробником, і відчуває складнощі з розумінням реалізації
коду.
ОБМЕЖЕНИЙ ЧАС
Частіше за все програмне забезпечення розробляється згідно графіків з
високим темпом випуску версій, з обмеженими ресурсами та з нереалістичними
термінами проєкту. Цілком ймовірно, що будуть досягнуті компроміси у вимогах,
дизайні, кодуванні та в загальному питанні якості для задоволення термінів
поставки. Інколи розробникам не дають достатньої кількості часу для
проєктування, розробки або тестування свого коду до його здачі. Пізні зміни в
дизайні можуть в останню хвилину вимагати змін у коді, які, ймовірніше за все,
спричинять помилки.
ТЕРМІНОВІ ЗМІНИ
Зміни, що вносяться до вимог, інфраструктури, інструментів, платформи, можуть
бути небезпечними. Дії з міграції баз даних, за сумісністю з різними
інформаційними системами або браузерами можуть бути дуже складними і, якщо
все виконано поспіхом у зв’язку зі зміною вимог в останній момент, можуть
призвести до помилок у додатку.
СКЛАДНІСТЬ КОДУ
Програмне забезпечення може бути складним і мати потребу у певному рівні
R&D1 та мозковому штурмі, аби досягнути розумного рішення. Нестача терпіння і
бажання завершити проєкт якомога швидше може спричинити помилки,
бажання/спокуса використати найпростіший спосіб реалізації рішення,
відсутність правильного розуміння технічної реалізації до розробки архітектури,
можуть призвести до помилок.
1Research
and Development – совокупность работ, направленных на получение новых знаний и практическое
применение при создании нового изделия или технологии
 
 
 
 

 
ЗМІНА ТЕХНОЛОГІЙ
Поява нового покоління технологій, підтримку яких диктує ринок, або ж від
початку неправильно обрані технології, які потребують переходу на інші.
НИЗЬКИЙ РІВЕНЬ ТЕХНОЛОГІЧНОГО ПРОЦЕСУ

Погана практика написання коду
Часом такі помилки як: неефективна обробка помилок/виключень, відсутність
належних перевірок (типів даних, діапазонів полів, граничних умов,
переповнення пам’яті і т.д.) виникають у коді через погану практику його
написання, що призводить до помилок у самому коді. Також розробники
можуть працювати з некоректним інструментарієм, несправними
компіляторами2, відладниками3, валідаторами4 і т.д.
Відсутність контролю версій

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

Досить часто під час розробки додатку ми потребуємо багато додаткових
інструментів, які в свою чергу є програмним забезпеченням і можуть містити
помилки. Наприклад, бібліотеки класів5, динамічні бібліотеки, компілятори,
редактори HTML, відладники і т.д. Помилка, яка виправлена, у таких
інструментах може в свою чергу призвести до помилки в програмному
забезпеченні, яке розробляється в даний час.
Відсутність кваліфікованого тестування

Відсутність якісної реалізації процесу тестування, ігнорування необхідних
базових підходів та практик при розробці тестів, аналізу та покриття коду
тестами, організації тестування (функціонального, регресивного та ін.)
2Компілятор (від англ. Compile – збирати разом, складати) – системна програма, що виконує перетворення
програми, яка написана однією алгоритмічною мовою, на програму мовою близькою до машинної, і в певному
розумінні еквівалентну першій.
3 Відлдник (деб ггер, англ. debugger) — комп’ютерна програма, призначена для пошуку помилок в інших
програмах, ядрах операційних систем, SQL-запитах та інших видах коду.
4 Валідатор формату (часто просто валідатор, калька з англ. validator) – комп’ютерна програма, яка перевіряє
відповідність будь-якого документу, потоку даних або фрагменту коду відповідному формату, перевіряє синтаксичну
коректність документа або файлу.
5 Бібліотеки
класів – це набір об’єктно-спрямованих типів та інтерфейсів, які представляють об’єктні моделі та
сервіси для вирішення більшості складних задач програмування, з якими може зіткнутися розробник.
10
 
а́
а́

 
 
 
 


ПРИЧИНИ ВИНИКНЕННЯ ЗБОЇВ (ВІДМОВ) (FAILURES)
Наявність Недотримання умов Порушення Порушення апаратної

дефекту виконання програми* цілісності додатку** частини***
* виконання додатку в непідтримуваному середовищі (платформі)

** порушення вірусами файлів додатку, злом додатку
*** умови навколишнього середовища: радіація, електромагнітні поля, забруднення,
пошкодження фізичних компонентів системи, які виконують код додатку
4. ПРИНЦИПИ ТЕСТУВАННЯ
Тестування може показати, що дефекти присутні, але не може
1. Тестування довести, що їх немає. Тестування знижує ймовірність наявності
демонструє наявність дефектів, які знаходяться у програмному забезпеченні, проте,
дефектів (Testing shows навіть якщо дефекти не були знайдені, це не доводить його
presence of defects) коректності.
Повне тестування з використанням усіх комбінацій вводів та

передумов є фізично неможливим, за винятком тривіальних
2. Вичерпне тестування
випадків. Замість вичерпного тестування повинні
недосяжно (Exhaustive використовуватися аналіз ризиків та розстановка пріоритетів,
testing is impossible) аби більш сфокусувати умови тестування. и не були знайдені,
це не доводить його коректності.
Щоб знайти дефекти якомога раніше, активності по тестуванню

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

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

разів, як результат, цей набір тестових сценаріїв більше не буде
5. Парадокс пестициду
знаходити нові дефекти. Щоб побороти цей «парадокс
(Pesticide paradox)
пестициду», тестові сценарії повинні регулярно рецензуватися та
коригуватися, нові тести повинні бути різносторонніми, аби
охопити всі компоненти програмного забезпечення або системи
і знайти якомога більше дефектів.
11
 
 
 
 


Тестування виконується по-різному, залежно від контексту.

6. Тестування залежить Наприклад, програмне забезпечення, для якого надзвичайно
від контексту (Testing is важлива безпека, тестується інакше, аніж сайт електронної
context dependent) комерції.
7. Омана через Виявлення та виправлення дефектів не допоможуть, якщо

відсутність помилок створена система не підходить користувачеві і не відповідає
(Absence - of - errors fallacy) його очікуванням та потребам.
5. ВИДИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

1. Десктопний додаток (Desktop application) – додаток, який працює автономно
на настільному комп’ютері чи ноутбуці.
2. Веб-додаток (Web application) – додаток, у якому всі або деякі частини

програмного забезпечення завантажуються з Інтернету кожного разу під час
запуску. Це може відноситись до браузерних додатків, які працюють через веб-
браузер користувача або клієнтських додатків, які нагадують локальні пристрої.
* Браузерний додаток (Browser-based application) – клієнт-серверний додаток,

у якому клієнтом виступає браузер, а сервером – веб-сервер. Логіка веб-
додатку розподілена між сервером та клієнтом, зберігання даних здійснюється
переважно на сервері, а обмін інформацією відбувається через мережу.
* Клієнтський додаток (Client-based application) – веб-додатки можуть

працювати і без браузера. Клієнтська програма, яка завантажує кожну серію
або те, що залишається на комп’ютері користувача і взаємодіє з сервером в
Інтернеті або іншим способом, з використанням стандартних веб-протоколів.
3. Мобільний додаток (Mobile application) – додаток являє собою комп’ютерну

програму, яка призначена для роботи на смартфонах, планшетних комп’ютерах
та інших мобільних пристроях.
4. Сервіси (Service-oriented application) – додатки, які забезпечують

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


6. КЛІЄНТ-СЕРВЕРНА АРХІТЕКТУРА
Клієнт-серверна архітектура (Client-server architecture) — мережева
архітектура, у якій навантаження мережі розподілене між постачальниками
послуг, що називають серверами, та замовниками послуг, що називають
клієнтами. Фізично клієнт та сервер – це програмне забезпечення. Зазвичай
вони взаємодіють через комп’ютерну мережу за допомогою мережевих
протоколів та знаходяться на різних вичислювальних машинах, проте можуть
також виконуватися і на одній машині. Додатки-сервери очікують від клієнтських
програм запити (request) і надсилають їм відповідь (response) з результатом
запиту.
Розглянемо приклад.
Ми сидимо за комп’ютером та хочемо зайти на сайт пошукової системи Google.
Що ж буде відбуватися з точки зору клієнт-серверної архітектури? Ми у себе за
комп’ютером – це клієнт, нам потрібен сервіс пошукової системи, ми заходимо
до браузера та вводимо в адресному рядку www.google.com. Далі йде запит на
віддалений сервер, який визначає, що нам потрібна сторінка пошукової
системи Google. Після цього сервер надсилає нам відповідь у вигляді сторінки
пошукової системи і ми бачимо її у нашому браузері.
Тонкий клієнт (Thin client) — комп’ютер або програма-клієнт у мережах з клієнт-

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

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

а серверну частину – Back End.
13

Розрізняють декілька видів клієнт-серверних архітектур:

1. Дворівнева клієнт-серверна архітектура складається з двох компонентів:
клієнта та сервера. Проте у сервері, як правило, розміщується також сховище
даних, де і зберігається вся інформація.
2. Трирівнева клієнт-серверна архітектура складається з трьох компонентів:
клієнта, сервера, де відбувається обробка інформації (ще його називають
сервер додатків (application server)) і сервера бази даних. У такій моделі з
сервера додатків знімається частина навантаження та переноситься на сервер
бази даних.
3. Багаторівнева клієнт-серверна архітектура складається з безлічі серверів
та баз даних, щоб коректно розподіляти навантаження по усій інфраструктурі
системи, і щоб користувачі не мали проблем із зависанням системи під час
роботи з нею.
Питання до заняття:
1. Що таке тестування?
2. Що таке якість?
3. Хто такий гарний тестувальник та які особисті якості він повинен мати?
4. Яка різниця між верифікацією та валідацією?
5. Що таке дефект?
6. Чи можна знайти всі дефекти у ПЗ? Аргументуйте свою відповідь.
7. Що таке збій?
8. Які існують принципи тестування та їх опис?
9. Яка різниця між дво- та трирівневою клієнт-серверною архітектурою?
10. Яка різниця між товстим і тонким клієнтом у контексті клієнт-серверної
архітектури?
Рекомендуємо до перегляду відео на нашому YouTube каналі
9 якостей гарного тестувальника

https://www.youtube.com/watch?v=tG-3wDsjE6Y Scan and watch
14


2. РОЗРОБКА ПЗ. ПРОЦЕС ТЕСТУВАННЯ. ЙОГО МЕТОДИ ТА РІВНІ
Заняття 2. РОЗРОБКА ПЗ. ПРОЦЕС ТЕСТУВАННЯ.

ЙОГО МЕТОДИ ТА РІВНІ
1. РОЗРОБКА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
2. ФУНДАМЕНТАЛЬНИЙ ПРОЦЕС ТЕСТУВАННЯ
3. МЕТОДОЛОГІЯ ТЕСТУВАННЯ
4. РІВНІ ТЕСТУВАННЯ
Якщо аналізувати фундаментальний процес тестування, то не можна сказати, що

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

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

рамками діяльність, яка має початок та кінець. У більшості випадків проєкт може
бути обмежений також фінансами або досягненням певних результатів.
Головна мета проєкту – це реалізація унікальних цілей та завдань.
Будь-який проєкт має стадію розробки.
1. РОЗРОБКА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Розробка програмного забезпечення (software development) — це рід діяль-

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

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

 
РОЗРОБКА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ (ТАКОЖ МАЄ НАЗВУ:

ЖИТТЄВИЙ ЦИКЛ РОЗРОБКИ ПЗ (SOFTWARE DEVELOPMENT LIFE CYCLE –
SDLC)) МОЖЕ БУТИ РОЗДІЛЕНА НА ДЕКІЛЬКА РОЗДІЛІВ:
1. Вимоги до програмного забезпечення: вилучення, аналіз, специфікація та

ратифікація6 вимог до програмного забезпечення.
2. Проєктування програмного забезпечення за допомогою засобів
автоматизованої розробки (наприклад, UML7)
3. Створення програмного забезпечення за допомогою мов програмування.
4. Тестування ПЗ: пошук та виправлення помилок у програмі.
5. Випуск програмного забезпечення.
6. Обслуговування ПЗ: програмні системи часто мають проблеми сумісності
та перенесення, а також потребують наступних модифікацій протягом
великого проміжку часу після того, як була завершена їх перша версія.
Також частиною розробки ПЗ є наступні процеси, які можуть бути

присутні протягом усього процесу розробки:
• Управління конфігурацією ПЗ: оскільки системи програмного

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

• Процес розробки ПЗ: процес побудови програмного забезпечення
активно обговорюється серед практиків, основними парадигмами
вважаються agile8 або waterfall.
• Якість ПЗ: методика оцінки критеріїв якості програмного продукту та

вимог до надійності.
6Ратифікація (лат. ratificatio від ratus — вирішений, затверджений + facere — робити) — процес надання юридичної
сили документу (наприклад, договору) шляхом затвердження його відповідним органом кожної зі сторін.
7 UML (англ. Unified Modeling Language — уніфікована мова моделювання) — мова графічного опису
для об’єктного моделювання в області розробки програмного забезпечення.
16


2. ФУНДАМЕНТАЛЬНИЙ ПРОЦЕС ТЕСТУВАННЯ

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

українській практиці ІТ, які зводяться до одного:
Тестування (Testing) – це процес виконання тестів, які описані в тестовій

документації та локалізації дефектів.
Контроль якості (QC – quality control) – це процес, спрямований на контроль
поточної якості продукту та порівняння її з запланованими характеристиками.
У цьому визначенні немає жодного слова про покращення якості продукту –
тільки контроль. Контроль можна розпочати тільки тоді, коли продукт вже
створений або раніше.
Гарантія якості (QA – quality assurance) – це процес, який вирішує більш
глобальні завдання, аналізуючи роботу тестувальника та спеціаліста з контролю
якості. У разі виникнення проблем, спеціаліст з контролю якості знаходить
шляхи вирішення проблем та не дає їй вплинути на якість продукту. Активність,
направлена на підвищення якості, враховуючи ефективність (найкраще
співвідношення використаних ресурсів до результату). Покращувати продукт
можна десятиріччями, проте ефекту буде мало.
Процес тестування – це техніка контролю якості, яка перевіряє відповідність
між реальною (фактичною) та очікуваною поведінкою системи. Тестування, як
процес своєчасного знаходження помилок та дефектів, не може повністю
гарантувати якість продукту, воно тільки порівнює вимоги до продукту з
реальною поведінкою.
QA процес може і повинен починатися якомога раніше, тоді ймовірність

виникнення прикрих помилок можливо буде виключити ще на ранніх стадіях
(на рівні архітектури).
Далі ми будемо розглядати тестування як сукупність трьох вище перерахованих
понять.
8Agile – серія підходів до розробки програмного забезпечення, яке орієнтоване на використання інтерактивної
розробки
17

 
 
 
 
 
Послідовність дій процесу тестування:

1. Планування та контроль
2. Тест аналіз та дизайн
3. Тест імплементація та виконання
4. Оцінка критеріїв виходу (exit criteria) та звітність
5. Закриття або завершуючі дії після того, як фаза тестування була виконана
(closure activities)
1. ПЛАНУВАННЯ ТА КОНТРОЛЬ (TEST PLANNING AND CONTROL)
Планування (planning) – це визначення того, що повинно бути протестовано та

того, як цього досягнути. Визначається, які саме задачі потрібно виконати, та хто
буде за це відповідати.
Основні цілі планування:
• Визначення областей та цілей тестування
• Визначення підходу тестування (об’єктів тестування, ризиків)
• Планування аналізу результату
• Планування часу виконання задач
• Визначення критерію завершення
Контроль (control) – це визначення того, що повинно бути зроблено, якщо

виконувані задачі не співпадають з планом. Контроль здійснюється протягом
усього тестування – порівнюється прогрес тестування з планом.
Цілі контролю:
• Аналіз результатів
• Порівняння поточного прогресу виконання тестів із запланованим раніше
• Виправлення помилок, якщо тестування пішло не за планом
2. АНАЛІЗ ТА ДИЗАЙН (TEST ANALYSIS AND DESIGN)
Це зв’язуюча стадія між плануванням тестів та їх виконанням.
На цій стадії відбувається детальне визначення того, що повинно бути

протестовано та вибір найменшого списку тестів, який задовольняє визначені
цілі. До уваги беруться частини, які визначені в Плануванні (planning) (дати, люди,
області тестування).
На цій стадії до початку самого тестування визначаються очікувані результати

(expected results).
18


Цілі аналізу та дизайну:

• Вивчення вимог до продукту, архітектури, інтерфейсу
• Аналіз компонентів, що тестуються, специфікацій
• Створення тестів
• Визначення ступені готовності вимог
3. ТЕСТ ІМПЛЕМЕНТАЦІЯ ТА ВИКОНАННЯ (TEST IMPLEMENTATION AND

EXECUTION)
Ця стадія передбачає розробку детальних тестів та їх виконання. Також

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

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

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

• Створення кейсів, підготовка даних, що є необхідними для тестування,
підготовка автоматичних інструментів
• Перевірка середовища тестування на готовність
• Виконання тестів (ручне або автоматичне тестування)
• Збереження результатів тестування (статусів, версій компонентів і т.д.)
• Порівняння отриманих та очікуваних результатів
4. ОЦІНКА КРИТЕРІЇВ ВИХОДУ ТА ЗВІТНІСТЬ (EVALUATING EXIT CRITERIA

AND REPORTING)
Критерії виходу визначаються на стадії планування, до виконання тестів.

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

 
 
 
 


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

• Визначення відповідності критеріям виходу
• Визначення необхідності прогону додаткових тестів
• Створення звітів про результати тестування
5. ЗАКРИТТЯ АБО ЗАВЕРШУЮЧІ ДІЇ ПІСЛЯ ТОГО, ЯК ФАЗА ТЕСТУВАННЯ

БУЛА ВИКОНАНА (CLOSURE ACTIVITIES)
Після того, як фаза тестування була виконана, здійснюються дії по завершенню

тестування, а саме – збір даних про виконані тести для об’єднання досвіду,
тестового забезпечення, фактів та цифр. Дії по завершенню тестування
відбуваються на тих етапах проєкту, коли система програмного забезпечення
випущена, тестування завершено (або перервано), етап був завершений або
супровід ПЗ був завершений.
Цілі завершуючих дій процесу тестування:

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

QA. У реальному проєкті, процес оцінки якості підлаштовується під методологію
розробки проєкту, а не навпаки.
3. МЕТОДОЛОГІЯ ТЕСТУВАННЯ
Тестування методом “чорної ящику” (Black Box testing) – метод тестування
функціональної поведінки об’єкта (програми, системи) з точки зору зовнішнього
світу, за якого не використовується знання про внутрішній пристрій або
структуру об’єкта, що тестується (простіше: немає доступу до програмного коду).
Воно націлено на перевірку очікуваної поведінки додатку або програми з точки
зору кінцевого користувача. Базується на даних входу та виходу.
20


Тестування методом “білого/прозорого ящику” (White Box testing) – метод

тестування, який базується на внутрішній структурі компонента або системи. У
такому разі існує доступ до програмного коду. Прикладом тестування “білої
ящику” є Unit тестування. Це безпосередньо тестування програмного коду юніт-
тестами. Юніт-тести пишуться розробниками для того, аби перевірити та
впевнитись в працездатності власного коду. *(дивись додаткове відео у нас на
YouTube каналі, посилання та код у питаннях до самоконтролю)
Тестування методом “сірого ящику” (Gray Box testing) – метод тестування, при
якому ми тестуємо методом “чорного ящику”, але тільки при цьому ми знаємо
внутрішню структуру і принцип роботи додатку. Знання про внутрішній устрій
програми дозволяють нам точніше підібрати вхідні значення та перевіряти
вихідні, тим самим покривати тестами найбільшу область можливих дефектів.
4. РІВНІ ТЕСТУВАННЯ
Тестування на різних рівнях відбувається протягом усього життєвого циклу
розробки та супроводу програмного забезпечення. Рівень тестування визначає
те, над чим здійснюються тести: над окремим модулем, групою моделей чи
системою в цілому.
Виконання тестування на усіх рівнях системи – це ключ до успішної реалізації та

здачі проєкту.
РІВНІ ТЕСТУВАННЯ
Компонентне Інтеграційне Системне Приймальне

тестування (component, тестування тестування тестування
unit, module, program (Integration testing) (System testing) (Acceptance testing)
1. КОМПОНЕНТНЕ ТЕСТУВАННЯ (component, unit, module, program testing) –

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

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


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

(функціональні одиниці ПЗ), так і нефункціональне тестування (продуктивність
системи, графічний інтерфейс).
Також може використовуватися у структурному10 тестуванні (тестування білого

ящику). Початковий код може бути протестований за допомогою середовища
розробки (unit framework or debugging tool), традиційно, виконується
розробником, який писав поданий код або іншими учасниками проєкту. Дефекти
на цьому рівні при структурному тестуванні виправляються тоді, як тільки вони
були знайдені, без будь-якого формального занесення їх до репортинг системи.
2. ІНТЕГРАЦІЙНЕ ТЕСТУВАННЯ (Integration testing) тестує інтерфейси

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

на тест-об’єктах різноманітного розміру:
• Тести компонентно-інтеграційного тестування – описують взаємодію між

компонентами ПЗ, а також виконуються після компонентного тестування;
• Тести системно-інтеграційного тестування – описують взаємодію між
різними системами та можуть бути виконані після системного тестування.
Чим більший об’єм інтеграції, тим важче ізолювати збої у певному інтерфейсі,
що може призвести до підвищеного ризику, а також до появи різноманітних
підходів інтеграційного тестування. Найбільш об’ємний вид інтеграції, коли усі
компоненти або системи інтегровані одночасно, після чого все тестується як
одне ціле. Це має назву «BigBang» (Великий Вибух) тобто інтеграційне тестування
або монолітне тестування. Відповідно немає необхідності симулювати роботу тих
частин, яких ще немає у розробці.
Головним недоліком є те, що у загальному це займає багато часу і складно

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

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

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

архітектури системи:
ЗВЕРХУ ВНИЗ (спадне тестування):Tестування передбачає, що процес

тестування рухається слідом за розробкою. Спочатку тестується найвищий
керуючий рівень системи, без модулів більш низького (наприклад,
починаючи з GUI або основного меню). Потім поступово з більш
високорівневими модулями інтегруються більш низькорівневі.
У результаті застосування такого методу, відпадає необхідність у
драйверах (роль драйвера виконує більш високорівневий модуль системи),
проте зберігається потреба в заглушках.
ЗНИЗУ ВГОРУ (висхідний підхід): під час використання цього методу

мається на увазі, що спочатку тестуються всі програмні модулі, які входять
у склад системи і тільки потім вони об’єднуються для інтеграційного
тестування.
За такого підходу область пошуку дефекту у тестувальника досить вузька,
тому набагато вища ймовірність правильно ідентифікувати дефект.
Недолік – потреба в драйверах та заглушках, які будуть симулювати
модулі, яких не вистачає.
ФУНКЦІОНАЛЬНО-ІНКРЕМЕНТАЛЬНА: інтеграція та тестування

відбуваються на основі функцій або функціональності, як описано в
функціональній специфікації.
На кожному етапі інтеграції, тестувальники повинні концентруватися
виключно на самій інтеграції. Наприклад, якщо інтегрується компонент А
з компонентом В, вони зацікавлені в тестуванні зв’язку між компонентами,
а не функціональності будь-якого з них. Можуть бути використані
функціональні та структурні підходи. Тестування конкретних
нефункціональних характеристик (наприклад, продуктивність) також
можуть бути включені в тестування інтеграції.
3. СИСТЕМНЕ ТЕСТУВАННЯ (System testing) – розглядає поведінку усієї

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

 
 

 
Системне тестування повинно досліджувати як функціональні, так і

нефункціональні вимоги до системи. Типові нефункціональні тести містять у собі
продуктивність та надійність. Тестувальники можуть також мати справу з неповними
або незадокументованими особливостями. Системне тестування функціональних
вимог починається з використання найбільш підходящих методів, які базуються на
специфікації (speci cation-based, black box testing). Також використовуються методи на
основі структурного тестування (Structure-based, white box testing).
Системне тестування потребує тестове середовище, яке контролюється, контроль

версій програмного забезпечення і тестових даних. Тестове середовище повинно
відповідати кінцевій меті або виробничому середовищу якомога більше, аби звести
до мінімуму ризик помилок навколишнього середовища, які не були знайдені під час
4. ПРИЙМАЛЬНЕ ТЕСТУВАННЯ (Acceptance testing) - коли компанія-розробник

виконала системне тестування і були виправлені всі або майже всі дефекти, система
буде доставлена користувачу або замовнику для приймального тестування.
Приймальне тестування повинно відповісти на наступні питання: «Система може бути
випущена?», «Чи є наявні значні (бізнес) ризики?» і «Компанія-розробник виконала
свої зобов’язання?»
Приймальне тестування найчастіше покладається на користувача або клієнта, хоча

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

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

наприклад:
• Приймальне тестування може застосовуватися над комерційним продуктом одразу
після його встановлення або інтеграції.
• Приймальне тестування продукту може відбуватися під час компонентного
• Приймальне тестування покращення нового функціоналу може відбуватися перед
системним тестуванням.
24
 

fi


Якщо система була розроблена для широкого ринку, то перевіряти її для

окремих користувачів або клієнтів не практично, у деяких випадках навіть
неможливо. Зворотній зв’язок є необхідним від потенційних або існуючих
користувачів у своєму секторі ринку, перш ніж програмний продукт буде
виставлений на продаж на комерційній основі.
Дуже часто такий тип системи проходить два етапи приймального тестування.
Перший називається альфа-тестування (Alpha testing). Таке тестування

відбувається з боку розробників. Потенційні користувачі та члени організації
розробника також можуть використовувати систему. Розробники спостерігають
за роботою користувачів та фіксують проблеми, які вони знаходять. Альфа-
тестування також може бути здійснене незалежною групою тестування.
Бета-тестування (Beta testing) – система надсилається користувачам, які

встановлюють її та використовують у робочих умовах реального світу.
Користувачі надсилають звіти про помилки, які відбуваються з системою, у
компанію розробника, де дефекти будуть розглянуті та виправлені.
1. Що таке проєкт?
2. Які розрізняють основні фази розробки ПЗ?
3. Яка різниця між тестувальником та QA?
4. Які розрізняють основні фази фундаментального процесу тестування?
5. Яка різниця між тестуванням методом чорної ящику та білого?
6. Що таке Unit Testing?
7. Які розрізняють види інтеграційного тестування?
8. Які можна перерахувати плюси та мінуси підходу інтеграції компонентів Big Bang?
9. Приймальне тестування може бути виконано тільки після системного
тестування, чи не так? Аргументуйте свою відповідь.
10. Чи може Acceptance Testing виконуватися тестувальниками?
Unit Testing Test Driven Development

ttps://www.youtube.com/ https://www.youtube.com/
watch?v=FuVFHr4US94 watch?v=UBrhDMhq994
24
Scan and watch Scan and watch
25


3. МЕТОДОЛОГІЇ РОЗРОБКИ ПЗ. ВИДИ ТЕСТУВАННЯ
Заняття 3. МЕТОДОЛОГІЇ РОЗРОБКИ ПЗ.

ВИДИ ТЕСТУВАННЯ
1. МЕТОДОЛОГІЇ РОЗРОБКИ ПЗ 29
2. ВИДИ ТЕСТУВАННЯ 50
1. МЕТОДОЛОГІЇ РОЗРОБКИ ПЗ
МЕТОДОЛОГІЇ РОЗРОБКИ ПЗ
Каскадні методології розробки Ітеративні методології розробки
Розробляти ПЗ можна за допомогою різних методологій. Як завжди, коли існує

можливість вибору, обов’язково виникає відповідальність за його результат.
Неправильно обрана методологія може призвести до перевитрати ресурсів, до
затримки термінів виконання проєкту і навіть до повного його провалу.
Як обрати правильну методологію? Чим вони відрізняються? Такими ключовими

принципами слід вважати насамперед відношення методології до ітеративної або
каскадної розробки та ступінь формальності в оформленні робочих матеріалів і
поведінки розробки як такої.
КАСКАДНІ МЕТОДОЛОГІЇ РОЗРОБКИ (WATERFALL MODEL)
Модель водоспаду (каскадна модель) – модель процесу розробки

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

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


На наступній стадії процесу відбувається інтеграція окремих компонентів, які

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

відладка продукту; на цьому етапі усуваються всі недоліки, які з’явились на
попередніх стадіях розробки. Після цього програмний продукт впроваджується та
забезпечується його підтримка – внесення нової функціональні і усунення помилок.
Тим самим, каскадна модель має на увазі, що перехід від однієї стадії розробки до
іншої відбувається тільки після повного та успішного завершення попередньої
фази, (перехід назад або вперед або перекриття фаз – не відбувається).
Затвердження вимог
Проєктування
Розробка
Тестування
Підтримка
Рис. 3.1. Каскадна модель життєвого циклу програмного забезпечення
🧐 Цікаво знати
Методику «Водоспаду» досить часто критикують за недостатню гнучкість та
оголошення самоціллю формальне управління проєктом на шкоду термінам,
вартості та якості. Тим не менш, під час управління великими проєктами
формалізація часто виступала дуже великою цінністю, оскільки могла
кардинально знизити багато ризиків проєкту і зробити його більш прозорим.
27
 


НА РІВЕНЬ ФОРМАЛІЗМУ РОЗРОБКИ ПЗ ВПЛИВАЄ:
Кількість документації Рівень її деталізації Наявність рецензування
V – MODEL
V-модель розвивалась у 1960-х, з того часу різні інститути та автори перероблювали,
покращували та екстраполювали її. Існує безліч версій V-моделі, кожна зі своєю
спеціалізованою термінологією, назвами та описами фаз. Хоча у галузі ІТ відбулися
великі зсуви з моменту її виникнення, визначені V-моделлю принципи так само
застосовуються сьогодні, як і у часи початкового створення моделі.
Проєктування
Вимоги Приймальне тестування
приймальних тестів
Системне Проектування Тестування

проєктування системних тесті системи
Проєктування Проєктування Інтеграційне

взаємозв’язків інтеграційних тестів тестування
Детальне Проєктування Модульне

проєктування модульних тестів тестування
Кодування
Рис. 3.2. Схема V-подібної моделі
28
 
 
 
 


ПРИНЦИПИ V-МОДЕЛІ:
«Від більшого до меншого» Цей принцип встановлює вимоги, стандарти,

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

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

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

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

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

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

 
 
 
ФАЗИ V-ПОДІБНОЇ МОДЕЛІ

Нижче запропоновано короткий опис кожної фази V-подібної моделі, починаючи від
планування проєкту та вимог, до приймального тестування:
Планування проєкту та вимог – визначаються системні вимоги, а також те, як

будуть розподілені ресурси організації з метою їх відповідності визначеним вимогам
(у випадку необхідності на цій фазі відбувається визначення функцій для апаратного
та програмного забезпечення);
Аналіз вимог до продукту та його специфікації – аналіз існуючої на даний момент

проблеми з ПЗ, завершується створенням повної специфікації;
Архітектура або проєктування на вищому рівні – визначає, яким чином функції ПЗ

повинні застосовуватися під час реалізації проєкту;
Деталізована розробка проєкту – визначає і документально обґрунтовує

алгоритми для кожного компоненту, який був визначений на фазі побудови
архітектури. Ці алгоритми згодом будуть перетворені в код;
Розробка програмного коду – виконується перетворення алгоритмів, визначених

на етапі деталізованого проєктування, у завершене ПЗ;
Модульне тестування – виконується перевірка кожного написаного модуля на

наявність помилок;
Інтеграція та тестування – встановлення взаємозв’язків між групами модулів, які

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

в цілому (повністю інтегрована система), після розміщення її в апаратному
середовищі відповідно до специфікації вимог до ПЗ;
Приймальне тестування – дозволяє користувачу протестувати функціональні

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

фазі передбачені також модернізація та внесення правок.
30


ПЕРЕВАГИ ТА НЕДОЛІКИ V-ПОДІБНОЇ МОДЕЛІ
ПЕРЕВАГИ НЕДОЛІКИ
• Особливе значення надається • За допомогою цієї моделі непросто

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

перед розробкою проєкту системи,
а проєктування ПЗ – перед
розробкою компонентів.
• Модель визначає продукти, які

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

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

ІТЕРАТИВНІ МЕТОДОЛОГІЇ РОЗРОБКИ
Ітеративний підхід (iteration, «повторення») у розробці програмного

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

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

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

• безперервне ітеративне тестування, яке дозволяє оцінити успішність усього
проєкту в цілому;
• раннє виявлення конфліктів між вимогами, моделями та реалізацією проєкту;

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

З більшості представників ітеративної розробки, найбільш поширеними є SCRUM і
KANBAN.
SCRUM
Скрам (Scrum) — методологія управління проєктами, що активно

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


Скрам — це набір принципів, на яких будується процес розробки, який дозволяє в

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

можна описати однією короткою статтею.
Рис 3.3. Життєвий цикл спринту
РОЛІ У МЕТОДОЛОГІЇ SCRUM
Scrum Master Product Owner Team
33


Скрам Мастер (Scrum Master) — найважливіша роль у методології.

Скрам Мастер відповідає за успіх Scrum у проєкті. По суті, Скрам Мастер
є інтерфейсом між менеджментом і командою.
Як правило, цю роль у проєкті відіграє менеджер проєкту або тімлід (team lead).
Важливо зазначити, що Скрам Мастер не розподіляє задачі між членами
команди. В Scrum команда є самоорганізованою та самокеруючою.
Головні обов’язки Скрам Майстра:

• Створює атмосферу довіри • Робить проблеми та відкриті
питання видимими
• Бере участь у мітингах у якості
фасилітатора11 • Відповідає за дотримання практик
та процесу в команді
• Усуває перепони
Скрам Мастер веде Daily Scrum Meeting та відслідковує прогрес команди за

допомогою Sprint Backlog, відмічає статус усіх завдань у спринті. Scrum Master
може також допомагати Product Owner створювати Backlog для команди.
Product Owner – це людина, яка відповідає за розробку продукту. Як правило,

це product manager для продуктової розробки, менеджер проєкту для
внутрішньої розробки та представник замовника для розробки на замовлення.
Product Owner – це єдина точка прийняття кінцевих рішень для команди у

проєкті, саме тому це завжди одна людина, а не група чи комітет.
Обов’язки Product Owner:

• Відповідає за формування product • Надає зрозумілі та протестовані
vision вимоги команді
• Управляє очікуваннями замовників • Взаємодіє з командою та
та усіх зацікавлених замовником
• Координує та пріоритизує Product • Відповідає за прийом коду в кінці
backlog кожної ітерації
Product Owner ставить завдання команді, але він не має права ставити завдання
конкретному члену проєктної команди протягом спринту.
Фасилітатор (англ. facilitator, від лат. facilis — «легкий, зручний») — це людина, яка забезпечує успішну групову
11
комунікацію.
34
 
 
 


Команда (Team)
У методології Scrum команда є самоорганізованою та самокеруючою. Команда
бере на себе обов’язки по виконанню об’єму роботи на спринт перед Product
Owner. Робота команди оцінюється як робота єдиної групи. У Scrum внесок
окремих членів проєктної команди не оцінюється, оскільки це руйнує
самоорганізацію команди.
Обов’язки команди:
• Відповідає за оцінку елементів • Відстежує особистий прогрес
беклогу (разом зі Скрам Мастером).
• Приймає рішення стосовно • Відповідає за результат перед
дизайну та імплементації Product Owner
• Розробляє софт та надає
його замовникові
Розмір команди обмежується розміром групи людей, які здатні ефективно

взаємодіяти один з одним. Типовий розмір команди: 3 – 9 осіб.
Команда в Scrum кросс функціональна. До неї входять люди з різноманітними

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

(collocated). Бажано розміщувати команду не в кубах, а в одній спільній кімнаті
для того, аби зменшити перепони для вільного спілкування. Команді необхідно
надати все необхідне для комфортної роботи, забезпечити дошками та
фліпчартами12, надати всі необхідні інструменти та середовище для роботи.
12Фліпч рт — магнітно-маркерна дошка з кріпленням для папірчика чи блоку паперу, які перегортаються як блокнот.
35
а́

 
 


АРТЕФАКТИ
Product Backlog – це пріоритезований список бізнес-вимог та технічних вимог,
які існують на даний момент.
Product Backlog складається з use cases, defects, enhancements, technologies,

stories, features, issues, і т.д. Product backlog також містить завдання важливі для
команди, наприклад, "провести тренінг".
Product Backlog постійно переглядається та доповнюється – до нього

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

Усі функції розбиті по завданням, кожна з яких оцінюється командою. Кожного
дня команда оцінює об’єм роботи, який потрібно пропрацювати для завершення
завдань. Сума оцінок роботи, що залишилась, може бути побудована як графік
залежності від часу. Такий графік називається Sprint Burn down chart. Він
демонструє прогрес команди протягом спринту.
СПРИНТ (SPRINT)
В Scrum ітерація має назву Sprint. Її тривалість складає до 1 місяця (30 днів).
Результатом спринту є готовий продукт (build), який можна передавати (deliver)

замовнику (принаймні, система повинна бути готова до демонстрації замовнику).
Короткі спринти забезпечують швидкий feedback проєктній команді від

замовника. Замовник отримує можливість гнучко керувати scope системи13,
оцінюючи результат спринту і пропонуючи покращення до вже створеної
функціональності. Такі покращення потрапляють в Product Backlog,
пріоритезуються на рівні з іншими вимогами та можуть бути заплановані на
наступний (або на один з наступних) спринтів.
Кожний спринт – це маленький "водоспад". Протягом спринту виконуються всі

роботи зі збору вимог, дизайну, кодуванню та тестуванню продукту.
Scope спринту повинен бути фіксованим. Це дозволяє команді давати

зобов’язання на такий обсяг роботи, який повинен бути виконаний у спринті.
Це означає, що Sprint Backlog не може бути змінений ніким, крім команди.
13 Scope системи – обсяг усього функціоналу системи.
36
 
 

 
 
 

 
ЖИТТЄВИЙ ЦИКЛ СПРИНТУ
Планування спринту
На початку кожного спринту відбувається його планування, де беруть участь
замовники, користувачі, менеджмент, Product Owner, Скрам Мастер і команда.
Планування спринту складається з двох послідовних мітингів.
Планування спринту, мітинг перший Планування спринту, мітинг другий
Учасники: Учасники:
Команда, Product Owner, Scrum Master, Скрам Мастер, команда.
користувачі, менеджмент.
Мета:
Мета: визначити, як саме буде розроблятися
Визначити мету спринту (Sprint Goal) певна функціональність для того, аби
та Sprint Backlog – функціональність, досягнути мети спринту.
яка буде розроблена протягом Для кожного елементу Sprint Backlog
наступного спринту для досягнення визначається список завдань та
мети спринту. оцінюється їх тривалість.
Артефакт: Артефакт:
Sprint Backlog у Sprint Backlog з’являються завдання.
Якщо у процесі спринту виявляється, що команда може не встигнути зробити

заплановане на спринт, то Скрам Мастер, Product Owner і команда зустрічаються та
з’ясовують, як можна скоротити scope робіт і при цьому досягнути мети спринту.
Переривання спринту (Sprint Abnormal Termination)
Переривання/зупинка спринту відбувається у виняткових ситуаціях. Спринт може

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

зупинки спринту. Після цього починається новий спринт: відбувається його
планування та стартують роботи.
37
 
 
 
 
 

 
 
 
 

 
 


Daily Scrum Meeting

Цей мітинг відбувається кожного ранку на початку дня. Він необхідний для того, аби
всі члени команди знали, хто та чим займається у проєкті. Тривалість такого мітингу
суворо обмежена і не повинна перебільшувати 15 хвилин. Мета мітингу – поділитися
інформацією. Він не призначений для вирішення проблем у проєкті. Усі питання, як
потребують спеціального обговорення, повинні бути винесені за межі мітингу.
Скрам мітинг проводить Скрам Мастер. Він по черзі ставить питання кожному члену
команди.
Що було зроблено вчора?
Що буде зроблено сьогодні?
З якими проблемами зіткнувся?
Скрам Мастер збирає всі відкриті для обговорення питання у вигляді Action Items,
наприклад, у форматі що/хто/коли.
Демо і рев’ю спринту

Команда демонструє інкремент14 продукту, створеного за останній спринт. Product
Owner, менеджмент, замовники, користувачі, у свою чергу, оцінюють його. Команда
розповідає про поставленні завдання, про те, як вони були вирішені, які перепони
траплялись на їхньому шляху, які рішення були прийняті, які проблеми залишились
невирішені. На базі такого огляду, сторона, яка приймає, може зробити висновки
про те, як далі повинна розвиватися система. Учасники мітингу роблять висновки
про те, як йшов процес у команді та пропонують рішення з його покращення.
Скрам Мастер відповідає за організацію та проведення даного мітингу. Команда

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

більше двох годин). Зокрема саме через це забороняється використовувати
презентації в Power Point. Підготовка до мітингу не повинна займати у команди
більше 2-х годин.
14 Інкремент – це збільшення на одиницю.
38
 
 


Ретроспектива Спринту
Ретроспектива Спринту дає Скрам Команді можливість інспектувати себе та
створити план покращень для наступного Спринту.
Ретроспектива Спринту відбувається після Огляду Спринту, перед наступним

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

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

потребу в потенційному покращенні;
• Розробка плану по залученню покращень в процес роботи СкрамКоманди.
Скрам Мастер заохочує Скрам Команду передивитися свої процеси розробки в

рамках фреймворку Скраму, аби зробити її більш ефективною та приємною у
наступному Спринті. Під час кожної Ретроспективи Спринту Скрам Команда шукає
шляхи покращення якості продукту, який розробляється, адаптуючи поняття
“Завершеності”.
До закінчення Ретроспективи Скрам Команда повинна визначитися з

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


KANBAN
Для початку розповімо про походження терміну Канбан. Цей термін прийшов до нас
з Японії завдяки широковідомій у вузьких колах виробничій системі Тойота. Основні
принципі, які закладені у ній — ощадливе виробництво (Lean manufacturing),
постійний розвиток, орієнтація на клієнта і т.д.
Термін Канбан має дослівний переклад: “Кан” означає видимий, візуальний, і “бан”
означає картка або дошка. На заводах Тойота картки Канбан використовуються
повсюдно для того, щоб не захаращувати склади та робочі місця заздалегідь
створеними запчастинами. Наприклад, уявіть, що ви встановлюєте двері на Тойоту
Короллу. У вас навколо робочого місця знаходиться пачка з 10 дверей. Ви
встановлюєте їх одну за одною на нові машини і, коли в пачці залишилось 5
дверцят, ви знаєте, що потрібно замовити нові двері. Ви берете картку Канбан,
пишете на ній замовлення на 10 дверей та відносите її тому, хто робить ці двері. Ви
знаєте, що він зробить їх якраз до того моменту, коли у вас закінчаться 5 дверей, які
залишились. Саме так і відбувається — коли ви встановлюєте останні двері,
прибуває пачка з 10 нових дверей. І так постійно — ви замовляєте нові двері тільки
тоді, коли вони вам потрібні.
А зараз уявіть, що така система діє на усьому заводі. Ніде немає складів, де
запчастини лежать тижнями та місяцями. Всі працюють тільки після запиту та
виготовляються саме стільки запчастин, скільки замовлено. Якщо раптом
замовлень стало більше чи менше – система сама легко підлаштовується під зміни.
Основне завдання карток Канбан у цій системі — це зменшувати кількість

«роботи, яка виконується в даний момент» (work in progress).
Наприклад, на всю виробничу лінію може бути виділено рівно 10 карток для дверей.
Це означає, що кожного разу на момент часу на лінії буде не більше 10 готових
дверей. Коли замовляти нові двері та скільки – це завдання для того, хто їх
встановлює. Тільки він знає свої потреби і тільки він може надсилати замовлення
виробнику дверей, але він завжди обмежений числом 10.
Цей метод Ощадливого виробництва (Lean manufacturing) був вигаданий у Тойоті і

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

забезпечення.
40


Що ж таке Канбан розробка відповідно до ПЗ, та чим вона відрізняється від

інших гнучких методологій, таких як SCRUM?
По-перше, потрібно одразу зрозуміти, що Канбан — це не конкретний процес, а
система цінностей. Як і SCRUM. Це означає, що ніхто не скаже вам, що і як
робити покроково.
По-друге, увесь Канбан можна описати однією простою фразою:
«Зменшення роботи, яка виконується в даний момент» (work in progress)».
По-третє, Канбан — це навіть більш «гнучка» методологія, ніж SCRUM. Це
означає, що вона не підходить усім командам та для усіх проєктів. Також це
означає, що команда повинна бути у ще більшій готовності до гнучкої роботи,
ніж команди, які використовують SCRUM.
Різниця між Канбан і SCRUM:
• В Канбан немає таймбоксів ні на що (ні на завдання, ні на спринти)

• В Канбан завдання більші і їх менше
• В Канбан оцінки термінів на завдання опціональні або їх взагалі немає
• В Канбан «швидкість роботи команди» відсутня і рахується тільки середній час
на повну реалізацію завдання
Тепер подивіться на цей список та замисліться — що залишається від гнучкої

методології, якщо ми видаляємо спринти, збільшуємо розміри завдань та
припиняємо вимірювання швидкості роботи команди? Нічого? Як взагалі можна
говорити про контроль розробки, якщо ми прибираємо основні інструменти
контролю – терміни, швидкість роботи та спринти? Менеджери завжди думають
про контроль та намагаються отримати його, хоча насправді ніколи його не
мають. Контроль розробки з боку менеджера – це фікція. Якщо команда не хоче
працювати, як її не контролюй, вона провалить проєкт.
Якщо команда отримує фан від роботи і працює з повною віддачею, то ніякий
контроль і не потрібен, а тільки заважає, збільшує витрати. Наприклад,
загальновідома проблема SCRUM — це великі витрати через обговорення,
зустрічі та великі втрати часу на стиках спринтів (коли як мінімум день йде на
закриття одного спринту, а потім день на відкриття нового. І якщо спринт –
2 тижні, то 2 дні з 2 тижнів – це 20%, страшенно багато). Як результат, ледь не
30-40% часу при застосуванні SCRUM витрачається на підтримку самого процесу
– на щоденні мітинги, на 5% workshop, на спринт ретроспектив і т.п. 30%!
41
 

 
 
Mодуль1. ОСНОВНІ ПОНЯТТЯ В ТЕСТУВАННІ ПЗ
Канбан розробка відрізняється від SCRUM в першу чергу орієнтацією на

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

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

виглядати так:
Рис 3.4. Kanban дошка
Стовпці зліва направо:
Цілі проєкту (Goals):

Необов’язковий, але корисний стовпчик. Сюди можна розмістити високорівневі
цілі проєкту, аби команда їх бачила та всі про них знали.
Наприклад, «Збільшити швидкість роботи на 20%» або «Додати підтримку Windows 10».
42
 


Черга завдань (Story Queue):

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

Цей та наступні стовпчики до «Завершено» можуть змінюватися, оскільки
команда вирішує, які кроки проходить завдання до стану «Завершено».
Наприклад, у цьому стовпці можуть бути завдання, для яких дизайн коду або
інтерфейсу ще не зрозумілі та обговорюються. Коли обговорення завершені,
завдання пересувається до наступного стовпця.
Розробка (Development):
Тут завдання висить до тих пір, поки розробка функцій не завершена. Після
завершення вона пересувається до наступного стовпця. І, якщо архитектура
хибна або не точна – завдання можна повернути до попереднього стовпця.
Тестування (Test):
У цьому стовпці завдання знаходиться, поки воно тестується. Якщо знайдені
дефекти – повертається до Розробки. Якщо ні – просувається далі.
Встановлення (Deployment):
Тут завдання висить до тих пір, поки розробка функцій не завершена. Після
завершення вона пересувається до наступного стовпця. І, якщо архитектура
хибна або не точна – завдання можна повернути до попереднього стовпця.
Завершено (Done):
Сюди стікер потрапляє тільки тоді, коли всі роботи по завданню завершені
повністю.
У будь-якій роботі трапляються термінові завдання. Заплановані чи ні, але такі,

які потрібно виконати прямо зараз. Для таких можна виокремити окреме місце
(на картинці відмічено як «Expedite»). У Expedite можна розмістити одне
термінове завдання і команда повинна почати її виконувати негайно та
завершити якомога швидше. Але може бути тільки одне таке завдання! Якщо
з’являється ще одне – воно повинно бути додане до «Черги завдань».
А тепер найважливіше. Бачите цифри під кожним стовпчиком? Це кількість

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

 
 
 
 
 
 

 
 


Наприклад, якщо ви маєте 8 програмістів у команді, то в рядок «Розробка» ви

можете помістити цифру 4. Це означає, що одночасно програмісти будуть
виконувати не більше 4-х завдань, а отже у них буде багато причин для
спілкування та обміну досвідом. Якщо ви поставите туди цифру 2, то 8
програмістів, які виконують 2 завдання, можуть занудьгувати або втрачати
занадто багато часу на обговореннях. Якщо поставити 8, то кожен буде
займатися своїм завданням і деякі завдання будуть затримуватися на дошці
надовго, але ж головне завдання Канбан – це зменшити час проходження
завдання від початку до стадії завершеності. Ніхто не дасть точну відповідь, які
повинні бути ліміти, але спробуйте для початку розділити розробників на 2 та
подивитися, як це працює у вашій команді. Потім ці числа можна підганяти під
вашу команду.
Під «розробниками» я розумію не тільки програмістів, але і інших спеціалістів.

Наприклад, для стовпця «Тестування» розробники – це тестувальники, оскільки
тестування – це їх обов’язок.
Увесь Канбан можна описати всього трьома правилами:
Розділіть роботу на завдання, кожне завдання напишіть на картці

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

виробництві.
Вимірюйте час циклу (середній час на виконання одного завдання)

і оптимізуйте постійно процес, аби зменшити цей час.
44
  
 


2. ВИДИ ТЕСТУВАННЯ
Розуміння видів тестування вводиться як засіб чіткого визначення мети певного
рівня тестування для ПЗ. Потрібно розглядати різні види тестування, тому що
тестування функціональності компонента або системи може бути недостатнім на
кожному рівні для досягнення загальних цілей тестування.
Вид тестування фокусується на конкретній меті тестування, наприклад,

тестування функціональності, яка виконується компонентом або системою, або
тестування нефункціональних характеристик якості, таких як надійність та
продуктивність. Залежно від об’єктивних цілей тестування, воно буде
організовано по-різному.
Розглянемо наступні види тестування:
1. ФУНКЦІОНАЛЬНЕ ТЕСТУВАННЯ (FUNCTIONAL TESTING)

Функція системи (або компонента) відповідає на питання «Що система робить?».
Функціональне тестування фокусується на визначенні того, чи робить ПЗ те, що

воно повинно робити.
Зазвичай це описано у функціональній специфікації, історіях користувача (user

story) або у варіантах використання (use cases). Також можуть бути присутні деякі
функції, які передбачаються бути імплементованими, але вони не
документуються. Такі незадокументовані та неявні вимоги також є частиною
вимог до системи, але їх важко протестувати. Функціональні тести засновані на
цих функціях, які описані в документах і є зрозумілими для тестувальників.
Вони можуть бути виконані на всіх рівнях тестування (наприклад, тестування
компонентів може бути закладено на специфікації компонентів).
Функціональне тестування розглядає певну поведінку системи і дуже часто

відноситься до методу “чорного ящику” (black box testing). Це частково правда,
адже тестування чорного ящику включає в себе нефункціональне тестування.
Тестування функціональності може відбуватися з двох позицій:

на основі вимог (requirements-based) або на основі бізнес-процесів (business
process-based).
45


Тестування на основі вимог використовує специфікацію функціональних вимог

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

Бізнес-процеси описують сценарії, які включають у себе щоденне використання
системи з точки зору бізнес користувачів.
Невід’ємною частиною функціонального тестування також є:
• Тестування точності (Accuracy testing)

• Тестування придатності (Suitability testing)
• Тестування безпеки (Security testing)
• Тестування взаємодії (Interoperability testing)
Тестування точності (Accuracy testing)

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

 
 
 
Як же нам перевірити точність, якщо ми не маємо специфікації або документа, у

якому не вистачає інформації? Це той випадок, коли знання доменної області
стають життєвоважливими для успіху проєкту. Якщо специфікація не диктує нам,
що програмне забезпечення повинно зробити, то ми повинні визначити
самостійно, як воно повинно працювати. Ми можемо зробити ці висновки на базі
нашого досвіду, наших знань про цю та аналогічні до цієї системи, наших знань
про успадковані системи, а також на базі інформації, яку ми збираємо, коли
опитуємо розробників, аналітиків, клієнтів та спеціалістів технічної підтримки,
або, якщо ніщо не допомагає, ми можемо зробити це на базі того, що, як ми
думаємо, «розумна людина буде очікувати» це робити.
Тестування придатності (Suitability testing)

Тестування придатності це тестування для перевірки того, що набір функцій
додатку відповідає наборові завдань кінцевого користувача. Оскільки це
тестування зорієнтоване на спроможність програмного забезпечення
працювати в тій якості, яка є необхідною для кінцевого користувача, варіанти
використання (use cases) і користувацькі сценарії (user scenarios) зазвичай
використовуються для управління тестуванням.
Коректність варіантів використання будуть сильно впливати на ефективність

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

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

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

Це може бути виконано через інтерфейс користувача тестувальниками без

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

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

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

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

для того, аби впевнитись, що адекватне планування та підготовка були виконані
перед процесом тестування.
Тестування взаємодії (Interoperability testing)

Тестування взаємодії проводиться для перевірки, чи буде програмне
забезпечення, яке тестується, функціонувати правильно в усіх визначених
цільових середовищах (environments).
15 Полісі – політики компанії/проєкту
48
 
 
 

 
 
 
Це включає в себе обладнання, програмне забезпечення, проміжне ПЗ,

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

якщо воно може бути легко інтегровано з іншими системами без необхідності
ключових змін – переважає тільки вимога, аби параметри конфігурації та
властивості файлів були змінені. Кількість та тип змін, що необхідні для роботи
у різних середовищах, визначає ступінь сумісності програмного
забезпечення.
2. НЕФУНКЦІОНАЛЬНЕ ТЕСТУВАННЯ (NON-FUNCTIONAL TESTING)

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

рівнях.
Нефункціональне тестування містить наступні види тестування:
• Тестування продуктивності (Performance testing)

• Юзабіліті тестування (Usability testing)
• Тестування підтримуваності (Maintainability testing)
• Тестування надійності (Reliability testing)
• Тестування портативності (Portability testing)
Це тестування поняття «Наскільки добре» працює система. Давайте детальніше

розглянемо вищеперераховані види нефункціонального тестування.
Тестування продуктивності (Performance testing)

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

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

цілей.
• З метою демонстрації того, що система задовольняє критерії

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

справжню мету. Перед початком тестування завжди потрібно поставити бізнес-
питання: «Яку мету ми хочемо досягнути, коли тестуємо продуктивність?».
Цілі можуть відрізнятися залежно від технологій, що використовуються

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

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

мета, що переслідується, для продуктивності буде заснована на
максимальній пропускній здатності або на кількості транзакцій за одиницю
часу.
Час відповіді сервера (server response time)

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


ОСНОВНІ ПОКАЗНИКИ (МЕТРИКИ) ПРОДУКТИВНОСТІ:

Одним з результатів, який отримуємо при тестуванні навантаження і потім
використовуємо у подальшому для аналізу, є показники продуктивності додатку.
Основні з них розібрані нижче:
1. Споживання ресурсів центрального процесора (CPU, %)

Метрика, яка демонструє, скільки часу з заданого визначеного інтервалу було
витрачено процесором на вирахування для обраного процесора. У сучасних
системах важливим фактором є здатність процесору працювати в декількох
потоках, аби процесор міг здійснювати обчислення паралельно. Аналіз історії
споживання ресурсів процесора може пояснювати вплив на загальну
продуктивність системи потоків даних, що обробляються, та операційної
системи, мультипоточності обчислень та інших факторів.
2. Споживання оперативної пам’яті (Memory usage, Mb)

Метрика, яка демонструє кількість пам’яті, яку використовує додаток.
Під час роботи додатку пам’ять заповнюється посиланнями на об’єкти, які, якщо
не використовуються, можуть бути очищені спеціальним автоматичним
процесом, який називають «збирачем сміття» (англ. Garbage Collector). Час, який
витрачається на очищення пам’яті таким способом, може бути значним, у
випадку, коли процес зайняв усю доступну пам’ять або коли процесу виділені
великі обсяги пам’яті, що потребують очищення. На час, який необхідний для
очищення пам’яті, доступ процесу до сторінок виділеної пам’яті може бути
заблокований, що може вплинути на кінцевий час обробки цих процесом даних.
3. Робота з дисковою підсистемою

Робота з дисковою підсистемою може значно впливати на продуктивність
системи, тому збір статистики про роботу з диском може допомагати виявляти
вузькі місця в цій області. Велика кількість зчитувань або записів може
призводити до простоювання процесора в очікуванні обробки даних з диску і, як
результат, збільшення споживання CPU і збільшення часу відгуку.
4. Час виконання запиту (request response time, ms)

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

 
 


НАПРЯМКИ У ТЕСТУВАННІ ПРОДУКТИВНОСТІ
Тестування навантаження Стрес тестування Тестування стабільності

(Load testing) (Stress testing) (Stability testing)
Тестування навантаження (Load testing) — це найпростіша форма тестування

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

• Користувачі, які працюють з системою.
• Інші системи, які взаємодіють з нашою системою.
Під тестуванням навантаження варто також розуміти той рівень напруги, за
якого система стабільно працює під час тестування.
Стрес тестування (Stress testing) – зазвичай застосовується для визначення

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

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


Юзабіліті тестування (Usability testing)

Юзабіліті тестування (Usability testing) вимірює придатність програмного
забезпечення для задоволення потреб його користувачів. Юзабіліті тестування
охоплює широкий спектр областей та призначений для вимірювання
ефективності (e ciency) та задоволення (satisfaction) тим, що буде визначено
користувачем під час використання програмного забезпечення. Розглянемо
кожний приклад більш детально:
Ефективність (e ectiveness) – тестування ефективності розглядає

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

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

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

поставляються за допомогою програмного забезпечення, юзабіліті тестування
вимірює такі атрибути як зрозумілість, освоюваність, працездатність та
привабливість. Коли здійснюється тестування на зрозумілість, ми дивимось на ті
частини програмного забезпечення, котрі допомагають користувачу розпізнати
та мати можливість застосувати логічну концепцію програмного забезпечення.
Освоюваність визначається кількістю зусиль, які необхідні користувачам. аби
вивчити додаток. Працездатність визначається на основі здатності користувача
ефективно та результативно виконувати свою місію. Привабливість це
суб’єктивна міра здатності програмного забезпечення подобатися
користувачеві.
53
ffi
ff


Частина планування процесу тестування демонструє те, що спеціалісти з

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

Підтримуваність. Це слово знають усі в сфері тестування, але інколи маємо
труднощі з поясненням. Це, як правило, розглядається як щось, що ми хотіли б
мати в нашому програмному забезпеченні, але складно пояснити, що таке
підтримуваність насправді. ISO 9126 модель якості є досить корисною тут, вона
визначає підтримуваність як «легкість, з якою програмний продукт може бути
змінений, або виправлені дефекти, змінений відповідно до нових вимог,
змінений для кращої підтримки та адаптації зі зміною середовища».
Відповідно до ISO 9126, ПІДТРИМУВАНІСТЬ може бути описана в термінах
Аналіз Змінюваність Стабільність Тестування
Аналіз відноситься до зусиль, які необхідні (як правило, самим розробникам)

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

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

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

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


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

процесу розробки ПЗ. Це стосується як початкової розробки програмного
забезпечення, так і будь-яких змін, які вносяться у процесі життєвого циклу.
Невід’ємними частинами цього процесу є дизайн та програмування методів,
використання та проведення спеціальних тестів, аби гарантувати
підтримуваність.
Тестування надійності (Reliability testing)

Надійність характеризує здатність програмного забезпечення виконувати свої
необхідні функції в заданих умовах за певний відрізок часу або під час
виконання певної кількості операцій (ISO 9126). Коли ми говоримо про надійність,
ми завжди думаємо про два фактори «що робити?» (затвердженні умови) та «як
довго?» (за часом або операцією).
Надійність зазвичай вимірюється такою метрикою як середній час між

відмовами (meantime between failures – MTBF). Програмне забезпечення, яке
має збій в середньому один раз на тиждень, вважається менш надійним, ніж
програмне забезпечення, яке має збій один раз на місяць. Коли ми робимо такі
заяви, ми не повинні забувати диференціювати збої між рівнями серйозності
(severities) та умов, за яких програмне забезпечення працювало.
Надійність програмного забезпечення може бути покращена шляхом практик

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

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

Здатність відновлюватися (recover ability) програмного забезпечення може бути

розглянута за наступними двома аспектами:
• Здатність відновлюватися під час відмов (Failover capability):

Здатність підтримувати безперервну роботу системи навіть у випадку
виходу з ладу. У такому випадку, повторне встановлення вказаного рівня
продуктивності може дійсно мати місце навіть без участі користувачі
програмного забезпечення (наприклад, кінцевих користувачів або інших
систем).
• Відновлення можливостей (Restore capability):

Здатність мінімізувати ефект збою на дані системи.
Тестування портативності (Portability testing)

Портативність це поняття того, наскільки легко програмне забезпечення може
бути передано в передбачуване середовище або від самого початку, або з вже
існуючого середовища.
Якісні характеристики портативності згруповані за стандартом ISO 9126
Адаптованість Інсталяційність Замінність Співіснування

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

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

 
 
 


Програмне забезпечення повинно бути гнучким, аби бути комерційно успішним.

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

спільне останнього, а також поняття адаптованості. Тестування взаємодії
перевіряє, чи є функції програмного забезпечення доступними, коли ПЗ працює
в різноманітних середовищах, а адаптованість в свою чергу оцінює, наскільки
легко можна реалізувати ПЗ в інші цільові середовища.
Інсталяційність (Installability)
Інсталяційність характеризує здатність програмного забезпечення бути готовим
до використання в його цільовому середовищі. Деякі програмні додатки
розроблені в стабільному середовищі, де є всі необхідні компоненти, такі як
операційна система, база даних та комунікаційне програмне забезпеченням,
можуть розглядатися як «належне». Часто це не наша відповідальність, аби
гарантувати, що ці стандартні компоненти встановлені, і ми часто можемо
вважати для нашої стратегії тестування, що всі вони готові, коли наше програмне
забезпечення встановлене.
Давайте розглянемо деякі фактори, які можуть впливати на інсталяційність ПЗ:
1. Люди, які встановлюють ПЗ, не є частиною команди розробки. Відповідно до

цього, інсталяція повинна бути зрозуміла і не створювати труднощів кінцевим
користувачам.
2. Інсталяція – комплексна процедура. Наявність різноманітних параметрів та
певна кількість кроків, які повинні бути виконані в певній послідовності, так
само повинні тестуватися заздалегідь.
3. Залежність ПЗ від апаратної частини – процес інсталяції повинен бути
коректним на випадок різноманітних середовищ встановлення, і на випадок
неправильного середовища повинен коректно реагувати на це.
4. Цільове середовище може відрізнятися від середовища розробки та
тестування – як процес інсталяції, так і взагалі процес використання ПЗ, може
відрізнятися від середовища розробників та реальних користувачів. Це
потрібно враховувати, з можливістю майбутнього застосування бета-
57
 


5. Процес видалення ПЗ повинен бути обов’язковим для інсталяційного пакету.

6. Процес переустановлення ПЗ повинен бути обов’язковим для інсталяційного
пакету.
7. Процес інсталяції повинен бути обмеженим у часі.
Замінність (Replaceability)
Замінність характеризує здатність систем функціонувати правильно з різними
альтернативними програмними компонентами. Сучасні програмні архітектури
часто містять у собі елементи, які розроблені, аби бути заміщеними в
майбутньому. Можливо, нові, покращені версії програмних компонентів будуть
доступні в майбутньому, або, можливо, комплексні системи, з якими взаємодіє
додаток, повинні бути змінені. Навіть, якщо заміна програмних компонентів не
планується на даний момент, зацікавлені сторони (особливо власники бізнесу та
оператори) можуть вимагати здатності бути гнучким, якщо виникають нові запити
протягом життєвого циклу додатку.
Співіснування (Co-existence)
Співіснування описує здатність додатку розділити середовище з іншими
додатками, не відчуваючи або не спричиняючи при цьому негативні ефекти.
Усі вищеперераховані атрибути якості формують та впливають на Портативність ПЗ.
3. ТЕСТУВАННЯ ПОВ’ЯЗАНЕ ЗІ ЗМІНАМИ

Кінцевою метою тестування є тестування змін. Ця категорія трохи відрізняється
від інших, тому що якщо ви внесли зміни до програмного забезпечення, ви
змінили спосіб його функціонування, те, як воно виконує завдання та його
структуру. Однак ми шукаємо тут конкретні типи тестування, які стосуються змін,
навіть якщо вони можуть містити в собі всі інші види тестів.
Тестування підтвердження (Con rmation testing or Re-testing)

Коли тест не проходить успішно, і ми вирішуємо, що причиною помилки є дефект
програмного забезпечення, то створюється звіт про дефект. Ми можемо
очікувати на нову версію програмного забезпечення, у якому дефект буде
виправлений. У такому випадку нам буде необхідно ще раз зробити тест, щоб
підтвердити, що дефект дійсно був виправлений. Це має назву тестування
підтвердження (con rmation testing)(також відоме як повторне тестування (re-
testing)).
58
fi
 
 
fi


Під час виконання тестування, важливо впевнитись у тому, що тест виконаний

точно так само, як це було перший раз, використовуючи ті самі вхідні дані та
середовище. Якщо тест пройшов успішно, це означає, що програмне
забезпечення в дійсний час виправлене. Принаймні тепер ми знаємо, що одна
частина програмного забезпечення працює правильно – де був дефект. Але
цього недостатньо. Виправлення могло створити або розкрити інший дефект в
іншому місці в програмному забезпеченні.
Спосіб, який може виявити ці неочікувані побічні ефекти (side e ects)

виправлень - це регресійне тестування (regression testing).
Регресійне тестування (Regression testing)

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

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

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

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

 
ff

 
Регресійне тестування
https://www.youtube.com/watch?v=1f3yfUnji8o Scan and watch
Санітарне тестування (Sanity testing)

Санітарне тестування – це вузькоспрямоване тестування, необхідне для
доведення факту того, що конкретна функція працює відповідно до зазначених у
специфікації вимог. Є підвидом регресійного тестування. Використовується для
визначення працездатності певної частини додатку після змін, які здійснені у
ньому або навколишньому середовищі. Зазвичай виконується вручну.
Димове тестування (Smoke testing)

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

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

впровадити автоматизацію тестових сценаріїв для димового тестування.
4. ТЕСТУВАННЯ ПІДТРИМУВАНОСТІ (MAINTENANCE TESTING)

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

 
 


Розробка та процес тестування, які застосовуються до нових розробок, не

застосовуються принципово для цілей підтримуваності. Ті ж самі кроки будуть
застосовуватися для процесу тестування. Залежно від розміру та ризику
внесених змін, вже будуть обговорені рівні тестування, які будуть застосовані.
1. Яка різниця між каскадними та ітеративними методологіями розробки ПЗ?

2. У чому полягає поняття формалізму при розробці ПЗ?
3. Що відбувається під час Daily Scrum Meeting?
4. Які розрізняють ролі в Scrum?
5. Що є більш пріоритетним: функціональне чи нефункціональне тестування?
6. Яка різниця між Regression Testing та Re-Testing?
7. Яка головна мета Ретроспективи в Scrum?
8. Що проводиться першим: Smoke Testing чи Regression Testing?
9. Які основні метрики вимірюються під час Performance Testing?
61

Модуль II.
ПЛАНУВАННЯ ПРОЦЕСУ ТЕСТУВАННЯ
Заняття 4.
GUI ЕЛЕМЕНТИ ТА ОГЛЯД ВИМОГ
1. ЕЛЕМЕНТИ ГРАФІЧНОГО ІНТЕРФЕЙСУ (GUI ЕЛЕМЕНТИ)
2. ВИДИ ВИМОГ ТА ЇХ ХАРАКТЕРИСТИКИ
1. ЕЛЕМЕНТИ ГРАФІЧНОГО ІНТЕРФЕЙСУ (GUI ЕЛЕМЕНТИ)
Графічний інтерфейс користувача (Graphical user interface, GUI) – різновид

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

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

наступні елементи управління:
Вказівник (Pointer) – вказівник або курсор миші являє собою

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

Mодуль ІІ. ПЛАНУВАННЯ ПРОЦЕСУ ТЕСТУВАННЯ

4. GUI ЕЛЕМЕНТИ ТА ОГЛЯД ВИМОГ
Кнопка (Button) – елемент інтерфейсу комп’ютерних програм, є

метафорою кнопки в техніці і, відповідно, зображується схожою
на неї та виконує аналогічні функції. При натисканні на неї
відбувається програмно пов'язана з цим натиском дія чи подія.
У широкому розумінні, кнопкою називають будь-який екранний
елемент, з окресленим кордоном, натискання на який призводить
до певної дії.
Флажок, чекбокс, галочка (Checkbox) – елемент графічного

інтерфейсу користувача, який дозволяє користувачеві керувати
параметром з двома станами – увімкнено та вимкнено. Під час
стану увімкнення всередині чекбоксу відображається відмітка
(галочка або рідше хрестик (×)).
Комбінований список, випадаюче меню (Combo box або

Dropdown list) – елемент графічного інтерфейсу користувача.
Поєднання випадаючого меню (розкривається при клацанні
мишки) та однорядкового текстового поля, яке дозволяє
користувачеві ввести значення вручну або обрати з переліку.
Елемент для вибору дати (Datepicker) – елемент

графічного інтерфейсу користувача для вибору дати або
діапазону дат.
Розширювач (Expander) – елемент графічного інтерфейсу

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

 
Елемент для відображення даних таблиці (Grid view або Data Grid) – виключно
гнучкий елемент управління таблицями, яки призначений для демонстрації даних
у вигляді двовимірної сітки (grid), або екранної таблиці, що складається з рядків та
стовпців.
Елемент для групування елементів (Group box) –

елемент графічного інтерфейсу користувача, який є
контейнером для інших об’єктів.
Напис або текст (Label) – елемент графічного інтерфейсу користувача, який

відображає текст на формі вікна.
Список (Listbox) – елемент графічного інтерфейсу

користувача, який відображає список, що
прокручується, з елементами. Дозволяє користувачеві
обрати один чи декілька елементів зі списку, як правило,
утримуючи клавішу Ctrl або Shift, аби зробити множинний
вибір. Усі елементи тримаються в списку статично, але
можуть бути додані динамічно також.
Елемент для введення паролю (Password box) –

елемент графічного інтерфейсу користувача, який
дозволяє користувачеві вводити текстову інформацію, у
свою чергу текст шифрується.
Перемикач (Radio button) – елемент інтерфейсу,

який дозволяє користувачеві обрати одну опцію (пункт) з
визначеного набору (групи)
64

 
 
Меню (Menu) – елемент графічного інтерфейсу користувача, який дозволяє обрати

одну чи декілька перерахованих опцій програми. У сучасних операційних системах
меню є найважливішим елементом графічного інтерфейсу користувача.
Розрізняють наступні типи меню:
Головне меню вікна (Main menu або menu bar)
Випадаюче меню (drop down menu)
Контекстне меню (pop up menu)
Смуги прокручування (Scroll bar) – це горизонтальні

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

користувача, який дозволяє встановлювати значення,
переміщуючи повзунок.
65


Індикатор процесу або Індикатор виконання (Progress bar) – елемент графічного

інтерфейсу користувача, який являє собою прямокутну панель для відображення
індексації ходу або виконання будь-яких завдань, наприклад, завантаження файлу
через мережу.
Інформаційний рядок (Status bar) – елемент графічного інтерфейсу користувача,

дуже часто розміщений у нижній частині вікна та розділений на секції, які містять
різну інформацію.
Панель інструментів (toolbar) – елемент графічного інтерфейсу користувача, який

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

Декілька вікон, які одночасно розміщені на екрані, можуть перекриватися, якщо
віртуально знаходяться «вище» або «нижче» відносно одне одного.
Вікно традиційно має прямокутну форму, зазвичай з обрамленням рамкою і/або
кольором фону, який відрізняється від кольору основного екрану. За
необхідності вікно має заголовок (з поясненням функції) та функції управління.
Діалогове вікно (Dialog Window) – спеціальний елемент інтерфейсу, вікно, яке
призначене для виводу інформації і (або) отримання відповіді від користувача.
Отримало свою назву, бо здійснює двосторонню взаємодію комп’ютер-
користувач (діалог), повідомляє щось користувачеві та очікує від нього відповідь.
Діалогові вікна підрозділяються на модальні та немодальні.
Модальне діалогове вікно – вікно, яке блокує роботу користувача з
материнським додатком до тих пір, доки користувач це вікно не закриє.
Немодальне діалогове вікно використовується у випадках, коли інформація,
яка виводиться на вікні, не є суттєвою для подальшої роботи системи.
Тому вікно може залишатися відкритим у той час, як робота користувача з
системою продовжується.
66


Вкладка (tab) – елемент графічного інтерфейсу користувача, який дозволяє в

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

активною та на області екрану, якою управляють, відображається відповідне
наповнення обраної вкладки. Вкладки розташовуються одна за одного
горизонтально, рідше – вертикально.
Поле з текстом (Text box) – елемент графічного інтерфейсу користувача, який

дозволяє користувачеві вводити текстову інформацію.
Підказка (Tooltip) – елемент графічного інтерфейсу, слугує додатковим засобом

навчання користувача.
Типи підказок:
Спливаюча підказка – з’являється при наведенні курсору до об’єкта, який цікавить
Підказка під час запуску – вікно, яке з’являється після запуску, та демонструє
короткий текст по незвичним або нестандартним можливостям програми
67


2. ВИДИ ВИМОГ ТА ЇХ ХАРАКТЕРИСТИКИ

На сьогодні існує безліч визначень вимог до програмного забезпечення (software
requirements).
Вимоги16 – умови або можливості, які необхідні для вирішення проблем або
досягнення мети.
Вимоги – умови або можливості, якими повинна володіти система або системні
компоненти, аби виконати контракт або задовольняти стандарти, специфікації
або інші формальні документи.
Термін вимоги (до програмної системи) може пояснюватися по-різному. У деяких

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

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

функціональні вимоги. На додаток кожна система має свої нефункціональні вимоги.
Модель на рисунку нижче ілюструє спосіб подання цих типів вимог.
РІВЕНЬ 1
• Vision and Scope Document

Бізнес вимоги • Market Requirements Document (MRD)
• Business Requirements Document (BRD)
РІВЕНЬ 2
• User Story (only for SCRUM)

Вимоги користувачів
• Use Cases (can be used in RUP)
РІВЕНЬ 3
Функціональні вимоги • Software Requirements Specification (SRS)
Системні Нефункціональні • Business Rules • External Interfaces

вимоги вимоги • Quality Attribute • Constraints
16 Визначення за стандартом: IEEE Std. 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology
68

 
БІЗНЕС-ВИМОГИ (BUSINESS REQUIREMENTS)

Бізнес-вимоги містять високорівневі цілі організації або замовників системи.
Як правило, їх висловлюють ті, хто фінансує проєкт, покупці системи, менеджер
реальних користувачів, відділ маркетингу. Ці вимоги пояснюють, чому організації
потрібна така система, тобто є опис цілей, які організація прагне досягнути з її
допомогою. Традиційно бізнес-вимоги описуються у формі документа про бачення
та межі проєкту (Vision and scope document), який ще інколи називають уставом
проєкту (project charter), документом вимог ринку (market requirements document)
або business-requirement document (BRD).
ВИМОГИ КОРИСТУВАЧІВ (USER REQUIREMENTS)

Вимоги користувачів повинні описувати функціональні та нефункціональні
системні вимоги таким чином, аби вони були зрозумілі навіть користувачеві,
який не має спеціальних технічних знань. Ці вимоги пояснюють, що користувач
може зробити з системою. Вимоги користувачі повинні бути написані
зрозумілою мовою, з використанням простих таблиць, а також показових та
зрозумілих діаграм.
До звичайних способів представлення цього виду вимог відносять варіанти
використання (use case), історії користувачів (user story). Таким чином, у цьому
документі вказано, що клієнти зможуть робити з допомогою системи.
ФУНКЦІОНАЛЬНІ ВИМОГИ (FUNCTIONAL REQUIREMENTS)

Функціональні вимоги визначають функціональність ПЗ, яку розробники повинні
побудувати, щоб користувачі могли виконати свої завдання в межах бізнес-
вимог. Ці вимоги пояснюють, що буде розроблено розробником. Функціональні
вимоги документуються в специфікації вимог до ПЗ (software requirements
speci cation, SRS), де якнайповніше описується, яка очікується поведінка
системи.
СИСТЕМНІ ВИМОГИ (SYSTEM REQUIREMENTS)

Системні вимоги – це високорівневі вимоги до продукту, які містять опис підсистем,
з яких складається система, що розробляється. Говорячи про систему, ми маємо на
увазі програмне забезпечення або підсистеми ПЗ та обладнання. Люди – частина
системи, тому певні функції системи можуть поширюватися і на людей.
НЕФУНКЦІОНАЛЬНІ ВИМОГИ (NON – FUNCTIONAL REQUIREMENTS)

Нефункціональні вимоги відносяться до системи в цілому, а не до окремих її частин.
Це означає, що вони більш значні та критичні, ніж окремі функціональні вимоги.
Помилка, яку допущено в функціональних вимогах, може знизити якість системи,
помилка в нефункціональних вимогах може зробити систему непрацездатною.
69
fi
 
 
Усі нефункціональні вимоги можна розділити на 4 великі групи:
Бізнес-правила (business rules)

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

Атрибути якості описують експлуатаційні властивості програмного продукту.
Сюди відносяться вимоги до продуктивності системи, об’єму необхідної пам’яті,
надійності (визначає частоту можливих збоїв у системі), переносимість системи
на різні комп’ютерні платформи, зручності експлуатації, обмеження дизайну
реалізації.
Розрізняють наступні атрибути якості:
• Функціональність (functionality) – наскільки ПЗ здатне вирішувати

завдання, які відповідають зафіксованим та передбаченим потребам
користувача, за визначених вимог використання ПЗ.
• Придатність (availability) – чи доступний продукт, коли та де його потрібно

використовувати.
• Можливість встановлення (installability) – наскільки легко та коректно

встановити продукт.
• Цілісність (integrity) – чи захищений продукт від несанкціонованого

доступу та втрати даних.
• Сумісність (interoperability) – наскільки легко продукт взаємодіє з іншими

системами.
• Продуктивність (performance) – наскільки швидко продукт виконує операції.
• Надійність (reliability) – наскільки довго продукт може працювати без

збоїв.
70
 
 

 
 


• Відновлюваність (recoverability) – наскільки швидко продукт може

відноситися після збою.
• Міцність (robustness) – наскільки добре продукт готовий до неочікуваних

робочих умов.
• Безпека (safety) – наскільки добре продукт захищений від уражень.
• Зручність використання (usability) – наскільки прийнятне ПЗ для

розуміння, вивчення, використання та привабливості для користувача.
• Ефективність (e ciency) – наскільки ПЗ здатне забезпечувати необхідний

рівень продуктивності відповідно до виділених ресурсів, часу та інших
визначених умов.
• Підтримуваність (maintainability) – легкість, з якою ПЗ може аналізуватися,

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

перенесення з одного оточення (software/hardware) в інше.
Зовнішні взаємодії (external interfaces)

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

ffi

 
 


Характеристики якості гарних вимог:
• Коректність (Correctness)
• Недвозначність (Unambiguousness)
• Повнота (Completeness)
• Несуперечливість (Consistency)
• Верифікованість (Verifiability)
• Трасування (Traceability)
• Модифікованість (Modifiability)
• Пріоретизованість (Ranked for importance)
Розглянемо вищеперелічені характеристики детальніше:
Коректність
Кожна вимога повинна точно описувати функціональність. Чи можна поставити
питання, наскільки коректною є наша вимога? Чи дійсно це те, що вимагається
від системи чи хтось припустився помилки/друкарської помилки у процесі
написання вимоги?
Приклад: після набору номеру телефону, користувач повинен чути короткі гудки
(які символізують, що триває дзвінок
Опис: у даному випадку просто сплутали слово. Гудки повинні бути довгими. Це
ніяк не суперечить вимозі (яка також існує) про те, що під час ситуації «зайнято»
також повинні бути короткі гудки. Також це не суперечить трасування на верхні
вимоги, де може бути вказано, що для різних ситуацій повинні бути різні гудки.
Решта критеріїв також не порушені. Це просто неправильність опису вимоги.
• потрібні гарні знання доменної області (у даному випадку це знання в

області телефонії та зв’язку);
• потрібно дивитись на трасування вгору та вниз (на бізнес-вимоги та на

низькорівневі вимоги – дизайн, макети, детальний опис реалізації), можливо
буде виявлена певна розбіжність даних;
• процес рев’ю (огляду) також може допомогти, бажано, аби це рев’ю

проводив тест-аналітик або той, хто також має відношення до написання
вимог.
72
 


Недвозначність
Усі читачі вимог повинні інтерпретувати їх однаково, але звичайна мова часто
буває багатозначною. Заповнюйте документацію просто, коротко та точно,
застосовуючи лексику, яка зрозуміла користувачам. «Зрозумілість» - мета якості
вимог, як пов’язана з точністю: читачі повинні чітко розуміти кожне положення.
Можна поставити питання, чи можуть 2 різні людини зрозуміти вимогу по-
різному?
Приклад: Телефон повинен працювати в автономному режимі, коли він

заряджається від батарейок В автономному режимі недоступні наступні функції:
функція 1; функція 2
Опис: чи повинні бути доступні функція 1; функція 2, якщо телефон з

батарейками, але під’єднаний до мережі? Тестувальник може подумати, що так,
програміст – ні. Замовник також може це інтерпретувати як захоче. Вимогу
можна зрозуміти двозначно. Частково це може межувати з критерієм «повнота»,
але в даному випадку це може бути повноцінною вимогою, оскільки ситуація
«робота від мережі» також, наприклад, прописана в іншій вимозі. Тому повнота є,
але немає однозначності для деяких ситуацій.
Як тестувати на недвозначність та знаходити такі помилки:

• Перевіряти «розгалуженість» вимог: якщо є умови або виключення –
перевіряти, аби всі вони були описані та не було «неописаних дірок», які
якраз можуть розумітися по-різному, тому що явно не прописані.
• Рев’ю, аналогічно до попереднього пункту.
Повнота
Кожна вимога повинна повністю описувати функціональність, яку буде
реалізовано в продукті. Тобто вона повинна містити всю інформацію, яка
необхідна для розробників, аби тим вдалося створити цей фрагмент
функціональності. Якщо ви розумієте, що даних певного роду не вистачає,
використовуйте примітку «TBD» (to be determined — необхідно визначити) на
полях як стандартний прапорець для виділення такого місця. Заповніть усі
пробіли в кожному фрагменті вимог, перш ніж починати конструювання цієї
функції. Можна поставити питання, наскільки повним є набір вимог? Якщо є
секція у специфікації, яка визначає функціональність модулю, то чи вся
функціональність цього модулю покрита вимогами?
73
 
 


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

(«*», «#» и т.п.), і в цих вимогах пропущена одна зі спец-кнопок. Для цієї кнопки
просто немає вимог.
Як тестувати на повноту та знаходити такі помилки:

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

• Звертати увагу на загальні формулювання вимог (наприклад – телефон у
режимі Mute не повинен видавати звук за жодних обставин. А обставин
може бути багато, чіткого переліку немає і бути не може). При виявленні
таких вимог потрібно або намагатися їх переформулювати, або виносити
подібні вимоги до «особливо небезпечного списку» і потім аналізувати всі
інші вимоги щодо протиріччя з ними.
• Розподіляти на категорії та рев’ювити їх спрямовано на предмет протиріч.

• Виділяти всі вимоги, які трасуються на одну високорівневу вимогу та
аналізувати такі набори (зазвичай суперечливість відноситься до однієї
74
 
 


вимоги верхнього рівня, в межах якого й існує декілька більш

низькорівневих вимог з різних розділів, які суперечать одна
одній).функціональність цього модулю покрита вимогами?
Верифікованість
Для тестувальників це – один з основних та найважливіших критеріїв.
Чи можливо перевірити цю вимогу та упевнитись, що її дотримано?
Приклад:
У випадку виникнення критичної помилки, телефон повинен перезавантажитись.
Інформація на дисплеї телефону повинна відображатися у зрозумілому для

користувача вигляді.
Опис: Що таке критична помилка – можна визначити та прописати. Але

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

такого тест-кейсу? Ми не зможемо прописати очікуваний результат для цього
випадку, відповідно й перевірити вимогу.
Як тестувати на верифікованість та знаходити такі помилки:
• Під час аналізу вимог поставити питання: «Як я буду це перевіряти?». Якщо
однозначної відповіді немає – необхідно більш детально аналізувати і,
можливо, вносити зміни у вимоги (уточнення, обмеження).
• Під час аналізу вимог визначати загальні формулювання, які потребують

підбору невизначеного числа варіантів для перевірки виконання вимоги.
Трасування
Будь-яка вимога проходить шлях від бізнес-ідеї до деталей реалізації. Це можуть
бути три рівні вимог (business requirements, user requirements, functional
requirements). Трасування — це зв’язок вимоги вище з вимогою нижче.
Наприклад, є бізнес-вимога щодо того, що повинна бути можливість вимикати
звук. Вона може розпадатися на рівні functional requirements на багато вимог,
75
 
 
 
 


які описують функціональність режиму Mute.

Зв’язок між усіма цими вимогами – і є трасування.
Розрізняють два види трасування:

• Зворотнє трасування (Backward traceability) – вимоги посилаються на
джерела в ранніх документах.
• Трасування вперед (Forward traceability) – кожна вимога повинна мати
унікальне ім’я та номер.
На практиці часто трапляється, що якась з вимог втрачає трасування:
Приклад:
Бізнес-вимога не має жодної функціональної вимоги. Відповідно маємо пробіл в
реалізації (ми не зробимо того, що потрібно бізнесу).
Функціональна вимога описує те, чого не було в бізнес-вимогах. Виходить, ми

робимо те, що не потрібно.
Обидва ці сценарії – показник того, що трасування некоректне і на це ніхто не

звернув увагу.
Як тестувати на верифікованість та знаходити такі помилки:

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

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

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

замислюватися про вимоги та аналізувати, чи правильно вони пов’язані між
собою (можливо, цього зв’язку взагалі не повинно бути, а може повинен бути
зв’язок з іншою вимогою).
76
 


Модифікованість
Необхідно забезпечити можливість зміни вимог, якщо виникає така потреба, та
підтримувати історію змін кожного додатку. Для цього всі вони повинні бути
унікально помічені та позначені, аби ви могли посилатися на них неодноразово.
Кожна вимога повинна бути записана до специфікації тільки один раз. Інакше ви
легко отримаєте розбіжності, якщо зміните тільки одне положення з двох
однакових.
Пріоритезованість
Необхідно забезпечити можливість зміни вимог, якщо виникає така потреба, та
Виставте пріоритети кожній функціональній вимозі, характеристиці або варіанту
використання (use case), аби визначте, що необхідно кожній версії продукту.
Якщо всі положення однаково важливі, менеджеру проєкту буде важко
впоратись зі зменшенням бюджету, порушенням термінів, втратою персоналу
або додаванням нових вимог у процесі розробки.
Вимоги можна розділити за наступними пріоритетами:

• Обов’язкове (Essential) – має на увазі, що ПЗ не буде прийнятним, якщо ці
вимоги не реалізовані належним чином.
• Умовне (Conditional) – має на увазі, що ці вимоги можуть покращити ПЗ, але

якщо вони не реалізовані, то ПЗ буде вважатися прийнятним.
• Необов’язкове (Optional) – має на увазі, що вимоги можуть бути не

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

2. Що таке вимоги?
3. Які розрізняють види вимог?
4. Перерахуйте назви документів, у яких описуються різноманітні види вимог.
5. Які характеристики повинні мати гарні вимоги?
6. Web сторінка повинна завантажуватися швидко. Яка характеристика гарних
вимог порушена?
77

 
 


5. ПЛАНУВАННЯ ПРОЦЕСУ ТЕСТУВАННЯ
Заняття 5. ПЛАНУВАННЯ ПРОЦЕСУ ТЕСТУВАННЯ

2. ОГЛЯД СТРУКТУРИ ТЕСТ ПЛАНУ
3. ТЕСТОВЕ ПОКРИТТЯ (TEST COVERAGE)

Планування – оптимальне розподілення ресурсів для досягнення поставлених
цілей; сукупність процесів, які пов’язані з визначенням цілей та дій у майбутньому.
Безпосередньо на планування процесу тестування впливають тестова політика

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

життєвого циклу. Зворотній зв’язок від результатів тестової діяльності
використовується для визначення змін ризиків таким чином, щоб планування
можна було коригувати.
ДІЇ ПО ПЛАНУВАННЮ ТЕСТУВАННЯ

Дії по плануванню тестування усієї системи або її частини можуть містити:
• Визначення об’єму, ризиків та цілей тестування;
• Визначення загального підходу до тестування, у тому числі рівні тестування та
критерії входу/виходу;
• Інтегрування та координація дій тестування з життєвим циклом ПЗ;
• Прийняття рішень про те, що тестувати, які ролі необхідні для виконання
тестування, коли та як проводити тестування та як оцінювати результати;
• Складання розкладу аналізу та проєктування тестів;
• Складання графіку підготовки, виконання та оцінки тестів;
• Визначення розміру, рівня деталізації, структури та шаблонів для тестової
документації;
• Вибір метрик17 для моніторингу та контролю підготовки та проведення
тестування, виправлення дефектів, проблем та ризиків.
Процес планування тестування може бути задокументований в документі, який має
назву Тест план (Test Plan).
Метрика – числове значення, яке може вказувати на прогрес процесу тестування, наприклад, кількість дефектів
17
або пройдених тестів за одиницю часу

78


2. ОГЛЯД СТРУКТУРИ ТЕСТ-ПЛАНУ

Тест План – це документ, який описує увесь об’єм робіт тестування, починаючи з
опису об’єкта, стратегії, графіку, критеріїв початку та завершення тестування,
обладнання та інструментальних засобів, які використовуються, спеціальних знань,
а також оцінка ризиків з варіантами їх вирішення.
ЦІЛІ СТВОРЕННЯ ТЕСТ-ПЛАНУ

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

яке тестується, з іншими учасниками проєктної команди;
• пріоритезація завдань тестування;

• вчасне планування витрат ресурсів на тестування;
• облік ресурсів (ПЗ, обладнання), які необхідні для тестування;
• завчасне врахування ризиків, які можуть виникнути в процесі реалізації плану,
та залучення попереджувальної стратегії.
Розрізняють наступні рівні деталізації тест-планів:
1. Загальний тест-план (Master Plan або Master Test Plan)

2. Тест-план (Test Plan або Detailed Test Plan)
Залежно від особливостей проєкту та методології роботи, інколи вистачає

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

зведену інформацію з Загального тест-плану та Детального тест-плану.
79
 
 
 

 
Таблиця 5.1 Особливості Загального тест-плану і Тест-плану
Загальний тест-план Тест-план

(Master Test Plan) (Detailed Test Plan)
Створюється у випадку: Детальний тест-план складається на

кожний реліз/ітерацію або для кожної
• якщо продукт має безліч релізів або
команди в межах проєкту. Його основна
ітерацій, між якими зберігається спільна
мета – коротко описати завдання
інформація, яку немає сенсу повторювати;
• якщо різноманітні тестові команди
працюють над одним продуктом,
виконуючи різні завдання, які необхідно
об’єднати в межах одного документа.
Міститься інформація:
Міститься інформація:
• загальна інформація про продукт, • перелік областей тестування з
посилання на документацію, баг-трекер
пріоритетами;
та інші проєктні ресурси;
• стратегія тестування;
• загальні правила тестування: вимоги до
оформлення дефектів; • проєктні ризики;
• критерії готовності продукту до випуску; • ресурси, необхідні для виконання завдань;
• інструменти та техніки, які • проєктний план (терміни готовності

основних завдань).
використовуються.
1. Тест-план ідентифікатор (Test Plan Identi er)

Деякі компанії створюють номер для ідентифікації Тест-плану, його рівня та рівня
ПЗ, до якого він буде відноситися. Краще, якщо рівень Тест-плану буде
відповідати рівню програмного забезпечення. Також номер вказує на вид Тест-
плану: Загальний Тест-План, детальний план чи будь-який інший рівень.
Потрібно пам’ятати, що Тест-план, як і вся програмна документація, є
динамічним і повинен постійно оновлюватися. Таким чином, він буде мати
історію переглядів та змін.
2. Посилання (References)
Перелік усіх документів, на основі яких створюється Тест-план:
1. План Проєкту
2. Вимоги до продукту
80
 
 
 

 
 

fi
 


3. Архітектура продукту
4. Детальний дизайн продукту
5. Стандарти розробки та процесу тестування
6. Опис методології
7. Корпоративні стандарти
Також можуть бути посилання на інструментальні засоби, які використовуються

під час процесу тестування.
3. Введення (Introduction)
Визначення мети Тест-плану, ідентифікація рівня Тест-плану (Загальний і т.д.).
Також до цієї частини належать усі посилання на інші плани, які містять
інформацію про проєкт або процес. Краще створити блок з усіма посиланнями
на документи. Вказується опис об’єкта тестування, ресурси, обмеження
бюджету, об’єм роботи тестування.
4. Ризики (Software Risks)

Визначення критичних частин системи:
1. Постачання продукту третьою стороною.
2. Нова версія інтерфейсного програмного забезпечення.
3. Можливість використання інструментів.
4. Надзвичайно складні функції.
5. Модифікація невдалих компонентів системи.
6. Незадокументовані модулі чи зміни.
Також можуть бути ідентифіковані складні ризики, такі як:

1. Безпека
2. Численні інтерфейси
3. Відношення з клієнтом
4. Державні стандарти.
Ще один важливий фактор – це нерозуміння вимог до продукту. Такі ризики

можуть з’явитися на рівні розробки, менеджменту та користувача.
Належний підхід для виявлення ризиків – це постійні зустрічі з командою.
81

 
 


5. Функції, які будуть протестовані (Features to be tested або In Scope)

Список функцій, які повинні бути протестовані. Дані функції можуть бути
пріоритезовані: високий, середній та низький пріоритети.
6. Функції, які не будуть протестовані (Features not to be tested або Out of Scope)
Список функцій, які не будуть протестовані.
Визначення причин, за якими ці функції не будуть протестовані:

• функції не будуть входити до релізу програмного забезпечення;
• функції, які будуть розроблені, але не будуть протестовані в релізі
програмного забезпечення.
7. Підхід або Стратегія (Approach or Strategy)

Стратегія тестування — це план проведення робіт з тестування системи або її
модуля, який враховує специфіку функціональності та залежності з іншими
компонентами системи або платформи.
Стратегія визначає типи тестів, які потрібно виконати для даного функціоналу
системи, додає опис необхідних підходів з точки зору тестування та може
подавати опис або вимоги до необхідних для тестування інструментів або
інфраструктури.
Трохи страшно? Спробуємо розділити на більш детальні частини,
використовуючи, наприклад, розподіл за питаннями, на які відповідає стратегія
Стратегія відповідає на питання:
1. Які інструментальні засоби використовуються для тестування?
2. Чи потрібно проводити спеціальний тренінг для навчання співробітників?
3. Які метрики повинні бути зібрані?
4. Hardware (яке обладнання потрібно використати?)
5. Software (яке third-party ПЗ18 потрібно використати?)
6. Коли та як буде застосовуватися регресія?
7. Процес роботи зі зміною вимог (Change Management)
8. Процес роботи з дефектами (Defect Management)
9. Які види тестової документації будуть застосовуватися
10. Ключові ролі на проєкті
11. Які рівні та види тестування будуть застосовуватися
18 hird-party ПЗ – стороннє програмне забезпечення; іншого виробника
82

 
 


8. Критерій входу (Entry criteria)

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

• готовність та доступність тестового оточення;
• готовність засобу тестування в оточенні;
• доступність коду, який тестується;
• доступність тестових даних.
9. Критерій виходу (Exit criteria)

Критерій виходу визначає, коли потрібно припиняти тестування, наприклад, по
закінченню рівня тестування або коли набір тестів досягнув певної мети.
Зазвичай критерії виходу можуть покривати:
• щільність оцінки, наприклад, покриття коду, функціональності або ризиків;
• оцінку щільності дефектів або вимірювання надійності;
• вартість;
• кінцеві ризики, такі як невиправлені дефекти або недостача тестового
покриття будь-якої області;
• план, який заснований на часі виходу ПЗ на ринок.
10. Критерії зупинки та відновлення процесу тестування (Suspension and
resumption criteria)
Вказує на те, коли потрібно призупинити виконання тестів.
Якщо кількість дефектів або їх серйозність досягли тієї точки, де наступне
тестування не має жодного сенсу і його продовження буде пустою витратою
часу та ресурсів, то процес виконання тестів потрібно зупинити.
Якщо дефекти були виправлені або ті фактори, які перешкоджали тестуванню,
були виправлені, тестування може бути відновлене.
11. Сутності тестування (Test Deliverables)

Що повинно бути зроблено в рамках даного тест-плану та всього процесу
тестування?
• Тест план
• Тест кейси
• Тест докази
• Тест звіт
83
 
 


12. Середовище тестування (Environment)

Вказуються вимоги до середовища тестування:
• Спеціальне hardware
• Хто та які тестові дані будуть використовувати
• На скільки буде покритий тестами кожний компонент системи
• Версії та інше програмне забезпечення
• Обмежене використання системи на цьому етапі тестування.
13. Команда та відповідальність у команді (Responsibilities)

Хто за що відповідає?
• Визначення ризиків
• Визначення функцій, які (не) будуть протестовані
• Визначення стратегії для Плану даного рівня
• Наявність необхідних елементів для тестування
• Хто проводить тренінги
• Хто визначає, що додати/не додати до Тест-Плану
14. Графік (Schedule)

Графік тестування повинен базуватися на реальних оцінках часу на етап
розробки (скільки часу необхідно на імплементацію). Якщо дані оцінки
неправильні – зміститься увесь графік тестування.
Оцінка часу тестування
Розрізняють два підходи до оцінки трудовитрат у тестуванні:
• Заснований на метриках:
оцінка трудовитрат заснована на метриках попередніх або вихідних
проєктів або заснована на типових значеннях;
• Заснований на експертній оцінці:
оцінка завдань здійснюється ініціатором цих завдань або експертом.
Як тільки оцінка трудовитрат зроблена, можна визначити ресурси або скласти
графік.
Роботи з тестування можуть залежати від ряду факторів, включаючи:
• Характеристики продукту: якість специфікації або будь-якої іншої інформації,

які використовуються для моделей тестування (тобто основи тестування),
розмір продукту, складність предметної області, вимоги до надійності та
безпеки і вимоги до документації;
84
 
 
 


• Характеристики процесу розробки: стабільність організації, засоби, які

використовуються, процеси тестування, кваліфікація залучених людей та
часові обмеження;
• Результат тестування: кількість дефектів та об’єм роботи, яку необхідно
переробити.
15. Підтвердження (Approvals або Sign O )
Підписи та затвердження учасників, які мають відношення до даного документу:
• Project Manager
• Business Analyst
• Test Manager
3. ТЕСТОВЕ ПОКРИТТЯ
Тестове Покриття (Test coverage) – це одна з метрик оцінки якості тестування, яка
являє собою щільність покриття тестами вимог або виконуваного коду.
Якщо розглядати тестування як «перевірку між реальною та очікуваною поведінкою

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

буде обрано для перевірки вимог або виконуваного коду
Складність сучасного програмного забезпечення та інфраструктури зробили

неможливим завдання проведення тестування зі 100% тестовим покриттям. Тому
для розробки набору тестів, який забезпечує більш-менш високий рівень покриття,
можна використовувати спеціальні інструменти або техніки тест-дизайну.
Існують наступні підходи до оцінки та вимірювання тестового покриття:
1. Покриття вимог (Requirements Coverage) – оцінка покриття тестами

функціональних та нефункціональних вимог до продукту шляхом побудови матриць
трасування (traceability matrix).
2. Покриття коду (Code Coverage) – оцінка покриття виконуваного коду
тестами, шляхом відслідковування неперевірених у процесі тестування частин
програмного забезпечення.
85

ff
 


Відмінності:
Метод покриття вимог зосереджений на перевірки відповідності набору тестів, що
проводяться, до вимог до продукту, у той час як аналіз покриття коду – на повноті
перевірки тестами, розробленої частини продукту (вихідного коду).
Обмеження:
Метод оцінки покриття коду не виявить нереалізовані вимоги, оскільки працює не з
кінцевим продуктом, а з існуючим вихідним кодом.
Метод покриття вимог може залишити без перевірки деякі ділянки коду, тому що не
враховує кінцеву реалізацію.
Розглянемо більш детально кожний вид тестового покриття:
ПОКРИТТЯ ВИМОГ (REQUIREMENTS COVERAGE)

Розрахунок тестового покриття відносно вимог здійснюється за формулою:
Lcov
Tcov = 100%
Ltotal *
де:
Tcov – тестове покриття;
Lcov – кількість вимог, які перевіряються тест-кейсами;
Ltotal – загальна кількість вимог
Для вимірювання покриття вимог, необхідно проаналізувати вимоги до продукту та

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

це «білі плями», тобто якщо виконати всі створені тест-кейси, неможливо дати
відповідь, реалізована ця вимога в продукті чи ні.
Для оптимізації тестового покриття під час тестування на основі вимог, найкращим
способом буде використання стандартних технік тест-дизайну.
86
  

 
 

 
ПОКРИТТЯ КОДУ (CODE COVERAGE)

Розрахунок тестового покриття відносно виконуваного коду програмного
забезпечення здійснюється за формулою:
Ltc
Tcov = 100%
Lcode *
де:
Tcov – тестове покриття;
Ltc – кількість рядків коду, які покриті тестами;
Lcode – загальна кількість рядків коду.
У наш час існують різні інструментальні засоби, які дозволяють проаналізувати, у які
рядки були входження під час проведення тестування, завдяки чому можна значно
збільшити покриття, додавши нові тести для конкретних випадків, а також позбутися
дублюючих тестів.
Проведення такого аналізу коду та наступна оптимізація досить легко реалізуються

в рамках тестування методом білого ящику (white-box testing) під час модульного,
інтеграційного і системного тестування; під час тестування методом чорного ящику
(black-box testing) завдання стає досить дорогим, оскільки вимагає багато часу та
ресурсів на встановлення, конфігурацію та аналіз результатів роботи, як з боку
тестувальників, так і з боку розробників.
Тепер більш детально розглянемо Матрицю Трасування (Traceability Matrix).
Матриця трасування (traceability matrix) – спосіб відображення зв’язків між

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

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


• визначення покриття вихідних вимог (чи всі вимоги споживача, замовника

враховані в проєкті?),
• визначення зв’язків між вимогами та функціями, даними та функціями
проєктованої системи,
• розподілу функцій за елементами фізичної архітектури системи,
• керування іншими типами проєктних даних, наприклад, розподіл User Story
за спринтами (у рамках методології Scrum).
Системні аналітики люблять використовувати матриці трасування, тому що вони

наочні та дозволяють швидко знайти «підозрілі» точки в проєктних рішеннях, а
також оцінити область змін під час зміни вихідних вимог.
Наприклад, за матрицею трасування легко побачити, що спроєктована функція
не потрапила в жодний компонент. Так само можна оцінити перезавантаження
компонентів.
Рис 5.1. Матриця трасування
88


1. Що таке тест-план?
2. Які розрізняють атрибути тест-плану?
3. Що таке Entry і Exit критерії в тест-плані?
4. На базі чого описують Schedule?
5. Які розрізняють види тест-планів?
6. Хто може описувати тест-план?
7. Що таке матриця трасування?
8. Які розрізняють види тестового покриття?
9. Які інструментальні засоби можна використовувати для написання
тест-плану та визначення тестового покриття?
89

 
Модуль ІІІ.
АНАЛІЗ, РОЗРОБКА ТА ВИКОНАННЯ
ТЕСТІВ
Заняття 6.
ОГЛЯД ЧЕК-ЛИСТА, ТЕСТ КЕЙСУ ТА РИСК ЛОГУ
1. ДЕТАЛЬНИЙ ОГЛЯД ЧЕК-ЛИСТА (CHECK LIST)
2. ДЕТАЛЬНИЙ ОГЛЯД ТЕСТ КЕЙСУ (TEST CASE)
3. ДЕТАЛЬНИЙ ОГЛЯД РИСК ЛОГУ (RISK LOG)
4. ПОЗИТИВНЕ ТА НЕГАТИВНЕ ТЕСТУВАННЯ
5. ТЕСТ НАБІР І ТЕСТОВИЙ СЦЕНАРІЙ
1. ДЕТАЛЬНИЙ ОГЛЯД ЧЕК-ЛИСТА (CHECK LIST)
Чек-листи – один з фундаментальних інструментів тестування. Вони дозволяють

не забуватися про важливі тести, фіксувати результати своєї роботи та
відслідковувати статистику про статус програмного продукту.
Чек-лист – це документ, який описує, які функції необхідно перевірити.
Чек-листи тестування можуть мати зовсім різні рівні деталізації. Іноді чек-листами
називають детальні інструкції про продукт, який тестується, інструкції, які містять
послідовність дій, безліч деталей і т. д. Це не так! Головний принцип чек-листів
полягає у тому, що кожен тестувальник по-своєму проходить їх та розширює
тестовий набір своєю експертизою.
Таблиця 6.1 Плюси та мінуси чек-листів
ПЛЮСИ МІНУСИ
• статистика: хто, коли, що проходив (з • тестувальники-початківці не завжди
деталізацією зі збирання продукту та ефективно проводять тести без досить
оточенню, на якому проводилось детальної документації;
тестування); • чек-листи неможливо використовувати для
• пам’ятка, яка допомагає не забути навчання нових співробітників, оскільки в
важливі тести; них недостатньо детальної інформації;
• можливість оцінити стан продукту, його • замовнику або керівництву може бути
готовність до випуску. недостатньо того рівня деталізації, який
пропонують чек-листи.
90
 
 

Mодуль ІІІ. АНАЛІЗ, РОЗРОБКА ТА ВИКОНАННЯ ТЕСТІВ

6. ОГЛЯД ЧЕК-ЛИСТА, ТЕСТ КЕЙСУ ТА РИСК ЛОГУ
Приклад Чек-листа для додатку «Калькулятор»:

Функція Результат перевірки
Версія 1.1 Версія 1.2 Версія 1.3
Додавання passed passed bugs
Цілих чисел passed passed passed
Дробових чисел passed passed failed
Негативних чисел passed passed passed
Позитивних чисел passed passed passed
Ділення bugs passed passed
Негативних чисел failed passed passed
Позитивних чисел passed passed passed
Ділення на нуль passed passed passed
2. ДЕТАЛЬНИЙ ОГЛЯД ТЕСТ КЕЙСУ (TEST CASE)
Тест кейс (Test Case) – це тестовий артефакт, який описує сукупність кроків,
конкретних умов та параметрів, які є необхідними для перевірки реалізації
функції, що тестується, або її частини.
Тест кейс – це мінімальний елемент тестування.

Гарний тест кейс складається з трьох частин та має наступну структуру:
• Список дій, що приводять продукт, який тестується, у потрібний стан

(Preconditions).
• Список дій, якими можна верифікувати те, що підлягає перевірці (Test Case
Description).
• Список дій, що приводять продукт у вихідний стан (Postconditions).
💡 ВАЖЛИВО
Суттєвим є те, що процес верифікації тільки один. Саме тому тест кейс не можна
подрібнити, розбити на декілька ще менших частин. Тому він є мінімальним
елементом перевірки. Якщо верифікацій більше, ніж одна, це вже не тест кейс.
Перший та третій компоненти тест кейсу також дуже важливі. Вони роблять різні
тест кейси незалежними один від одного. Їх можна виконувати в будь-якій
послідовності. Це дуже важливо під час автоматизації тестування. Але для
ручного тестування це також важливо. Тому що з тест кейсів складають тест світ
(test suite) – групу зв’язаних тест кейсів.
91


ВИДИ ТЕСТ КЕЙСІВ
Тест кейси поділяються за своїм майбутнім результатом на позитивні (Positive) і

негативні (Negative):
Позитивний тест кейс (Positive test case) використовує тільки коректні дані та
перевіряє, що додаток правильно виконав функцію, яку очікують.
Додаток здійснює пошук даних за певними параметрами і один з параметрів –
телефон користувача. Ми вводимо в поле «Телефон» цифрові значення та
натискаємо кнопку «Пошук». Додаток повинен коректно знайти дані, які
відповідають тому критерію, який був заданий. У такому випадку, коректні дані для
поля це цифри. Відповідно в такому випадку ми перевіряємо, наскільки коректно
працює система з коректними даними.
Негативний тест кейс (Negative test case) оперує як коректними, так і

некоректними даними (мінімум 1 некоректний приклад) та визначає своєю метою
перевірку виняткових ситуацій (спрацювання валідаторів), а також перевіряє, що
функція, яку викликає додаток, не виконується під час спрацювання валідатора.
Візьмемо попередній додаток, що здійснює пошук даних за визначеними
параметрами і один з параметрів – телефон користувача. Ми вводимо в поле
«Телефон» буквенні значення та натискаємо кнопку «Пошук». Оскільки буквенні
символи є недопустимими для поля телефону, додаток повинен коректно
опрацювати цей випадок, наприклад, після натискання кнопки «Пошук», повинно
з’явитися попереджувальне діалогове вікно. Відповідно в такому випадку ми
перевіряємо, наскільки коректно система опрацьовує неправильні вхідні дані.
Також тест кейси розподіляються за деталізацією опису на високорівневі (high-

level) і деталізовані (detailed або low- level)
Високорівневий тест кейс (High-level test case) – тест кейс без конкретних
вхідних даних, реальні дані та результат, який очікується, не визначені або
невідомі, використовуються логічні вирази. Якщо результат, який очікується,
невідомий, він також не вказується.
92
 
 


Деталізований тест кейс (Detailed test case) – тест кейс з конкретними

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

високорівневий та детальний тест кейси.
Візьмемо додаток «Блокнот» (Notepad) і розглянемо роботу кнопки «Find Next»

діалогового вікна «Find»
Розглянемо вимогу: Кнопка «Find Next» повинна бути неактивна, якщо поле
«Find what:» не містить жодного символу, і активна, коли це поле містить як
мінімум один символ. Виходячи з поданої вимоги, ми вже можемо визначити
результат, який очікується, для високорівневого тест кейсу, так само для
детального тест кейсу.
93


Таблиця 6.2 Приклад високорівневого Test case:
Назва тест кейсу Дія Очікуваний результат
1.Активна 1.Відкрити додаток «Notepad» Додаток «Notepad» було успішно запущено

кнопка «Find
Next» (HLTC)
2.Ввести будь-які символи у Введені символи коректно відображаються
текстове поле додатку у текстовому полі додатку
3. Відкрити діалогове вікно «Find» Діалогове вікно «Find» було успішно відкрито
4. Ввести у поле «Find what:» як

мінімум один символ, якщо його Кнопка «Find Next» активна
там немає
5. Закрити додаток «Notepad» Додаток «Notepad» було успішно закрито
2. Не активна 1.Відкрити додаток «Notepad» Додаток «Notepad» було успішно запущено

кнопка «Find
Next» (HLTC)
2.Ввести будь-які символи у Введені символи коректно відображаються
текстове поле додатку у текстовому полі додатку
3. Відкрити діалогове вікно

Діалогове вікно «Find» було успішно відкрито
«Find» та видалити текст у полі
«Find what:», якщо він там є кнопка «Find Next» не активна
4. Закрити додаток «Notepad» Додаток «Notepad» було успішно закрито
94
 
 
 
 
 
 
Таблиця 6.3 Приклад деталізованого Test Case:
Назва тест кейсу Дія Очікуваний результат
1.Запустити виконуваний файл

1.Активна Додаток «Notepad» було успішно запущено
«Notepad.exe»
кнопка «Find
Next» (DTC) 2.Ввести слово “test” у текстове Слово “test” коректно відображається у
поле додатку текстовому полі додатку
3. Клікнути лівою кнопкою миші на

Випадаюче меню було відкрито
елементі головного меню «Edit»
4. Вибрати елемент випадаючого Діалогове вікно «Find» було успішно

меню «Find…» і клікнути на ньому відкрито, поле «Find what:» не містить
лівою кнопкою миші у собі символів
5. Ввести у поле «Find what:»

Кнопка «Find Next» активна
символ «t»
6 Клікнути лівою кнопкою миші З’явилось діалогове вікно з підтвердженням

на червону кнопку з хрестиком про зберігання даних
7. Клікнути на кнопку «Don’t Save» Додаток «Notepad» було успішно закрито
1.Запустити виконуваний файл

2. Не активна Додаток «Notepad» було успішно запущено
«Notepad.exe»
кнопка «Find
Next» (DTC) 2.Ввести слово “test” у текстове Слово “test” коректно відображається у
поле додатку текстовому полі додатку
3. Клікнути лівою кнопкою миші на

Випадаюче меню було відкрито
елементі головного меню «Edit»
4. Вибрати елемент випадаючого Діалогове вікно «Find» було успішно

меню «Find…» і клікнути на ньому відкрито, поле «Find what:» не містить
лівою кнопкою миші у собі символі, кнопка «Find Next» не активна
5. Ввести у поле «Find what:»

Кнопка «Find Next» активна
символ «t»
6. Видалити символ «t» з поля

Кнопка «Find Next» неактивна
«Find what:»
7. Клікнути лівою кнопкою миші З’явилось діалогове вікно з підтвердженням

на червону кнопку з хрестиком про зберігання даних
8. Клікнути на кнопку «Don’t Save» Додаток «Notepad» було успішно закрито
95
 
 
 
 
АТРИБУТИ TEST CASE, ЯК ДОКУМЕНТА
• Номер тест кейсу (Test Case ID) – вказується номер кейсу.

• Назва тест кейсу (Test Case Name) – вказується ім’я кейсу.
• Ким створений (Created by) – вказується ім’я тестувальника, який створив
даний Тест кейс.
• Посилання на вимоги (Reference requirements) – вказується вимоги зі

специфікації, на базі яких був створений тест кейс (якщо інформація
доступна).
• Вид Тестування (Testing type) – вказується тип тестування, який

застосовується в даному тест кейсі (не обов'язковий атрибут).
• Компонент (Component) – вказується частина системи, яка тестується.

• Кроки або послідовність дій (Steps) – список дій, які переводять систему з
одного стану в інший, для отримання результату, на основі якого можна
зробити висновок про задоволення реалізації поставлених вимог.
• Очікуваний результат (Expected Result) – очікуваний результат, який

визначається вимогами до частини системи.
• Пріоритет (Priority) – визначає, наскільки важливим для перевірки є даний

тест кейс (черговість виконання).
3. ДЕТАЛЬНИЙ ОГЛЯД РИСК ЛОГА (RISK LOG)
Риск Лог (Risk Log) – тестовий артефакт, який відповідає за перевірку певної
функціональності, може мати різний рівень деталізації та базується на ризиках.
Останнім часом на різних проєктах почали використовувати такий тестовий

артефакт як «Риск Лог», який, по суті, заміняє тестовий артефакт «Тест кейс».
Коротко розглянемо, як описувати Риск Лог для певної функціональності.

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


Для прикладу візьмемо вимогу, яку ми вже розглянули в прикладі з Тест

Кейсом: Кнопка «Find Next» повинна бути неактивна, якщо поле «Find what:» не
містить жодного символу, і активна, коли дане поле містить як мінімум один
символ.
У такому випадку ми маємо два ризики, які можуть виникнути для поданої
вимоги.
Перший ризик: Кнопка «Find Next» активна, якщо поле «Find what:» не містить
жодного символу.
Другий ризик: Кнопка «Find Next» не активна, якщо поле «Find what:» містить як
мінімум один символ.
Перший та другий ризики будуть Риск Логами для розглянутої вище вимоги.
Як працювати з даними Риск Логами та як проводити тестування, спираючись на
них? Якщо у випадку з Тест Кейсами ми покроково проходили все, що було
описано в Тест Кейсі, то Риск Лог повинен спростувати той факт, який описаний
у Риск Лозі, і коли цей факт спростований, Риск Лог вважається успішно
пройденим.
Для прикладу візьмемо Риск Лог: Кнопка «Find Next» активна, якщо поле «Find
what:» не містить жодного символу. Якщо ми упевнимось у тому, що поле «Find
what:» не містить жодного символу, але при цьому кнопка «Find Next» неактивна,
як зазначено у вимозі, то Риск Лог буде вважатися успішно пройденим, якщо
даний Ризик був перевірений та доведено, що він не виник під час перевірки.
4. ПОЗИТИВНЕ ТА НЕГАТИВНЕ ТЕСТУВАННЯ
“Позитивне” тестування –це тестування на даних або сценаріях, які відповідають

нормальній (штатній, очікуваній) поведінці системи.
Головною метою “позитивного” тестування є перевірка того, що за допомогою

системи можна робити те, для чого вона була створена.
“Негативне” тестування –це тестування на даних або сценаріях, які відповідають

нештатній поведінці системи, яка тестується, - різноманітні повідомлення про
помилки, виключені ситуації, «позамежні» стани і т.п.
97
 
Головною метою “негативного” тестування є перевірка стійкості системи до

різноманітних впливів, валідація неправильного набору даних, перевірка
обробки виключних ситуацій (як в реалізації програмних алгоритмів, так і в
логіці бізнес-правил).
Однак передувати «позитивному» та «негативному» тестуванню повинні роботи з

виконання «димового» тестування.
Чому “позитивне” тестування вважається важливішим, ніж “негативне”?

Припустимо, що система не дуже стійка до «поганих» вхідних даних. Це
страшно? Як правило, не дуже. Користувачі рано чи пізно навчаться обходити
«підводні камені», не будуть робити «небезпечні» або «недозволені» дії, служба
технічної підтримки скоро запам’ятає, які проблеми зазвичай виникають у
користувачів і будуть давати поради на кшталт «ні в якому разі не залишайте це
поле пустим, інакше…».
АЛЕ – усього цього не буде зовсім, якщо система не виконує своє основне
призначення, якщо користувачі (замовники) не можуть вирішити свої бізнес-
завдання, якщо вони все роблять правильно, вводять коректні дані, але не
отримують результат. І порадити їм нічого в такому випадку не можна.
Саме тому «позитивне» тестування набагато, набагато важливіше «негативного».
Помилки у нормальній поведінці, які заважають користувачам виконувати

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

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

стає важливим тільки тоді, коли всі позитивні тести вже виконані.
98


5. ТЕСТ НАБІР І ТЕСТОВИЙ СЦЕНАРІЙ
Тест Набір або Тест Світ (Test Suite) – це набір тест кейсів, які об’єднані тим, що
відносяться до одного модуля, який тестується, до функціональності, пріоритету
або одного типу тестування. Кожен тест світ складається з більш ніж одного тест
кейсу і часто виконується усією «пачкою» у процесі тестування.
Тест кейси об’єднуються у тест світи для більшої зручності під час проходження
тест кейсів, виконуючи їх послідовно від модуля до модуля, від одного типу
тестування до іншого, а не сумбурно, кидаючись з одного кутка в інший, та
залишаючи неперевіреною більшу частину модуля чи загальної функціональності.
Тестовий Сценарій (Test Scenario) – це набір дій, які потрібно виконати для
перевірки того, наскільки коректно працює функціонал усієї системи.
Як правило, це послідовність тих дій, які кінцевий користувач буде
здійснювати для вирішення своїх завдань.
1. Що таке чек-лист та для чого він потрібен?

2. Яка різниця між тест кейсом і тест планом?
3. Назвіть основні атрибути тест кейсу.
4. Для чого потрібні передумова та післяумова у тест кейсах?
5. Яка різниця між деталізованим та високорівневим тест кейсами?
6. Що має вищий пріоритет, позитивне чи негативне тестування, чому?
7. Що таке тестовий набір?
8. Які можна назвати плюси/мінуси тест кейсу та риск лога?
99


7. ТЕХНІКИ ТЕСТУВАННЯ
Заняття 7. ТЕХНІКИ ТЕСТУВАННЯ

1. СТАТИЧНЕ ТА ДИНАМІЧНЕ ТЕСТУВАННЯ
2. СТАТИЧНІ ТЕХНІКИ ТЕСТУВАННЯ
3. ДИНАМІЧНІ ТЕХНІКИ ТЕСТУВАННЯ
1. СТАТИЧНЕ ТА ДИНАМІЧНЕ ТЕСТУВАННЯ

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

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

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

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

1. Запуску системи або підсистеми;
2. Великої кількості необхідних функціональних елементів або модулів;
3. Порівняння через графічний інтерфейс користувача поведінки системи та
очікуваного результату поведінки.
100

 
ТЕХНІКИ ТЕСТУВАННЯ
Статичні Динамічні
Неформальне рецензування Базуються на специфікації
Класи еквівалентності
Проходження
Граничні значення
Технічне рецензування
Таблиця прийняття рішень
Формальне рецензування Тестування переходу станів
Сценарії виконання
Статичний аналіз
Причина/Наслідок
Базуються на досвіді
Передбачення помилок
Дослідницьке тестування
Базуються на структурі
Не розглядаються у даному курсі
Базуються на дефектах
Не розглядаються у даному курсі
Рис 7.1 Техніки тестування
101
 
 
2. СТАТИЧНІ ТЕХНІКИ ТЕСТУВАННЯ

Одним з основних видів статичних технік тестування є рецензування (Review). Один і
той самий документ може підлягати різним типам рецензії.
Існує чотири типи рівня рецензії:

Low
Informal
Walkthrough Level
of formality
Technical review
Inspection High
Рис. 7.2. Типи рівня рецензії
Ролі, які використовуються в поданих видах рецензії:
Модератор (Moderator)
Модератор – лідер процесу рецензії. Це та людина, разом з автором, яка визначає
тип рецензії, підхід та склад команди. Модератор також складає графік зустрічей,
поширює документи до початку зустрічей та зберігає всі зібрані дані.
Автор (Author)
Автор рецензованого документа. Головна мета автора – покращити якість
документа і з’ясувати якомога більше неточностей та недоробок у документі.
Рецензенти (Reviewers) – головне завдання рецензентів – перевірити документ на

наявність помилок. Рівень ретельності перевірки залежить від виду рецензії.
Розглянемо більш детально кожний тип рецензії:
1. Неформальне рецензування (Informal Review) – найпоширеніший вид

рецензування. Цей процес виконується багато разів на ранніх стадіях життєвого
циклу документа. Команда для неформального рецензування може складатися
всього з двох осіб: автора та людини, яка буде переглядати документ.
Головна мета цього рецензування – допомогти автору покращити якість
документа. Головна характеристика – таке рецензування не документується.
102
 
 


2. Наскрізний огляд (Walkthrough)

Цей тип рецензування здійснюється автором документа. Формат проведення мітингів
вільний (від неформального до найбільш формального). Підготовка рецензентів до
мітингу та створення звіту – опціонально. Головна мета ознайомитися, зрозуміти документ
та знайти помилки.
3. Технічне рецензування (Technical review)

При такому типі рецензування усі помилки та зміни добре задокументовані. Мітинг
проводиться модератором, але не автором документа. Команда обов’язково готується до
мітинга. Мітинг може відбуватися як в формальному, так і неформальному форматі та
ставити перед собою цілі обговорити та прийняти рішення щодо документа, виявити
помилки, перевірити документ на відповідність специфікаціям та стандартам.
4. Формальне рецензування (Formal Review или Inspection) – на відміну від

неформального рецензування, формальне слідує певному процесу, який складається з
шести пунктів:
1. Планування (Planning)
2. Перший мітинг (Kick-off meeting)
3. Підготовка (Preparation)
4. Другий мітинг (Review meeting)
5. Виправлення документа (Rework)
6. Перегляд змін (Follow-up)
Планування (Planning) – процес рецензування починається з «вимог про

рецензію» автора до модератора (або лідера інспекції). Модератору часто доводиться
піклуватися про планування (дату, час, місце та запрошення) перевірки. Для більш
ефективних перевірок, наприклад, інспекції, модератор завжди визначає на даному етапі
формальні критерії входу/виходу для процесу рецензування. Етап входу визначає,
наскільки документ готовий до перегляду. Документ, який містить велику кількість
помилок, не підходить для формального рецензування.
Інші види етапу входу:

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


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

перевірити, були обрані, модератор, у співробітництві з автором, визначає склад
команди з огляду. Команда зазвичай складається з 4-6 учасників. Для
підвищення ефективності огляду, різні ролі призначаються кожному з учасників.
Ці ролі допомагають команді зосередити увагу на конкретних типах дефектів у
процесі перевірки.
Перший мітинг (Kick-o meeting) – додатковий крок у процесі перегляду

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

індивідуальному порядку над документом, використовуючи відповідні супровідні
допоміжні документи, правила, процедури. Учасники визначають дефекти,
питання, коментарі відповідно до розуміння мети документа. Усі питання
записуються, переважно у формі журналу. Орфографічні помилки записуються
на документі, але не згадуються у процесі наради. Критичним фактором успіху
для ретельної підготовки є кількість сторінок, які перевіряються за годину. Це
має назву швидкість перевірки.
Оптимальна швидкість перевірки є результатом поєднання ряду факторів, у
тому числі типу документа, його складність, кількість пов’язаних з ним
документів, а також досвід рецензента. Зазвичай швидкість перевірки
знаходиться в діапазоні від 5 - 10 сторінок за годину, але може бути значно
менше, для формального огляду, наприклад, одна сторінка за годину.
Другий мітинг (Review meeting) – зустріч зазвичай складається з наступних фаз:
1. Реєстраційна фаза (logging phase),

2. Фаза обговорення (discussion phase).
104

ff


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

допускається під час фази реєстрації. Якщо питання потребує обговорення,
пункт реєструється, а потім обробляється на стадії обговорення.
Кожному дефекту призначається пріоритет учасником команди:
1. Критичні дефекти (Critical defects) – дефекти в документі, які зменшують

якість продукту в загальному (архітектурі).
2. Основні дефекти (Major defects) – несправність в конструкції може

призвести до помилки в реалізації.
3. Незначні дефекти (Minor defects) – недотримання шаблонів та стандартів.
Фаза обговорення
Протягом цієї фази будуть розглядатися усі можливі питання та коментарі.
Учасники можуть взяти участь у дискусії, висловити свої зауваження та думки. У
якості голови засідання виступає модератор.
Найбільш критичним фактором завершення даної фази є визначення кількості

критичних, основних та незначних дефектів. Якщо кількість знайдених дефектів
на одній сторінці перевищує визначений критерій, то документ повинен бути
переглянутий ще раз після доопрацювання. Якщо кількість дефектів відповідає
визначеним критеріям, то документ буде розглянутий модератором на етапі
перегляду змін (follow up).
Виправлення документа (Rework) – на базі знайдених дефектів, автор

покращує якість документа. Не кожний дефект потребує конкретних виправлень
в документі, завдання автора – визначити, які дефекти можуть не виправлятися.
Усі зміни документуються для зручності перевірки на наступному етапі.
Перегляд змін (Follow-up) – на цьому етапі модератор перевіряє, які саме

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

самі кроки можуть називати Technical review або Inspection.
105
 


Фактори вдалого проведення review:
• До кожної рецензії повинен бути чіткий, раніше визначений список цілей.

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

Помилки озвучуються об’єктивно
• Застосування одного з типів рецензії (формальне або неформальне)

• Серед учасників розподіляються ролі (якщо необхідно) з метою
покращення ефективності
• Необхідна підтримка з боку менеджменту

Також існує ще один вид техніки статичного тестування – Статичний аналіз.
СТАТИЧНИЙ АНАЛІЗ (STATIC ANALYSIS)

Як і рецензія, статичний аналіз передбачає пошук помилок без запуску самого
коду програми. Проводиться після того, як код був написаний.
Цілі статичного аналізу:
• Раннє виявлення багів

• Раннє виявлення слабких моментів у архітектурі та коді
• Виявлення помилок, які відносяться до порушення стандартів розробки,
порушення взаємодії між моделями, інтерфейсами класів і т. п.
• Запобігання виникненню багів – аналіз першопричин багів, які вже є,
допомагає виправляти схожі баги на рівні архітектури програми або на
ранній стадії розробки.
Типові помилки, які можна виявити за допомогою статичного аналізу:
• На рівні коду – звертання до змінної без певного значення

• Мертвий код (dead code)
• Порушення стандартів програмування (наприклад, коментарі до коду
написані, але відсутні коментарі протягом коду)
• Порушення безпеки (наприклад, структури для зберігання паролів
недостатньо захищені)
106

Аналіз коду і структур так само здійснюється за допомогою автоматичних

інструментів. Програми здійснюються в автономному режимі та генерують звіт
своєї роботи.
3. ДИНАМІЧНІ ТЕХНІКИ ТЕСТУВАННЯ

1. ТЕХНІКИ, ЯКІ БАЗУЮТЬСЯ НА СПЕЦИФІКАЦІЇ (SPECIFICATION-BASED
TECHNIQUES) (ТЕХНІКИ ТЕСТ ДИЗАЙНУ)
1. 1. Класи еквівалентності (Equivalence Partitioning - EP) – розробка тестів

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

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

якщо ми виконаємо два будь-які тести з одного класу еквівалентності – отримаємо
один і той самий результат.
Метою такої техніки є не тільки скорочення кількості тестів (відповідно й

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

більшість тестів будуть зайвими (надлишковими).
• занадто маленька кількість еквівалентних тестів збільшує ймовірність того, що

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

структурованості тестування.
• До недоліків можна віднести те, що за умови неправильного використання

техніки ми ризикуємо не виявити баги.
107


Розглянемо приклад. Припустимо, ми тестуємо Інтернет-магазин, який продає

олівці. У замовленні необхідно вказати кількість олівців (максимум для
замовлення – 1000 штук). Залежно від кількості олівців, як замовляються,
розрізняється вартість:
1 – 100 – 10 грн. за олівець;

201 - 300 – 8 грн. за олівець і т.д.
З кожною новою сотнею, ціна зменшується на грн.
Якщо тестувати усі можливі варіанти обробки замовленої кількості олівців,

потрібно написати дуже багато тестів (згадуємо, що можна замовити аж 1000
штук), а потім ще все це протестувати. Спробуємо застосувати розподіл на класи
еквівалентності. Очевидно, що наші вхідні дані ми можемо розділити на наступні
класи еквівалентності:
Невалідне значення: >1000 штук;

Невалідне значення: <=0;
Валідне значення: від 1 до 100;
Валідне значення: від 901 до 1000.
На основі цих класів ми й складемо тестові сценарії. Отже, якщо взяти по

одному представнику з кожного класу, то отримаємо 12 тестів. 12 – не дуже
багато, але чи достатньо? Чи забезпечить такий набір тестів гарантію якості?
Давайте розглянемо наступну техніку: аналіз граничних значень, і спробуємо

відповісти на ці питання.
108
 

 
1. 2. Граничні значення (Boundary Values) – це техніка перевірки помилок на

межах класів еквівалентності.
Якщо техніка аналізу класів еквівалентності орієнтована на тестове покриття, то ця

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

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

важливий крок, від правильності розподілу на класи еквівалентності залежить
ефективність тестів граничних значень.
2. Потім необхідно визначити граничні значення цих класів.
3. Нам потрібно зрозуміти, до якого класу буде належати кожна межа.
4. Для кожної межі нам необхідно провести тести по перевірки значення до
межі, на межі і одразу після межі.
Переваги та недоліки
Ця техніка додає до техніки аналізу класів еквівалентності орієнтованість на
конкретний тип помилок. Тобто, техніка аналізу класів еквівалентності просто
говорить нам про те, що необхідно розбити усі тести на класи та провести
тестування усіх класів. А техніка граничних значень орієнтована на виявлення
конкретної проблеми – виникнення помилок на межі класів еквівалентності.
Але, як і для техніки аналізу класів еквівалентності, ефективність техніки аналізу

граничних значень залежить від правильності її використання. Ми повинні
прикласти зусилля, аби правильно визначити класи еквівалентності та їх межі. Якщо
ми віднесемось до цього поверхнево – ризикуємо припуститись помилок.
Чому цей підхід може бути корисним? Як задаються обмеження в коді? Зазвичай
знаками більше, менше, дорівнює. І помилку можна «накодити» запросто, якщо
поставити не те значення у прикладі, не той знак. Повернемось до наших олівців
(див. Розподіл на класи еквівалентності), залежно від кількості замовлених олівців,
розрізняється вартість:

201 - 300 – 8 грн. за олівець і т.д. З кожною новою сотнею, ціна зменшується на грн.
110
 


Максимально можна замовити – 1000 штук.

Використовуючи метод еквівалентного розподілу, були виділені наступні класи:
Невалідне значення: >1000 штук;

Невалідне значення: <=0;
Валідне значення: від 901 до 1000.
Саме час взятися за граничні значення цих самих класів.
Наприклад, для значення еквівалентності від 1 до 100 маємо наступні граничні

значення:
0, 1, 2 і 99, 100, 101.
У ці значення повинні входити безпосередньо межі класу, тестування яких буде

позитивним тестуванням: це 1 і 100. Потім беруться значення на крок «всередину»
класу, тестування яких також буде позитивним: це 2 і 99. І також значення на крок
«поза» класом еквівалентності: це 0 і 101.
Тестування цих значень у межах цього класу еквівалентності буде вважатися

негативним тестуванням.
Розглянемо граничні значення для класу еквівалентності від 101 до 200.

Результат буде наступним: 100, 101, 102 та 199, 200, 201.
Знову-таки, значення 101, 102 і 199, 200 для цього класу будуть позитивними тестами.
А 100 і 201 – негативними.
Можна помітити, що деякі значення у межах різних класів еквівалентності

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


Наприклад,
тестування значення 101: для класу еквівалентності від 1 до 100 – це негативний
кейс, а для класу еквівалентності від 101 до 200 – це позитивний тест. Для роботи
усієї програми це буде один кейс, адже очікуваний результат не змінюється: для
значення 101 очікуваний результат складає 9 грн.
Таким чином виписуємо граничні значення для усіх класів еквівалентності:
0, 1, 2 і 99, 100, 101

100, 101, 102 і 199, 200, 201
200, 201, 202 і 299, 300, 301
300, 301, 302 і 399, 400, 401
400, 401, 402 і 499, 500, 501
500, 501, 502 і 599, 600, 601
600, 601, 602 і 699, 700, 701
700, 701, 702 і 799, 800, 801
800, 801, 802 і 899, 900, 901
900, 901, 902 і 999, 1000, 1001
А також для негативних класів еквівалентності:

-1
1001.
Як ми бачимо, оскільки є перевірки на межі класів, багато значень повторюються.
Тому зараз записуємо, які значення будемо тестувати, використовуючи техніку
граничних значень та уникаючи повторів:
Значення Очікуваний результат
-1 Невалідне значення
0 Невалідне значення
1, 2 та 99, 100 10 грн. за олівець
101, 102 і 199, 200 9 грн. за олівець
202, 202 299, 300 8 грн. за олівець
і 302 і 399, 400
301, 7 грн. за олівець
401, 402 і 499, 500 6 грн. за олівець
501, 502 і 599, 600 5 грн. за олівець
601, 602 і 699, 700 4 грн. за олівець
701, 702 і 799, 800 3 грн. за олівець
801, 802 і 899, 900 2 грн. за олівець
901, 902 і 999, 1000 1 грн. за олівець
1001 Невалідне значення
111
 


Таким чином, для перевірки цього завдання технікою граничних значень,

потрібно зробити 43 тести.
Отже, отримуємо по 3 значення на межу, а також беремо по одному значенню з

«тіла» класів еквівалентності, усього: 43 + 12 беремо для перевірки 55 значень.
Це більше, ніж 12 тестів, але значно менше, ніж 1000 тестів. До того ж
перевіряємо не тільки валідні значення, але і невалідні!
1. 3. Таблиця прийняття рішень (Decision table) – чудовий інструмент для

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

Умови
Умова 1
Умова 2
…
Умова m
Дії
Дія 1
Дія 2
…
Дія n
Розглянемо на прикладі функції «Реєстрація нового користувача на сайті».
Припустимо, що веб-форма містить два обов’язкових для заповнення поля: Ім’я

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


Правило 1 Правило 2 Правило 3 Правило 4
Умови
Введення коректних даних
+ - + -
у поле "E- mail"
Введення коректних даних
+ - - +
у поле "Ім’я"
Введення некоректних даних
- + - +
у поле "E-mail"
Введення некоректних даних
- + + -
у поле "Ім’я"
Дії
Реєстрація успішна + - - -
Помилка, виправте дані - + + +
Правила 2, 3 і 4 призводять до одного і того ж результату, але з різними

значеннями входу. Дуже важливо під час розробки тест-кейсів не пропустити
різні шляхи проходження продукту для отримання однакового результату.
Чому варто використовувати?

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

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

коли систему, яку тестують, можна класифікувати як «машину з кінцевими станами».
Це означає, що система може знаходитись у певній (кінцевій) кількості різних станів.
Перехід від одного стану до іншого визначається певними правилами даної
«машини».
State-Transition testing, як і decision tables testing, чудовий інструмент для фіксації

вимог та опису дизайну додатку. На відміну від Decision tables testing, які
описують конкретний стан додатку, State-Transition testing описують, які ці стани
додатку можуть змінюватися. Діаграми визначають усі події, які виникають під
час роботи додатку, і як додаток реагує на всі ці події.
113


Використання техніки State-Transition testing простіше пояснити одразу в роботі,

на прикладах:
Діаграми переходів стану

Розберемо приклад бронювання авіаквитків. Працює це наступним чином.
Спочатку ми як клієнт надаємо авіакомпанії інформацію для бронювання – місце

відправлення, місце прибуття, дату та час відправлення. Працівник авіакомпанії
слугує інтерфейсом між нами та системою бронювання авіаквитків та
використовує надану нами інформацію для створення бронювання. Після цього
наше бронювання знаходиться в стані "Made" (зроблене). На додачу, після
створення бронювання, система бронювання запускає таймер. Якщо таймер
добігає кінця, а зарезервований квиток не оплачений – система скасовує
бронювання. У вигляді State-Transition diagrams це матиме такий вигляд:
Круг демонструє собою стан системи бронювання авіаквитків, у нашому випадку

це "Made" стан. Стрілка показує перехід у стан "Made". Опис під стрілкою
("giveInfo") це подія, яка надходить ззовні системи. Команда, у описі під стрілкою
(після «/"), говорить нам, що система зробила якусь дію у відповідь на подію, у
нашому випадку це запуск таймера. Чорна точка вказує на початок/вхід
діаграми.
114
 
 


Далі. Якщо таймер не добігає кінця і ми оплатили зарезервований квиток, то

система переходить у стан "Paid" (оплачений). Це показано стрілкою
"payMoney" (заплатити гроші) та переходом зі стану "Made" у стан "Paid".
Перш ніж продовжити, необхідно визначитися з поняттями:
Стан (state)(круг на діаграмі) – це стан додатку, у якому воно очікує на

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

стану в інший, відбувається відповідно до подій.
Подія (event) (ярлик над стрілкою) – це те, що змушує додаток змінити свій
стан. Події можуть надходити ззовні додатку, вони надходять через інтерфейс
додатку. Так само додаток може генерувати події, наприклад, як подія «час
таймера добіг кінця». Коли відбувається подія, додаток може змінити стан або
залишитися в тому ж стані і/або виконати дію. Події можуть мати параметри,
наприклад, подія "payMoney" може мати параметри "Cash", "Check", "Debit Card"
або "Credit Card".
Дія (action) (після "/" у ярлику над переходом) – це дія, яка ініційована у
зв’язку зі зміною стану. Це може бути «надрукувати квиток», «показати на екрані»
та інші. Зазвичай дії створюють щось, що є вихідними даними системи.
Дії виникають під час переходів, самі по собі стани є пасивними.
Точка входу показується на діаграмі як чорна крапка.
Точка виходу показується на діаграмі як мішень. Повернемось до нашої

діаграми бронювання.
Зі стану "Paid" повинен бути перехід у стан "Ticketed" (квиток видали), коли квиток
надрукували та передали вам до рук. Зверніть увагу, що під час переходу в стан
"Ticketed", авіаквиток (Ticket) є вхідними даними стану.
116


Зі стану "Ticketed" ми переходимо в стан "Used" (використаний), коли віддаємо

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

завершується символом мішені.
Але ця діаграма показує ще не всі можливі стани та переходи в життєвому циклі

бронювання. Почнемо доповнення.
Якщо бронювання не оплачене до кінця завершення часу таймера, воно

відмічається як неоплачене.
116
    

 
Інколи клієнти скасовують замовлення зі стану "Made". На такий випадок нам

потрібен ще один стан "Cancelled By Customer".
Також клієнт може скасувати бронювання на стані "Paid". У такому випадку стан
також стає "Cancelled By Customer" і вартість квитка повертається клієнту.
117

Скасувати бронювання можна під час стану"Ticketed". У цьому випадку стан

знову стає "Cancelled By Customer" і авіакомпанія повертає вартість квитка
клієнту. Але! Компанія повертає вартість квитка тільки тоді, коли клієнт повертає
квиток. Цей випадок демонструє ще один не описаний елемент діаграм –
квадратні дужки " [ ] ", які зображують умови для переходу. Перехід до іншого
стану відбудеться тільки якщо умова (в "[]")= true.
118
State-Transition Diagrams можна легко використовувати для створення тест

кейсів. Необхідно створити набір тест-кейсів, який повинен пройти шляхом усіх
переходів хоча б один раз.
1. 5. Варіанти використання (Use Cases) – це техніка, яка допомагає нам

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

актором (користувачем системи). Кожний Use Case описує взаємодію актора з
системою для досягнення конкретного завдання. У ролі актора виступають, як
правило, люди, але так само ними можуть бути й інші системи. Use Cases є
послідовністю кроків, які описують взаємодію між актором та системою.
Варіанти використання визначаються з точки зору актора, а не системи, і

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


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

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

вигляді варіантів використання.
Кроки Опис дій

(Steps) (Description)
1 А: Забронювати квиток
S: Білет резервується у системі та бронювання

2
переходить у стан «Made»
Головний
успішний сценарій 3 A: Оплатити квиток
(Main Success Scenario)
A: Actor
S: System 4 S: Система переводить квиток у стан «Paid»
5 A: Роздрукувати квиток
6 S: Система переводить квиток у стан «Ticketed»
7 S: Система переводить квиток у стан «Used»
Час на таймері закінчився, квиток не оплачений

2а S: Резервація скасовується і переходить у стан
«Cancelled NonPay»
A: Користувач скасовує бронювання
2b S: Бронювання скасовується і переходить у стан
«Cancelled by Customer»
Розширення S: Бронювання скасовується і переходить у стан
(Extensions) 4а
«Cancelled by Customer», оплачені кошти
повертаються користувачеві

S: Бронювання скасовується і переходить у стан
6а «Cancelled by Customer»,
оплачені кошти повертаються користувачеві після
повернення квитка(імітація даної дії у системі)
120

1. 6. Причина / Наслідок (Cause/E ect - CE).

Це, як правило, введення комбінацій умов (причин) для отримання відповіді від
системи (Наслідок). Наприклад, ви перевіряєте можливість додавати клієнта,
використовуючи певну екранну форму. Для цього вам необхідно буде ввести
декілька полів, таких як «Ім’я», «Адреса», «Номер телефону», а потім натиснути
кнопку «Додати» - «Наслідок». Після натискання кнопки «Додати», система додає
клієнта до бази даних і показує його номер на екрані – це «Наслідок».
2. ТЕХНІКИ, ЯКІ БАЗУЮТЬСЯ НА ДОСВІДІ (EXPERIENCE-BASED TECHNIQUES)
2. 1. Припущення помилок (Error guessing)

«Вгадування помилок» - проста неструктурована техніка, яка базується на інтуїції та
досвіді, який отримали під час тестування схожих додатків. Застосовується для
визначення та проведення тестів, які складно було б організувати за умов більш
формального та структурованого підходу.
Основний мінус Error guessing – це негарантована ефективність, оскільки результат

повністю залежить від досвіду конкретного тестувальника.
У якості покращення результативності Error guessing використовуються наступні

підходи:
• визначення областей тестування, на основі досвіду/думки кількох досвідчених
тестерів
• тести базуються на списках дефектів, існування яких припускається.
Аналізується область у якій є дефекти, і тестування здійснюється довкола цієї
«слабкої» області.
2. 2. Дослідницьке тестування (Exploratory testing)

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

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

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

забезпечення, його використання, його сильні та слабкі сторони.
121
 

ff

 
 
 


1. Яка різниця між статичним та динамічним тестуванням?

2. Які розрізняють види Review у статичному тестуванні?
3. Перерахуйте види технік динамічного тестування.
4. Яка техніка динамічного тестування доповнює техніку
«Класи еквівалентності»?
5. Що таке Статичний аналіз?
6. Яка різниця між технікою тестування Error Guessing і Exploratory Testing?
7. На якому рівні тестування зручно використовувати техніку
State Transition?
122


8. ПОНЯТТЯ ДЕФЕКТУ
Заняття 8. ПОНЯТТЯ ДЕФЕКТУ

1. ЩО ТАКЕ ДЕФЕКТ?
2. ДЕТАЛЬНИЙ ОГЛЯД ЗВІТУ ПРО ДЕФЕКТ
3. ЖИТТЄВИЙ ЦИКЛ ДЕФЕКТУ
1. ЩО ТАКЕ ДЕФЕКТ?
Помилками (дефектами) у програмному забезпеченні є всі можливі невідповідності
між характеристиками його якості, які демонструються, та сформованими або
передбачуваними вимогами користувачів.
Визначення дефекту та причини його виникнення були розглянуті в першому

модулі. Нижче ми розглянемо поняття дефекту більш детально.
КЛАСИФІКАЦІЯ ДЕФЕКТІВ
Функціональні дефекти (Functional defects) розподіляються на наступні
підкатегорії:
• Специфікація (Specification) – в документі з вимогами можлива помилка.

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

тест даних, тест дизайні та іншій документації, яка пов’язана з тестуванням.
• Системні дефекти (System defects) розподіляються на наступні підкатегорії:

• Внутрішні Інтерфейси (Internal Interfaces) – існують помилки внутрішньої
інтеграції компонентів системи.
• Апаратна частина (Hardware Devices) – помилки апаратної частини системи.

• Операційна система (Operating System) – помилки операційної системи як
зовнішньої частини додатку, який тестується.
• Архітектура ПЗ (Software Architecture) – деякі фундаментальні концепції

архітектури є некоректними, наприклад, переміщення даних з однієї таблиці
в іншу.
123


Дефекти, пов’язані з процесом (Process defects) розподіляються на наступні

підкатегорії:
• Арифметика (Arithmetic) – програмне забезпечення здійснює математичні

підрахунки некоректно. Мається на увазі не тільки проста математика, але й
чисельний аналіз та проблеми, які виникають з округленням та точністю.
• Ініціалізація (Initialization) – проблеми виникають на початку використання

додатку, наприклад, відсутні дані у списку під час завантаження додатку.
• Послідовність (Sequence) – дія відбувається не в той час, наприклад, вікна

з’являються або поля розміщуються в неправильному порядку.
• Статична логіка (Static Logic) – не вказані межі значень, еквівалентні класи не

містять правильні дані та не виключають некоректні дані (функціональність, яка
обробляє такі помилки, має назву валідатор «validator»).
Дефекти, які пов’язані з даними (Data defects) – використовуються некоректні

влаштовані в систему дані або дані, які визначає користувач.
Дефекті, які пов’язані зі стандартами (Standards defects) – до цього розділу

відносяться помилки, які пов’язані з невідповідністю стандартів держави або
замовника, конвенціями правильного написання коду.
Дефекти інтерфейсу користувача (User Interface defects).
2. ДЕТАЛЬНИЙ ОГЛЯД ЗВІТУ ПРО ДЕФЕКТ

Інструмент управління дефектами (Defect Management Tool, Bug or Issue
Tracker Tool, Bug Tracking System) – інструмент, який забезпечує фіксування
дефектів та їх змін, а також підтримку їх станів.
Крім стандартної функціональності, хороший інструмент управління дефектами

повинен мати можливості: пошуку за критеріями, зберігати історію змін, гнучкого
налаштування нотифікацій (повідомлень).
Хороший звіт про дефект повинен відповідати на наступні питання:
Де?
У якому місці інтерфейсу користувача або архітектури програмного продукту
знаходиться проблема.
124
 


Що?
Що відбувається або не відбувається згідно специфікації або за вашим
уявленням про нормальну роботу програмного продукту. При цьому вказуйте
на наявність або відсутність об’єкту проблеми, а не на його виявлення (його
вказують в описі). Якщо зміст проблеми варіюється, всі відомі варіанти
вказуються в описі.
Коли?
В який момент роботи програмного продукту, після настання якої події чи за
яких умов з’являється проблема.
Тестувальник повинен приділяти велику кількість уваги якості звітів про дефекти,
які він створює. Чим краще він написаний, тим менша ймовірність відхилення
дефекту або неправильного трактування дефекту іншими учасниками проєкту.
Метою написання звіту про дефект є виправлення дефекту, тому немає сенсу
створювати звіти заради звітів.
Розглянемо основні атрибути гарного звіту про дефект:
• Назва проєкту (Project) – офіційна назва проєкту.

• Унікальний номер звіту (ID) – ідентифікатор звіту про дефект.
• Дата створення (Created Date) – дата створення звіту.
• Дата оновлення (Update Date) – дата оновлення (зміна, закриття).
• Короткий опис (Summary, Title, Subject) – заголовок звіту. Потрібно стисло
та по суті передати інформацію про проблему. Характеристика гарного
заголовка – якщо прочитати лише заголовок, можна зрозуміти суть
помилки.
• Поточний статус (Status) – стан інциденту (звіту про помилку). Набір статусів
залежить від обраного процесу розробки. Наприклад: New, In Progress,
Closed, Deferred, Failed Retest, Fixed, Rejected, Reopen, Retest.
• Резолюція (Resolution) – пояснення до статусу. Наприклад, дефект може

бути закритий, але причини закриття можуть бути різними: виправлений,
відкладений, відхилений. Набір резолюцій залежить від обраного процесу
розробки. Наприклад: Code Change, Con guration, Deployment Issue,
Documentation, Test Data Issue, User Error, Duplicate, Not a Bug.
125
 
 

fi


Що?
Що відбувається або не відбувається згідно специфікації або за вашим
уявленням про нормальну роботу програмного продукту. При цьому вказуйте
на наявність або відсутність об’єкту проблеми, а не на його виявлення (його
вказують в описі). Якщо зміст проблеми варіюється, всі відомі варіанти
вказуються в описі.
Коли?
В який момент роботи програмного продукту, після настання якої події чи за
яких умов з’являється проблема.
Тестувальник повинен приділяти велику кількість уваги якості звітів про дефекти,
які він створює. Чим краще він написаний, тим менша ймовірність відхилення
дефекту або неправильного трактування дефекту іншими учасниками проєкту.
Метою написання звіту про дефект є виправлення дефекту, тому немає сенсу
створювати звіти заради звітів.
РОЗГЛЯНЕМО ОСНОВНІ АТРИБУТИ ГАРНОГО ЗВІТУ ПРО ДЕФЕКТ:
• Назва проєкту (Project) – офіційна назва проєкту.

• Унікальний номер звіту (ID) – ідентифікатор звіту про дефект.
• Дата створення (Created Date) – дата створення звіту.
• Дата оновлення (Update Date) – дата оновлення (зміна, закриття).
Короткий опис (Summary, Title, Subject) – заголовок звіту. Потрібно стисло
та по суті передати інформацію про проблему. Характеристика гарного
заголовка – якщо прочитати лише заголовок, можна зрозуміти суть
помилки.
Поточний статус (Status) – стан інциденту (звіту про помилку). Набір статусів
залежить від обраного процесу розробки. Наприклад: New, In Progress,
Closed, Deferred, Failed Retest, Fixed, Rejected, Reopen, Retest.
Резолюція (Resolution) – пояснення до статусу. Наприклад, дефект може

бути закритий, але причини закриття можуть бути різними: виправлений,
відкладений, відхилений. Набір резолюцій залежить від обраного процесу
розробки. Наприклад: Code Change, Con guration, Deployment Issue,
Documentation, Test Data Issue, User Error, Duplicate, Not a Bug.
126
 
 

fi


Пріоритет (Priority) – властивість, яка вказує на послідовність виконання

завдання або усунення дефекту. Чим вищим є пріоритет сутності, тим швидше
треба приступити до її реалізації. Набір пріоритетів залежить від обраного
процесу розробки. Базовий набір пріоритетів: High, Major, Medium, Low.
Пріоритет може виставлятися тестувальником, але так само може
редагуватися менеджером проєкту.
• High (критичний пріоритет) – критична помилка для проєкту, повинна

бути виправлена в найкоротші терміни.
• Major (високий пріоритет) – виправлення помилки є обов’язковим.

• Medium (середній пріоритет) – бажано виправити помилки до моменту
поставки додатку користувачам. Не потребує термінового вирішення.
• Low (незначний пріоритет) – незначна помилка, виправити потрібно за

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

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

дефектів залежить від обраного процесу розробки та від домовленостей між
учасниками проєкту. Базовий набір: Critical, Major, Medium, Minor.
• Critical (критична або блокуюча серйозність) – дефект, який блокує

подальшу можливість використання/тестування додатку. Неправильно
працююча бізнес-логіка високо пріоритетного функціоналу. Втрата даних.
Приклад – відсутність будь-яких можливостей через помилки в системі
створити основну бізнес сутність додатку.
• Major (значна серйозність) – дефект зачіпає високо пріоритетний

функціонал. Помилка не блокує роботу додатку. Приклад – неможливо
створити основну сутність додатку через допоміжну форму додавання,
через основну форму створення сутності – можливо.
• Medium (середня серйозність) – помилки в низько пріоритетних частинах

функціоналу, які не призводять до будь-яких ризиків. Приклад – не
працює пошук на одній зі сторінок додатку.
• Minor (незначна серйозність) – незначна помилка, яка не впливає на

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


• Компонент (и) (Component – область об’єкту тестування, до якої

відноситься інцидент.
• Версія додатку, для якої інцидент є актуальним (A ects Version) – версія

додатку, у якій знайшли інцидент. І версії, на яких інцидент відтворюється.
Важливо розуміти, що якщо ми знаходимо дефект у пізніх версіях додатку,
то, можливо, він відтворюється також на більш ранніх версіях. Для десктоп
додатків важливо знати всі версії, де дефект відтворюється. Іноді детальне
відображення усіх версій, у яких відображається дефект, є необхідним для
збору метрик. На більшості веб-проєктів достатньо вказувати тільки версію,
у якій знайшли інцидент.
• Версія додатку, для якої інцидент було закрито (Fix Version) – версія
додатку, у якому інцидент було закрито.
• Автор звіту (Reporter) – ім’я людини, яка створила звіт. Автором звіту не
обов’язково повинен бути спеціаліст з тестування, ним може бути будь-який
учасник проєкту або навіть користувачі.
• На кого призначено звіт (Assignee) – ім’я співробітника, на якого

призначено вирішення завдання.
• Оточення (Environment) – оточення, у якому знайдено дефект – операційна

система, браузер, сервер і т. п. Якщо дефект відтворюється на усіх
середовищах, то ставиться відповідний коментар.
• Опис / Кроки відтворення (Description) – інформація, яка необхідна для

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

відтворити ситуацію – скріншоти, відео.
Усі з вищеперерахованих полів заповнюються автором звіту.

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

ff
 
3. ЖИТТЄВИЙ ЦИКЛ ДЕФЕКТУ

Як правило, для моніторингу дефектів та роботи з ними використовуються системи
відслідковування помилок (Bug Tracking Systems).
Життєвий цикл» дефекту (Defect life cycle) – це, як правило, набір статусів, у
яких може знаходитись дефект у системі відслідковування помилок, від
початкової стадії його виявлення у системі і до стадії виправлення, закриття.
Рис. 8.1. Життєвий цикл дефекту (Defect life cycle)
Тепер переходимо до опису даної схеми.
Припустимо, ви знайшли дефект та зареєстрували його в баг трекінговій системі.

Відповідно до нашої схеми, він отримає статус «Новий» (New). Тестувальник, який
відкрив звіт про дефект, повинен призначити його на Менеджера проєкта або
безпосередньо на розробника, який відповідає за ту область, де знайшли дефект
(все залежить від процесу на проєкті).
129

 
У ситуації, якщо дефект не буде виправлятися в даному релізі, менеджер проєкта

переводить його в статус «Відкладений» (Deferred).
Якщо дефект необхідно виправити, менеджер або розробник переводять його в

статус «У процесі» (In Progress). Цей статус говорить про те, що розробник працює
над даним дефектом.
Якщо у процесі дослідження дефекту з’ясувалось, що причиною його виникнення є

помилка в коді розробника, він повинен зробити коригування коду, і як тільки
дефект буде виправлений, перевести його в статус «Виправлений» (Fixed).
Якщо у процесі дослідження дефекту з’ясувалось, що причиною його появи є

помилка тестових даних, неправильне розуміння користувача або звіт на такий
дефект уже створений, то дефект переходить в статус «Відхилений» (Rejected) і
розробник призначає його на тестувальника. Після цього тестувальник повинен ще
раз перевірити даний дефект і якщо розробник правий, тобто дефекта справді
немає, то звіт переходить в статус «Закритий» (Closed), якщо проблема дійсно існує
і даний ефект необхідно виправити, тестувальник ще раз відкриває його та
призначає на розробника, звіт переходить в статус «Перевідкритий» (Reopened).
Повернемось до статусу «Виправлений» (Fixed). Коли версія додатку, яка містить

виправлення, доступна для тестування, розробник переводить дефект у статус
«Перетестувати» (Re-Test) і призначає його на тестувальника. Якщо дефект був
виправлений та фактичний результат співпадає з очікуваннями, то дефект може бути
переведений у статус «Закритий» (Closed), якщо дефект досі існує, то звіт необхідно
перевести в статус «Невдалий повторний тест» (Failed Re-Test) і призначити його
на розробника.
Звіт про дефект, який знаходиться в статусі «Відкладений» (Deferred) може

розглядатися не тільки в наступній версії продукту, але і в поточній. Все залежить від
потреб проєкта та бажання замовника. Звіт зі статусом «Відкладений» (Deferred)
може бути переведений в статус «Перетестувати» (Re- Test), для визначення
поточного стану дефекту.
Повернемось до статусу «Закритий» (Closed). Якщо даний дефект з’явився у

системі знову, тестувальник може відкрити його ще раз та перевести його в статус
«Перевідкритий» (Reopened) і відповідно призначити його на розробника.
І, нарешті, останній нюанс, це помилки, які пов’язані зі специфікацією на продукт.

Якщо в процесі дослідження дефекту з’ясувалось, що помилка в специфікації, то
звіт призначають на Бізнес аналітика з наступним виправленням специфікації. Якщо
дані зміни потребують змін коду, то дефект призначають на розробника, якщо не
потребують – на тестувальника зі зміною статусу дефекту на «Перетестувати» (Re-Test).
130

 
1. Що таке дефект?
2. Які класифікують типи дефектів?
3. Опишіть життєвий цикл дефекту.
4. Назвіть основні поля/атрибути звіту про дефект.
5. Яка різниця між Priority і Severity у контексті поняття дефекту?
Інструменти для збору тестових доказів

(Test Evidence)
https://www.youtube.com/watch?v=4CBBWV6ldcs Scan and watch
Compare Tools
https://www.youtube.com/watch?v=x6UgrU4FrUs Scan and watch
Як правильно писати звіти про дефекти

англійською мовою
https://www.youtube.com/watch?v=UEY5hGNPSvA Scan and watch
131

 
Модуль IV.
ЗАВЕРШЕННЯ ПРОЦЕСУ ТЕСТУВАННЯ
ТА ЗВІТНІСТЬ
Заняття 11.
ФІНАЛЬНІ ДІЇ У ПРОЦЕСІ ТЕСТУВАННЯ
1. ЗАВЕРШЕННЯ ПРОЦЕСУ ТЕСТУВАННЯ
2. ДЕТАЛЬНИЙ ОГЛЯД ЗВІТНИХ ДОКУМЕНТІВ
1. ЗАВЕРШЕННЯ ПРОЦЕСУ ТЕСТУВАННЯ

Результати завершення процесу тестування повинні бути відображені в документі,
який має назву Зведений звіт про закінчення тестування (Test Summary Report).
Даний звіт може бути створений тільки після того, як усі тести були виконані та
вихідні критерії були досягнуті. Також, якщо команда працює за методологією
Scrum, необхідно провести Demo для замовника, і тільки після його проведення
може бути складений Зведений звіт про закінчення тестування. Головна мета Test
Summary Report це документування усіх результатів процесу тестування та надання
інформації усім учасникам та зацікавленим особам проєкту таким як: Project
Manager, Test Manager, Business Analyst та інші.
Зведений звіт про закінчення тестування може містити наступну інформацію:
• Ідентифікатор звіту.
• Назва додатку, який тестується, та його версія (можливо вказувати декілька
версій, які використовувались під час тестування).
• Опис підходу, методології або видів тестування, які застосовувались.

• Опис тих функціональних одиниць, які тестувалися (Test Coverage) і їх статус.
• Перелік усіх знайдених дефектів під час даного тестування та їх статуси.
• Заключний висновок про результати тестування.
• Затвердження (Approvals) від керівних учасників проєкту.
132

 
Mодуль IV. ЗАВЕРШЕННЯ ПРОЦЕСУТЕСТУВАННЯ ТА ЗВІТНІСТЬ
9. ФІНАЛЬНІ ДІЇ У ПРОЦЕСІ ТЕСТУВАННЯ
Усі вищеперераховані атрибути звіту про закінчення тестування можуть

розрізнятися/бути наявними/відсутніми на різноманітних проєктах або бути
представлені в різному вигляді.
Завершальні дії щодо закриття процесу тестування (Test Closure Activities)

відбуваються після того, як реліз продукту був випущений та переданий замовнику.
Це саме той час, коли потрібно зробити кінцеву звітність, документування та
архівацію тестового середовища, тестової документації та даних. Ці завершальні дії,
як правило, не фінансуються і не отримують достатньо уваги, тому що починаються
активності, які пов’язані з релізом/проєктом.
Недостатня кількість часу, яка витрачена на фінальні дії, так само зменшує
ймовірність того, що набутий вже досвід і знання будуть використані в повному
обсязі для поліпшення процесу.
2. ДЕТАЛЬНИЙ ОГЛЯД ЗВІТНИХ ДОКУМЕНТІВ

Крім зведеного звіту про завершення тестування (Test Summary Report), існують
також інші типи звітів, які використовуються тестувальниками в процесі тестування.
Тому розглянемо наступні види звітів:
• Щоденний звіт про роботу (Daily Progress Report) – містить інформацію про
роботу, яка була зроблена, а точніше про виконання тестів тестувальником або
командою протягом дня.
• Щотижневий звіт про роботу (Weekly Progress Report) – містить інформацію

про роботу, яка була зроблена тестувальником або командою протягом тижня.
• Підготовчий звіт про тестування (Test Preparation Report) – містить інформацію

про зроблену роботу, яка пов’язана з підготовкою та створенням тестів.
1. Що описує Test Summary Report?

2. Які розрізняють види звітної тестової документації?
3. Назвіть основні атрибути Test Summary Report.
133


10. КОНФІГУРАЦІЙНИЙ МЕНЕДЖМЕНТ, РИЗИКИ ТА МЕТРИКИ ТЕСТУВАННЯ
Заняття 12. КОНФІГУРАЦІЙНИЙ МЕНЕДЖМЕНТ,

РИЗИКИ ТА МЕТРИКИ ПРОЦЕСУ ТЕСТУВАННЯ
1. КОНФІГУРАЦІЙНИЙ МЕНЕДЖМЕНТ
2. МЕТРИКИ ТЕСТУВАННЯ
3. РИЗИКИ У ТЕСТУВАННІ
1. КОНФІГУРАЦІЙНИЙ МЕНЕДЖМЕНТ
Зазвичай розробка програмного забезпечення не відбувається без використання
якоїсь системи контролю версій. Даний підхід може застосовуватися або не
застосовуватися на окремих проєктах. Це залежить від специфіки системи, яка
розробляється, а також багатьох інших факторів, головними з яких є наявність
необхідних навичок та ресурсів, а також необхідність забезпечення якості системи,
яка розробляється.
Існує окрема дисципліна інженерії програмного забезпечення, яка займається

подібними організаційними завданнями без прив’язки до методології – це
конфігураційний менеджмент (configuration management).
Конфігураційний менеджмент або управління конфігураціями (англ. Software

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

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

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

 
 
У зв’язку з високою динамічністю розробки програмного забезпечення, у ній

конфігураційне управління особливо корисне. До процедур можна віднести
створення резервних копій, контроль вихідного коду, вимог проєкту,
документації і т. д. Ступінь формальності виконання даних процедур залежить від
розмірів проєкту, за умов правильної її оцінки ця концепція може бути дуже
корисною.
Цілі конфігураційного менеджменту:
• Контроль: дозволяє відстежувати зміни в контрольованих об’єктах,

забезпечує дотримання процесу розробки
• Управління: диктує процес автоматичної ідентифікації у процесі всього

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

• Управління зборкою
• Управління оточенням
• Відстеження завдань та проблем
Частиною конфігураційного менеджменту є процес управління версіями.
Система контролю версій (від англ. Version Control System) — програмне

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

Такі системи найбільш широко використовуються під час розробки програмного

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

вимірювання.
2. МЕТРИКИ ТЕСТУВАННЯ
Введення та використання метрик необхідне для контролю над процесом

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

процесу тестування. Необхідну для контролю інформацію збирають (як вручну,
так і автоматично) та використовують для оцінки стану та прийняття рішень, таких
як покриття (наприклад, покриття вимог або коду тестами) або критерії виходу
(наприклад, критерії завершення тестування). Метрики також можуть бути
використані для оцінки прогресу виконання запланованих робіт.
Розглянемо наступні метрики тестування:
МЕТРИКИ ТЕСТ КЕЙСІВ
Метрика показує результати проходження тест кейсів, а

Passed/Failed саме відношення кількості вдало пройдених до
Test Cases пройдених з помилками. В ідеалі, до кінця проєкту
кількість провалених тестів зводиться до нуля.
Метрика показує кількість тест кейсів, які необхідно

ще виконати в даній фазі тестування. Маючи цю
Not Run Test Cases інформацію, ми можемо проаналізувати та виявити
причини, через які тести не були проведені.
136


МЕТРИКИ ДЕФЕКТІВ
Open/Closed Метрика показує відношення кількості відкритих багів

Defects до закритих (виправлених та повторно перевірених)
Метрика показує відношення кількості перевідкритих

Reopened/Closed
багів до закритих (виправлених та повторно
Defects
перевірених)
Rejected/Opened Метрика показує відношення кількості відхилених

Defects багів до відкритих
Defects by Severity Кількість багів за серйозністю
Defects by Priority Кількість багів за пріоритетом
Метрики "Open/Closed Bugs", "Bugs by Severity" і "Bugs by Priority" добре

візуалізують ступінь наближення продукту до досягнення критеріїв якості щодо
дефектів. Маючи вимоги до кількості відкритих багів, після кожної ітерації
тестування ми порівнюємо їх з реальними даними, тим самим бачимо, де нам
потрібно додати, аби скоріше досягнути мети.
Метрики "Reopened/Closed Bugs" і "Rejected/Opened Bugs" спрямовані на

відстеження роботи окремих учасників групи розробки та тестування.
💡 Приклад 1
Припустимо, ми маємо ситуацію, коли кількість повторно відкритих після
виправлення дефектів не зменшується або навіть збільшується. Це сигнал тощо,
що необхідно провести аналіз причин, оскільки схожа ситуація може показати,
що:
• вимоги до функціоналу можна трактувати по-різному
• тестувальник не точно описав проблему
• неякісне поверхневе вирішення проблеми (виправлення дефекту)
137
 
 

 
💡 Приклад 2
Цей приклад продемонструє, для чого необхідна метрика "Rejected/Opened Bugs":
Ми спостерігаємо, що процент відхилених (Rejected) багів дуже великий. Це може
означати:
• вимоги до функціоналу можна трактувати по-різному
• тестувальник не точно описав проблему
• розробник не бажає виправляти допущену помилку або не вважає це
помилкою.
МЕТРИКИ ЗАВДАНЬ
Deployment tasks Метрика показує кількість реалізованих завдань
Метрика показує кількість все ще відкритих завдань.

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

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

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

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

Вартість тестування дефектів та придбання спеціальних інструментальних
засобів для проведення тестування.
Тестове покриття являє собою відношення

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

тестування: використовується метрика, яка базується на
відношенні кількості дефектів, які знайдені на етапі
= ∗ 100 тестування, до загальної кількості дефектів, які
+
знайдені на етапі тестування та експлуатації.
де , – дефекти,
які виявлені на етапі
тестування та експлуатації
відповідно
3. РИЗИКИ В ТЕСТУВАННІ
Ризик — ймовірність виникнення подій, небезпеки, загрози або ситуації, яка

відтворюється в небажаних наслідках або потенційній проблемі. Рівень ризику
визначається ймовірністю виникнення небезпечної події та її впливу (шкода, яка
з’являється в результаті цієї події).
Ризики в тестуванні поділяються на проєктні та продуктові.
Ризики проєкту
Ризики проєкту – це ризики, які впливають на здатність проєкту досягнути його
цілей, та містять:
Організаційні фактори:
• Нестачу кваліфікації, підготовки та співробітників;
• Особисті проблеми співробітників;
• Політичні проблеми, такі як:
139
𝑁
𝐸
𝑡
𝑁
𝑁
𝑡
𝑡
𝑁
𝑁
𝑒
𝑒

 
 


✓ Тестувальники в недостатній мірі повідомляють про свої проблеми та

результати тестування;
✓ Нездатність дотримуватися інформації, отриманої під час тестування або
рецензування (наприклад, не покращувати практики розробки або
тестування);
✓ Неправильне ставлення до тестування або помилкові очікування
(наприклад, не брати до уваги значення знайдених під час тестування
дефектів);Політичні проблеми, такі як:
Технічні проблеми:
• Проблеми у визначенні правильних вимог;
• Вчасно не готове тестове середовище;
• Пізнє перетворення даних, планування міграції та розробки тестових даних
та засобів перетворення/міграції тестових даних;
• Низька якість проєктування, коду, конфігураційних та тестових даних та
тестів;
Проблема постачальника:
• Відмова третьої сторони;
• Проблеми контракту.
Під час аналізу, управління та зменшенні цих ризиків тест менеджер повинен
слідувати добре обґрунтованим принципам управління проєктом.
Ризики продукту
Ризики продукту – це потенційні області збою (неблагонадійні майбутні події або
небезпека) у ПЗ або системі, оскільки вони ризикують якістю продукту,
наприклад:
• Поставка потенційно ненадійного ПЗ;
• Ймовірність того, що програмне/апаратне забезпечення може нашкодити
людині або компанії;
• Погані характеристики ПЗ (наприклад, функціональність, надійність,
зручність використання або продуктивність);
• Неповнота та низька якість даних (наприклад, проблеми міграції,
перетворення та переміщення даних, відхилення від стандарту даних); ПЗ,
яке не виконує передбачених функцій.
140
 

 
Ризики використовуються для визначення того, де починати тестування та яким

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

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

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

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

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

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


• оцінка/переоцінка (вимірювання) ризиків;

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

2. Назвіть види систем контролю версій.
3. Які розрізняють види метрик у тестуванні?
4. Назвіть основні види ризиків у тестуванні.
Навіщо потрібен GIT?

https://www.youtube.com/watch?
v=oKyzv8nzT28&list=PLRs8EELOYKc44Y_fKFvADdPXbrYZDQqr0&index=2 Scan and watch
Тестування верстки
https://www.youtube.com/watch?v=GfPmWGU0vI0 Scan and watch
142

IT GLOSSARY
IT GLOSSARY
Item Description
Approve підтвердження відповідальним співробітником певного питання,
документа, процедури і т.д. У тестуванні це може бути апрув кейсів
бізнес-аналітиком
Authentication процедура перевірки автентичності, наприклад, ідентифікація
користувача шляхом порівняння введеного ним пароля з паролем,
який збережений у базі даних користувачів
Authorization надання певній особі чи групі осіб прав на виконання певних дій; а
також процес перевірки (підтвердження) даних прав під час спроби
виконання цих дій
BackUp процес створення резервної копії продукту, програми і т.д.
Build готовий для тестування програмний продукт
Checkout вилучення існуючої версії коду для роботи з нею локально (приклад:
прийшов новий розробник у команду)
Commit внесення змін у спільний бранч проєкту (гілку коду), для того, щоб у
майбутньому цей код був протестований
Compare порівняння даних, коду і т. д. з метою визначення різниці
Compile перетворення програмного коду в машинно-орієнтовану мову
Deadline дата, до якої певні активності повинні бути завершені
Debug відтворення крок за кроком дій для того, щоб перевірити, що
повертає функція, ділянки коду (і в цілому розібратися, як працює код)
Demo демонстрація замовнику, менеджменту проєкту, команді, реалізованої
функціональності
Deployment процес постачання оновленої версії продукту (приклад з версії 1.0 до
1.1), який включає виправлені дефекти і/або новий функціонал
E2E виконання тестового сценарію від самого початку і до кінця (приклад:
вхід у додаток, створення звіту, редагування, експорт, вихід з додатку)
Escalate підняття певного питання на рівні вище (керівника відділу, тімліду,
проджект менеджера), використовується у випадку, якщо проблема
або питання виходять за рамки вашої компетенції
Evidence доказ того, що дії були дійсно виконані (тест кейс був протестований)
Execute виконання певної команди (наприклад, в SQL)
Feature сленгове визначення функції, програмної можливості (іншими
словами – фішка, також може застосовуватися для бага, який описує
нову поведінку ПЗ, яке немає необхідності виправляти, тому що
замовник згоден з даною поведінкою ПЗ)
Log le (logs) файл, у якому записуються дані про виконання певних дій
(використовується для визначення причин дефекту)
Merge злиття існуючого коду (гілки коду) з новою
143
fi
IT GLOSSARY
IT GLOSSARY
Item Description
латка, програмний код, який виправляє дефект ПЗ або вносить до

Patch
нього зміни
модуль, який дозволяє додати до існуючого ПЗ додаткові функції,

Plug in
розширює існуючий набір функцій
PROD (LIVE) реальне середовище використання ПЗ
запит у базі даних для створення, перегляду, зміни, видалення даних,

Query (SQL)
таблиць і т. д. (приклад: select * from User)
відхилення, повернення на доопрацювання питання, документа,
Reject
процедури і т. д.
випуск готового продукту на наступну стадію тестування,
Release
використання
артефакт, документ, який надає інформацію, прогрес у стислому
Report
вигляді за певний період
Restart перезавантаження додатку, програми, сервера
код, який дозволяє скасувати внесені зміни (зазвичай
Rollback
використовують в SQL разом з кодом, який вносить зміни)
Screenshot різновид evidence, картинка з підтвердженням дії або дефекту
фінальне підтвердження будь-чого. Для тестувальника це гарантія
Sigh o
якості продукту, який тестується
системно-інтеграційне тестування, іншими словами тестування сирого
SIT
коду на боці розробника ПЗ
завдання, зазвичай в Жирі, яка назначена на відповідального
Task
співробітника для її реалізації (нема таски в Жирі – нема роботи)))
приймальне тестування, яке виконується тестувальниками-
UAT
представниками замовника
або Refresh, оновлення даних, стану додатку, коду, до найсвіжішої,
Update
останньої версії
Work ow опис процесу, дії від початку до кінця, або окремої незалежної функції
144

fl
f
У поданій методичці Ви розглянули всю необхідну інформацію, яка

пов’язана з тестуванням програмного забезпечення. Її можна використовувати
як для підготовки до співбесідам по профілю «Тестування ПЗ», так і
безпосередньо на реальних проєктах для покращення процесу тестування.
Бажаємо професійних успіхів, нових проєктів та досягнень!
Запам’ятайте, «Дорога прокладається під ногами того, хто іде!».

Той, хто робить щось для досягнення своєї мети, рано чи пізно досягне її!
Не зупиняйтесь на шляху свого розвитку. Вдосконалюйте свої знання!
У Вас все вийде!
А ми завжди будемо пишатися Вашими результатами!
З повагою, команда найкращого навчального центру QA Start Up
145

Методичка QA START UP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Методичка QA START UP

Uploaded by

Copyright:

Available Formats

In God we trust, the rest we test…

Модуль I. ОСНОВНІ ПОНЯТТЯ В ТЕСТУВАННІ

Модуль ІІ. ПЛАНУВАННЯ ПРОЦЕСУ ТЕСТУВАННЯ

Модуль ІІІ. АНАЛІЗ, РОЗРОБКА І ВИКОНАННЯ ТЕСТІВ

Модуль IV. ЗАВЕРШЕННЯ ПРОЦЕСУ ТЕСТУВАННЯ

Незважаючи на те, що роль тестування на перший погляд може здатися не дуже

Яка б методологія розробки програмного забезпечення не використовувалась,

Завданнями сучасного тестування є не тільки виявлення помилок у програмах, але

Розуміння важливості процесу тестування призводить до виникнення тенденцій, які

Досконале тестування систем і документації може зменшити ризик виникнення

Mодуль1. ОСНОВНІ ПОНЯТТЯ В ТЕСТУВАННІ ПО

Тестування ПЗ (testing) – це процес дослідження, випробування програмного

• продемонструвати розробникам та замовникам, що програма відповідає

Також тестування – це можливий спосіб оцінки якості програмного

Mодуль1. ОСНОВНІ ПОНЯТТЯ В ТЕСТУВАННІ ПО

Тестування є складовою частиною процесу відладки програмного забезпечення

Усі вищеперераховані поняття будуть розглянуті в наступних модулях.

Якість (quality) – ступінь, з якої компонент, система або процес відповідає

Тестування оцінює якісний рівень продукту за трьома ключовими факторами:

Тестування може створити впевненість у якості програмного забезпечення за

Mодуль1. ОСНОВНІ ПОНЯТТЯ В ТЕСТУВАННІ ПО

Тест, який розроблений відповідним чином, успішно пройдений, зменшує загальний

3. ПРИЧИНИ ВИНИКНЕННЯ ДЕФЕКТІВ

Отже, питання коректної, а інколи навіть безпомилкової роботи програми стоїть

ДЕФЕКТ (DEFECT/FAULT/BUG) – вада компоненту або системи, яка може

ПОМИЛКА (ERROR/MISTAKE) – дія людини, яка призводить до неправильного

ЗБІЙ (FAILURE) – відхилення компоненту або системи від очікуваного виконання,

Складність Людський фактор: Обмежений час: Зміна

ПРИЧИНИ ВИНИКНЕННЯ ДЕФЕКТІВ (DEFECT, FAULT, BUG)

Низький рівень технологічного процесу:

Рис. 1.1. Причини виникнення дефектів

Mодуль1. ОСНОВНІ ПОНЯТТЯ В ТЕСТУВАННІ ПО

НИЗЬКИЙ РІВЕНЬ ТЕХНОЛОГІЧНОГО ПРОЦЕСУ

Відсутність контролю версій

Дефекти допоміжних інструментів

Відсутність кваліфікованого тестування

Mодуль1. ОСНОВНІ ПОНЯТТЯ В ТЕСТУВАННІ ПО

ПРИЧИНИ ВИНИКНЕННЯ ЗБОЇВ (ВІДМОВ) (FAILURES)

Наявність Недотримання умов Порушення Порушення апаратної

* виконання додатку в непідтримуваному середовищі (платформі)

Повне тестування з використанням усіх комбінацій вводів та

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

Зусилля тестування повинні бути зосереджені пропорційно до

Якщо одні й ті ж тести будуть переганятися велику кількість

Mодуль1. ОСНОВНІ ПОНЯТТЯ В ТЕСТУВАННІ ПО

Тестування виконується по-різному, залежно від контексту.

7. Омана через Виявлення та виправлення дефектів не допоможуть, якщо

5. ВИДИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

2. Веб-додаток (Web application) – додаток, у якому всі або деякі частини

* Браузерний додаток (Browser-based application) – клієнт-серверний додаток,

* Клієнтський додаток (Client-based application) – веб-додатки можуть

3. Мобільний додаток (Mobile application) – додаток являє собою комп’ютерну

4. Сервіси (Service-oriented application) – додатки, які забезпечують

Mодуль1. ОСНОВНІ ПОНЯТТЯ В ТЕСТУВАННІ ПО

Тонкий клієнт (Thin client) — комп’ютер або програма-клієнт у мережах з клієнт-

Товстий клієнт (Rich клієнт) в архітектурі клієнт-серверу – це додаток, який

Клієнтську частину також називають Front-End,

Mодуль1. ОСНОВНІ ПОНЯТТЯ В ТЕСТУВАННІ ПО

Розрізняють декілька видів клієнт-серверних архітектур:

Рекомендуємо до перегляду відео на нашому YouTube каналі

9 якостей гарного тестувальника

Mодуль1. ОСНОВНІ ПОНЯТТЯ В ТЕСТУВАННІ ПО

Заняття 2. РОЗРОБКА ПЗ. ПРОЦЕС ТЕСТУВАННЯ.