Testuvannia_PZ_Petrov_Illya_Ihorovych

1.

Тестування ПЗ
QA
Елементи теорії та практичні приклади
BUG
Група 242/2
Петров Ілля Ігорович
OK
Навчальна презентація
Quality
Assurance
Тестування ПЗ
01

2.

Що таке тестування програмного забезпечення?
Тестування допомагає знайти дефекти до того, як їх побачить користувач.
QA
Тестування ПЗ — процес перевірки програми,
щоб оцінити її якість, відповідність вимогам і
готовність до використання.
Вимоги
→
Перевірка
→
Головна ідея: не довести, що помилок немає, а
знайти ризики та слабкі місця.
Дефекти
→
Якість
• порівнює фактичний результат з очікуваним
• зменшує ризик помилок у релізі
• дає команді інформацію для прийняття рішень
Тестування ПЗ
02

3.

Мета та цінність тестування
Тестування економить час, гроші й репутацію продукту.
01 Зниження ризику
02 Зворотний зв’язок
03 Підтримка якості
04 Економія ресурсів
менше критичних помилок у продакшені
стабільна робота після змін
команда бачить реальний стан продукту
дефект дешевше виправити раніше
Приклад: баг у платежах краще знайти на тестовому середовищі, ніж після реальних оплат користувачів.
Тестування ПЗ
03

4.

Місце тестування у життєвому циклі розробки
QA бере участь не лише наприкінці, а протягом усього SDLC.
Вимоги
→
Дизайн
→
• на етапі вимог QA шукає неоднозначності
• під час розробки створюються автотести
• перед релізом виконується регресія
Тестування ПЗ
Розробка
→
Тестування
→
Реліз
→
Підтримка
• у Agile тестування йде в кожному спринті
• після релізу важливий моніторинг помилок
• якість — відповідальність усієї команди
04

5.

Верифікація та валідація
Два близькі поняття, але різні питання.
Верифікація
«Чи правильно ми створюємо продукт?»
Перевірка відповідності документації, вимогам,
дизайну, стандартам коду.
Приклад: рев’ю вимог і коду до запуску програми.
DOC
Тестування ПЗ
Валідація
«Чи той продукт ми створили?»
Перевірка, чи продукт справді вирішує потребу
користувача.
Приклад: тестування форми реєстрації реальним
сценарієм користувача.
USER
05

6.

Рівні тестування
Від маленької функції до всієї системи.
Unit
→
окремі функції або класи
Integration
→
взаємодія модулів
System
→
система цілком
Acceptance
→
прийняття замовником/користувачем
Приклад: для інтернет-магазину перевіряють функцію розрахунку ціни, зв’язок з оплатою, весь процес покупки і
приймання бізнесом.
Тестування ПЗ
06

7.

Види тестування: функціональне й нефункціональне
Що система робить і наскільки добре вона це робить.
Функціональне тестування
Нефункціональне тестування
Перевіряє функції продукту: логін, пошук, оплата,
збереження даних.
Перевіряє швидкість, безпеку, зручність,
стабільність, сумісність.
Питання: чи працює потрібна можливість?
Питання: наскільки якісно це працює?
Login
Speed
Тестування ПЗ
Search
Security
07

8.

Ручне та автоматизоване тестування
Обидва підходи потрібні, але для різних задач.
Ручне тестування
Автоматизоване тестування
QA вручну проходить сценарії, досліджує продукт,
перевіряє UX.
Скрипти самі перевіряють стабільні сценарії після
змін.
Добре для нового функціоналу, exploratory testing,
візуальної перевірки.
Добре для регресії, API, unit та повторюваних
перевірок.
MAN
Тестування ПЗ
AUTO
08

9.

Тест-кейс, чекліст і тест-план
Документація робить перевірку зрозумілою та повторюваною.
Тест-план
Чекліст
Тест-кейс
Що, коли, хто і як тестує. Описує
підхід, ресурси, ризики.
Короткий список перевірок без
детальних кроків.
Детальний сценарій: передумови,
кроки, очікуваний результат.
Приклад тест-кейсу: Реєстрація користувача
1. Відкрити форму реєстрації
2. Ввести валідний email і пароль
3. Натиснути «Створити акаунт»
Очікувано: акаунт створено, користувач бачить головну сторінку
Тестування ПЗ
09

10.

Життєвий цикл дефекту
Баг проходить шлях від знаходження до закриття.
New
→
Assigned
→
In Progress
• дефект має опис, кроки відтворення та фактичний
результат
• важливі поля: severity, priority, environment
• після виправлення QA робить retest
Тестування ПЗ
→
Fixed
→
Retest
→
Closed
Bug: Не працює кнопка «Оплатити»
Steps: додати товар → перейти в кошик → натиснути кнопку
Actual: кнопка не реагує
Expected: відкривається сторінка оплати
10

