Presentation 4

1.

Тестування програмного забезпечення: від теорії до
практичних кейсів Основні підходи, види, техніки
та реальні приклади
[Петров Ілля / 242/2 / 4 курс]

2.

Мета:
Зрозуміти, чому тестування — це не «пошук багів»,
а аналіз ризиків.
Розглянути класифікацію видів тестування з
прикладами.
Показати реальні техніки тест-дизайну (без води).
Дати практичний шаблон для написання багрепорту.
Продемонструвати популярні міфи та як їх
уникнути.

3.

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

4.

ПОМИЛКОВА ДУМКА: «Тестування гарантує, що багів немає».
Тестування може показати наявність дефектів, але не довести їх
відсутність (принцип Дейкстри). Кінцева мета — знизити ризики до
прийнятного рівня, а не «знайти всі помилки». Авторський
приклад: Якщо ви перевірили 1 000 входжень у додаток — 1001-ше
може виявитися критичним. Тестування дає ВПЕВНЕНІСТЬ, але не
АБСОЛЮТ.

5.

Ключова термінологія (для новачків)
Дефект (баг) — відхилення фактичного результату від очікуваного.
Помилка (error) — неправильна дія людини (написала код не так).
Збій (failure) — прояв дефекту під час роботи програми. Простий
ланцюжок: Людина зробила помилку в коді → отримали дефект
(баг) → програма впала → це збій. Тестувальник шукає дефекти ДО
того, як вони стали збоями для користувача.

6.

Рівні тестування (класика ISTQB)
Модульне (Unit testing) — перевіряємо один шматок коду (наприклад, функцію перевірки
пароля). Інтеграційне — як модулі спілкуються між собою (наприклад, API + база даних).
Системне — вся програма як єдине ціло (наприклад, інтернет-магазин від авторизації до
оплати). Приймальне (UAT) — чи задоволені вимоги реального замовника/користувача.
приклад: Тестування велосипеда: модульне — гальмівний тросик окремо інтеграційне —
гальма + колесо системне — вся їзда приймальне — чи подобається клієнту

7.

Види тестування за спрямованістю
(Функціональне vs Нефункціональне)
Функціональне тестування — перевіряє, ЩО робить система. Приклад: чи
надсилає кнопка "Відправити" листа? (так/ні) Нефункціональне тестування —
перевіряє, ЯК система працює. Приклад: чи надсилає та ж кнопка листа за 0.5
секунди при 1000 користувачах? Поширена помилка: ігнорувати
нефункціональні вимоги. Якщо форма працює, але завантажується 30 секунд
— функціонально ОК, але користувач піде.

8.

Приклад: як тестувати поле вводу
логіну
Завдання: поле "Логін" (має бути від 4 до 20 символів, тільки латиниця та цифри). Позитивне тестування: "ivan123",
"user_2025", "Petro_007" Негативне тестування: "Iван" (кирилиця), "u" (1 символ), "дужедовгийлогінбільше20символів"
Межові значення: 3 символи → баг (очикуємо помилку) 4 символи → ок 20 символів → ок 21 символ → помилка
Авторський коментар: Саме комбінація позитивних + негативних + межових тестів знаходить 80% багів.

9.

Техніки тест-дизайну
Класи еквівалентності — ділимо вхідні дані на групи, які система має
обробляти однаково. Приклад: вік 0-17 → знижка 0%, 18-64 → 10%, 65+ → 30%.
Тестимо по 1 значенню з кожної групи. Аналіз граничних значень —
перевіряємо межі між класами. Там помилки трапляються найчастіше
(наприклад, при 17 → все ще 0%, а має бути 10%). Попарне тестування (Pairwise)
— коли багато комбінацій, але тестувати всі неможливо. Приклад: 5
параметрів по 4 значення = 1024 комбінації, але достатньо ~20 тестів.

10.