11.

Black-box, white-box та gray-box підходи
Різниця — у доступі до внутрішньої логіки системи.
B
W
G
Black-box
White-box
Gray-box
тестуємо поведінку без
знання коду
аналізуємо код, гілки, умови,
покриття
маємо часткове знання
архітектури або БД
Приклад: при black-box перевіряємо тільки форму логіну; при white-box дивимось, які умови в коді обробляють
помилки; при gray-box можемо додатково перевірити запис у базі даних.
Тестування ПЗ
11

12.

Техніки тест-дизайну
Вони допомагають вибрати мінімум тестів з максимумом користі.
Класи еквівалентності
Ділимо дані на групи, де система має поводитись
однаково.
Граничні значення
Перевіряємо межі: мінімум, максимум і сусідні
значення.
Таблиці рішень
Зручно для правил із кількома умовами.
Попарне тестування
Комбінуємо параметри, не перевіряючи всі варіанти.
Приклад межі віку: дозволено 18–60 → тестуємо 17, 18, 19, 59, 60, 61
Тестування ПЗ
12

13.

Приклад unit-тестування
Unit-тести перевіряють маленькі частини програми ізольовано.
• швидко запускаються
• добре показують помилку в конкретній функції
• часто пишуться розробниками
function sum(a, b) { return a + b; }
test("adds numbers", () => {
expect(sum(2, 3)).toBe(5);
});
Ідея: якщо після зміни коду функція sum(2, 3) поверне не 5, тест одразу покаже проблему.
Тестування ПЗ
13

14.

Приклад інтеграційного тестування
Перевіряємо, чи модулі правильно працюють разом.
Frontend
→
• реєстрація створює користувача в БД
• API повертає правильний статус
• система надсилає лист підтвердження
Тестування ПЗ
API
→
База даних
→
Email
Scenario: create account
POST /users → 201 Created
DB: user exists
Email: confirmation sent
14

15.

Приклад UI / end-to-end тесту
E2E тест імітує дії користувача від початку до кінця.
Сценарій: купівля товару
1. Відкрити сайт
2. Знайти товар
3. Додати в кошик
4. Оформити замовлення
5. Перевірити повідомлення про успіх
await page.goto("/shop");
await page.fill("#search", "phone");
await page.click("text=Add to cart");
await page.click("text=Checkout");
await expect(page.locator(".success"))
.toBeVisible();
Плюс: показує реальну працездатність продукту. Мінус: повільніший і більш крихкий, ніж unit-тест.
Тестування ПЗ
15

16.

Нефункціональні перевірки
Якість — це не лише наявність функції.
P Performance
час відповіді, навантаження, стабільність
U Usability
зручність, зрозумілість, доступність
Тестування ПЗ
S Security
авторизація, права доступу, захист даних
C Compatibility
браузери, ОС, мобільні пристрої
16

17.

Smoke, sanity та regression testing
Це різні перевірки перед релізом і після змін.
Smoke testing
Швидка перевірка: чи продукт
взагалі запускається і основні
функції доступні.
Sanity testing
Regression testing
Коротка перевірка конкретного
виправлення або невеликої зміни.
Перевірка, що нові зміни не
зламали старий функціонал.
Приклад: після зміни логіну треба перевірити не лише логін, а й реєстрацію, профіль і доступ до сторінок.
Тестування ПЗ
17

18.

Інструменти для тестування
QA використовує різні інструменти залежно від задачі.
Test management
Bug tracking
TestRail, Zephyr, Qase
Jira, YouTrack, GitHub Issues
TOOLS
Тестування ПЗ
API testing
Postman, Swagger, Insomnia
Automation
Playwright, Selenium, Cypress
Performance
JMeter, k6, Lighthouse
18

19.

Метрики тестування та якості
Метрики допомагають бачити стан продукту, але не замінюють мислення QA.
Defect density
кількість дефектів на модуль або обсяг коду
Test coverage
яка частина вимог або коду покрита тестами
Pass rate
відсоток успішно пройдених тестів
Escaped defects
дефекти, які потрапили до користувачів
Важливо: 100% покриття тестами не гарантує відсутності помилок, але зменшує ризики.
Тестування ПЗ
19

20.

Висновки
Тестування ПЗ — основа якості сучасних програмних продуктів.
• тестування перевіряє відповідність вимогам і
реальним потребам
• існують різні рівні, види та техніки тестування
• документація дефектів допомагає команді швидше
виправляти помилки
• автоматизація корисна для повторюваних
перевірок
Головна думка:
якісний продукт створюється не
в кінці розробки, а на кожному її
етапі.
OK
Дякую за увагу!
Тестування ПЗ
20