Життєвий цикл бага
NEW (новий) → ASSIGNED (призначений) → OPEN (в роботі) → FIXED
(виправлено) → RETEST (перевірка) → CLOSED (закрито) АБО: REJECTED (не баг)
DEFERRED (відкладено) REOPENED (з'явився знову) Приклад із реального
проєкту: Баг: "Кнопка 'Купити' зникає при розмірі екрана 400x600" → NEW →
ASSIGNED розробнику → FIXED → RETEST (виявили, що тепер кнопка є, але не
клікабельна) → REOPENED → FIXED again → CLOSED.

11.

Структура ідеального багрепорту
Заголовок: [Модуль] Коротка суть (макс 10 слів) Серйозність (Severity): Blocker / Critical / Major /
Minor / Trivial Пріоритет (Priority): High / Medium / Low Кроки для відтворення: 1. Перейти на
сторінку ... 2. Ввести ... 3. Натиснути ... Фактичний результат: (що сталося) Очікуваний
результат: (що мало бути) Додатки: скріншот, лог, відео Авторська порада: Хороший багрепорт — це такий, який розробник може відтворити за 10 секунд, не запитуючи додатково.

12.

Види тестування за часом виконання
(Smoke, Sanity, Regression)
Smoke (димне) — чи "палає" система взагалі? Перевіряємо найголовніше:
логін, відкриття головної сторінки, додавання товару. Час: 5-10 хвилин. Якщо
не пройшов — далі тестувати сенсу немає. Sanity (самоперевірка) — чи працює
конкретна функція після дрібних змін? Наприклад, змінили колір кнопки —
тестимо тільки її. Regression (регресійне) — чи не зламалося те, що працювало
раніше? Запускаємо старі тести після будь-яких змін. Це найважливіше для
довгих проєктів.

13.

Автоматизація: за і проти (з
прикладами)
КОЛИ АВТОМАТИЗУВАТИ: — Регресійне тестування (багато повторів) — Навантажувальні тести
(1000+ користувачів) — Тести, які треба запускати щоночі КОЛИ НЕ ВАРТО: — Функція
змінюється кожного тижня (переписувати автотести дорожче) — Дослідницьке тестування
(людина шукає неочікувані сценарії) — Інтерфейс, який постійно перемальовують Приклад з
мого досвіду: Автотест логіна економить 30 хвилин щодня, але автотест банеру, який міняють
кожен день — це марна трата часу.

14.

Найпопулярніші інструменти
тестування (коротко)
Баг-трекери: Jira, YouTrack, Trello (для маленьких команд) Автотести: Selenium
(web), Appium (mobile), Postman (API) Навантаження: JMeter, K6 Тестменеджмент: TestRail, Zephyr (плагін для Jira) Без коду: Postman, Cypress
(частково), Katalon Studio Авторський вибір для початку: Jira + Postman +
базовий Selenium через Python.

15.

Реальний кейс: як один
баг коштував $100 000
Ситуація (вигадана, але типова для fintech): Електронний магазин. Функція
"Повернення коштів". Баг: якщо повернення робити через адмінку, то сума
віднімається двічі. Як виявили? Тестувальник застосував техніку "межові
значення": спочатку повернення 1 копійки (працювало), потім 1000 грн
(віднялось двічі). Наслідки до виправлення: некоректні повернення за 2 дні —
збитки 100 000 умовних одиниць. Висновок: Критичний баг може бути там, де
його не чекаєш (адмінка + фінанси).

16.

Поширені міфи про тестування
(руйнуємо)
Міф 1: «Тестування починається після написання коду» Правда: Тест-аналіз і
створення тест-кейсів починаються ще на етапі вимог. Міф 2: «Тестувальник
має знайти всі баги» Правда: Тестувальник оцінює ризики. Ідеально знайти всі
баги неможливо. Міф 3: «Автоматизація замінить людей» Правда:
Дослідницьке, юзабіліті, тестування вимог — суто людські задачі. Міф 4: «Якщо
тести пройшли — багів немає» Правда: Тести показують ЛИШЕ те, що ви
перевірили.

17.

Короткий чек-лист для тестування
будь-чого
Перш ніж почати тестувати (наприклад, нову форму реєстрації) — задай собі:
Який позитивний сценарій? (все добре) Які негативні сценарії? (порожнє поле,
невалідні дані) Де межі? (мін/макс довжина, спецсимволи) Що станеться при
дублюванні? (двічі натиснути "Відправити") Як поводиться при нестабільному
інтернеті? Чи зламається щось поруч? (регресія) Авторська порада: Тримай
цей чек-лист у стікерах на робочому столі.

18.

Як прокачати навички
тестувальника
Книги: - С. Канер "Тестування ПЗ" (класика) - R. Black "Foundation Level ISTQB" Курси
безкоштовно: - Prometheus: "Основи тестування ПЗ" - YouTube: канал "QAGuild" або "Danil
Testov" Практика: - Website: qainterview.com (тестові завдання) - BugBounty (HackerOne) —
шукай real баги на реальних сайтах за гроші Особиста порада: Створи тест-кейси для
улюбленого додатку на телефоні. Це найкращий старт.

19.

Висновки
Тестування — це аналіз ризиків, а не просто кліки по кнопках. Рівні
+ види + техніки — головний трикутник знань. Баг-репорт має бути
зрозумілим розробнику без додаткових питань. Не існує "ідеально
протестованого ПЗ", існує "прийнятний рівень якості". Починати
тестувати можна без глибоких технічних знань, але з логікою та
уважністю. І головне: Тестування рятує репутацію продукту, а іноді й
життя (див. medical софт).

20.

Питання та відповіді
(контакти)
Дякую за увагу! Чи є питання з теми тестування? Для зворотного
зв'язку: [Telegram @Dio_the_world1] «Хороший тестувальник не той,
хто знаходить баги, а той, хто не дає їм з’явитися у користувача.»