Acceptance Testing (приймальне тестування) — це останній рівень тестування перед запуском програмного продукту в продакшн (в реальне середовище). Його головна мета — перевірити, чи відповідає продукт бізнес-вимогам, очікуванням користувачів, і чи може він бути офіційно прийнятий замовником або клієнтом.
Основні характеристики Acceptance Testing
Мета: підтвердити, що система працює так, як очікується з точки зору бізнесу та користувача.
Хто проводить? Зазвичай проводиться замовником, кінцевими користувачами або представниками бізнесу. Але тестувальники теж можуть допомагати в підготовці сценаріїв.
Що перевіряється?
Виконання бізнес-вимог
Реальні користувацькі сценарії (User Stories або Use Cases)
System Integration Testing (SIT) — це рівень тестування, що проводиться після System Testing, і має на меті перевірити, як система інтегрується з іншими системами або зовнішніми компонентами, а також перевірити, як система взаємодіє із зовнішнім середовищем, наприклад, через інтерфейси або API.
Мета System Integration Testing (SIT)
Система після проходження System Testing є повністю функціональною, але SIT перевіряє, як вона взаємодіє з іншими системами або компонентами. SIT допомагає виявити помилки, які можуть виникнути під час взаємодії компонентів, а також перевіряє коректність інтеграційних точок, таких як API, бази даних, сторонні сервіси тощо.
Метою SIT є:
Перевірка коректності взаємодії системи з іншими компонентами.
Перевірка зовнішніх інтеграцій і взаємодії з іншими програмними продуктами.
Перевірка передачі даних між системами або компонентами, зокрема правильності форматів, протоколів та безпеки.
Перевірка того, як система працює у більшому контексті, коли інтегрується з іншими частинами (сервіси, сторонні інтерфейси тощо).
Особливості SIT в порівнянні з іншими етапами тестування
Component Integration Testing (CIT) проводиться після Component Testing, коли перевіряється взаємодія між окремими модулями програми. SIT ж перевіряє всю систему як єдине ціле, і її взаємодію з іншими системами або підсистемами.
System Testing фокусується на перевірці функціональності системи як такої, без акценту на взаємодію з іншими системами, тоді як SIT фокусується саме на інтеграції з зовнішніми компонентами.
Основні характеристики System Integration Testing
Типи інтеграцій:
Інтеграція з іншими системами: Перевіряється, як система працює в контексті з іншими системами. Наприклад, перевіряється, як програма взаємодіє з іншими базами даних, сторонніми API чи сервісами.
Інтеграція з апаратними засобами: Якщо система має взаємодіяти з апаратними пристроями (наприклад, датчиками, принтерами), тестується коректність їх інтеграції.
Мережеві взаємодії: Тестуються протоколи зв’язку між системами, перевіряється коректність передачі даних через мережу, стійкість до помилок і безпека.
Об’єкти тестування:
API: Інтерфейси для взаємодії з іншими системами або компонентами.
Бази даних: Перевірка того, як дані зчитуються і передаються між різними компонентами.
Веб-сервіси: Тестування взаємодії через SOAP, REST або інші протоколи.
Сторонні сервіси: Перевірка інтеграції з іншими сторонніми системами, такими як платіжні шлюзи, системи електронної пошти або постачальники даних.
Тестування взаємодії між різними типами компонентів: SIT передбачає перевірку того, як система працює з різними типами компонентів — від програмних модулів до апаратних пристроїв і сторонніх сервісів. Це тестування зв’язків між різними частинами системи, що важливо для забезпечення її належної роботи в реальних умовах.
Підвищена увага до неочевидних помилок: SIT дозволяє виявити помилки, які можуть не бути помітними на рівні компонентного тестування або системного тестування. Наприклад, це можуть бути помилки, пов’язані з нестабільними або неправильно налаштованими інтерфейсами між системами.
Часова точка виконання: SIT виконується після System Testing (коли система функціонує коректно як окрема одиниця), але до Acceptance Testing (коли тестуються умови прийняття продукту).
Техніки тестування в SIT
В рамках SIT застосовуються такі техніки:
Тестування інтеграційних точок: Перевірка кожного інтерфейсу між системами (наприклад, REST API, файлові інтерфейси).
Тестування відмов та відновлення: Перевірка, як система поводиться при відмові зовнішніх компонентів (наприклад, падіння API-сервісу).
Тестування безпеки: Перевірка безпечності інтеграцій, включаючи захист даних при передачі через мережу, перевірка авторизацій і автентифікацій.
Тестування масштабованості: Перевірка того, як система поводиться при збільшенні навантаження, особливо якщо інтеграція відбувається з іншими великими системами.
Типові проблеми, що виявляються на етапі SIT
Невідповідність протоколів: Невідповідність форматів передачі даних або протоколів між різними системами.
Невірна обробка даних: Наприклад, некоректна конвертація дат, чисел чи інших даних при інтеграції з зовнішніми системами.
Відсутність коректних механізмів обробки помилок: Помилки, що виникають через несправності зовнішніх компонентів, наприклад, через падіння сервісу, який інтегрується.
Ризики, пов’язані з SIT
Неповна документація: Відсутність точних технічних специфікацій для інтеграційних точок може призвести до неочевидних помилок.
Проблеми з конфігурацією: Невірно налаштовані інтеграційні середовища можуть призвести до непрацюючих тестів або тестування на непідготовленому середовищі.
Залежність від зовнішніх постачальників: Проблеми з інтеграцією можуть виникнути через затримки або непередбачувану поведінку зовнішніх сервісів.
Висновок
System Integration Testing — це важливий етап тестування, що дозволяє забезпечити безперебійну роботу системи в реальному середовищі, де вона має взаємодіяти з іншими компонентами або зовнішніми системами.
System Testing (Системне тестування) — це рівень тестування, під час якого тестується повністю зібрана, інтегрована система, яка складається з усіх компонентів (модулів), але ще не включає зовнішніх систем або середовищ.
Це тестування розглядає продукт як єдине ціле, перевіряючи, чи відповідає він функціональним та нефункціональним вимогам, сформульованим у специфікації або вимогах до системи.
Контекст у рівнях тестування
Згадаємо рівні тестування та місце System Testing:
Рівні тестування (Test Levels)
Рівень тестування
Що тестується
Основна мета
1. Unit Testing
Окремі компоненти (класи, методи, функції)
Перевірка правильності логіки окремих одиниць
2. Component Integration Testing
Взаємодія між компонентами системи
Перевірка коректної інтеграції модулів
3. System Testing
Уся система як цілісний продукт
Перевірка відповідності вимогам
4. System Integration Testing
Взаємодія системи з іншими зовнішніми системами
Перевірка інтеграції на рівні міжсистемному
5. Acceptance Testing
Готовий продукт з точки зору користувача
Перевірка прийнятності продукту для релізу
Коли проводиться?
System Testing виконується після успішного завершення Component Integration Testing, коли всі окремі компоненти вже інтегровані та працюють разом. Система на цьому етапі вважається функціонально повною, але ще не взаємодіє з зовнішніми системами (API, сторонні сервіси, інші підсистеми тощо).
Ціль System Testing
Перевірити, чи відповідає вся система вимогам, зазначеним у:
функціональній специфікації
технічному завданні
бізнес-вимогах
документації користувача
Хто виконує
System Testing зазвичай проводиться незалежною командою тестувальників. Часто використовується техніки “чорної скриньки“, коли тестувальник не має знань про внутрішню реалізацію системи, а перевіряє лише зовнішню поведінку.
Що саме тестується
System Testing охоплює повний набір функціональних і нефункціональних тестів:
Функціональне тестування:
Перевірка бізнес-логіки
Перевірка обробки помилок
Валідація даних
Тестування ролей користувачів
Перевірка навігації та взаємодії
Нефункціональне тестування:
Performance Testing (тестування продуктивності)
Security Testing (перевірка безпеки)
Usability Testing (юзабіліті-тестування)
Compatibility Testing (сумісність із ОС, браузерами, пристроями)
Localization Testing (перевірка перекладів, форматів дат тощо)
Accessibility Testing (відповідність стандартам WCAG для користувачів з обмеженими можливостями)
Відмінність від суміжних рівнів
Порівняння з Component Integration Testing:
Параметр
Component Integration Testing
System Testing
Що перевіряється
Взаємодія між компонентами
Повна система як єдине ціле
Рівень деталізації
Середній (компоненти)
Високий (усі фічі, як бачить користувач)
Підхід
Часто “білого ящика”
Зазвичай “чорного ящика”
Фокус
Інтерфейси, обмін даними між модулями
Повна відповідність системи вимогам
Порівняння з System Integration Testing:
Параметр
System Testing
System Integration Testing
Фокус
Внутрішня цілісність системи
Взаємодія з іншими системами
Включає зовнішні системи?
Ні
Так
Приклад
Реєстрація користувача, додавання товару до кошика
Інтеграція з платіжною системою, ERP
Залежність від середовища
В основному автономне середовище
Інтегроване середовище з іншими системами
Приклади System Testing
Ви тестуєте CRM-систему: перевіряєте реєстрацію клієнта, створення лідів, створення угоди, зміну статусу, генерацію звіту.
Ви тестуєте e-commerce платформу: проходите повний шлях користувача — від перегляду товарів до оформлення замовлення.
Переваги System Testing
Дозволяє виявити дефекти, що проявляються лише на рівні взаємодії всіх компонентів.
Імітує поведінку реального користувача.
Перевіряє виконання вимог замовника.
Недоліки System Testing
Вимагає повністю зібраної системи, тому виконується пізно в циклі розробки.
Важко знайти причину помилки, якщо вона виникає на рівні компонентів — потребує ретельної ізоляції дефекту.
Може бути дорогим через складність тестового середовища.
Підсумки
System Testing — це тестування повної системи на відповідність вимогам, яке виконується після того, як окремі компоненти були зібрані та протестовані разом (Component Integration Testing), але ще до взаємодії із зовнішніми системами (System Integration Testing).
Це важливий рівень тестування, який забезпечує перевірку того, що вся система працює правильно та готова до інтеграції в реальне середовище.
Component Integration Testing (тестування інтеграції компонентів) — це рівень тестування, на якому перевіряється взаємодія між окремими компонентами (модулями) системи після того, як кожен із них уже був протестований окремо (на рівні модульного тестування / Unit Testing).
Що таке «компонент»?
Компонент — це логічно відокремлений блок програми, який виконує певну функцію. Наприклад, у веб-додатку це можуть бути:
компонент авторизації,
компонент роботи з базою даних,
UI-компонент (форма, таблиця),
компонент API тощо.
Мета Component Integration Testing
Перевірити, чи правильно взаємодіють між собою окремі компоненти після їх об’єднання. Тобто не просто перевірити, що кожен працює окремо, а що їх зв’язки і передача даних між ними працює без помилок.
Приклад:
У системі є два компоненти:
LoginComponent — збирає логін/пароль і передає їх до
AuthService — перевіряє їх у базі даних.
На рівні component integration testing перевіряється:
Чи правильно LoginComponent викликає AuthService.
Чи правильно передаються дані (наприклад, JSON з логіном).
Чи коректно обробляється відповідь (успішний логін або помилка).
Методи реалізації
Bottom-up — спочатку інтегруються нижчі компоненти (напр., API та база), потім — вищі.
Top-down — спочатку тестуються зв’язки між вищими рівнями (UI, логіка), замінюючи нижчі моками.
Big Bang — всі компоненти інтегруються одразу й тестуються разом (не рекомендується через складність локалізації помилок).
Sandwich (гібридний) — поєднання top-down і bottom-up.
Інструменти
Для JavaScript/React: Jest + React Testing Library
Для Java/Backend: JUnit, Mockito
Для Python: pytest, unittest
Для інтеграцій: Postman, REST-assured, Cypress (в E2E режимі)
Component Testing, також відомий як Unit Testing, — це базовий рівень тестування, з якого все починається.
Що таке Component Testing?
Component Testing — це рівень тестування, при якому окремі частини (компоненти) програмного забезпечення перевіряються в ізоляції від інших частин системи.
Компонентом може бути:
окрема функція або метод
клас або модуль
сервіс або мікросервіс (на ранньому етапі)
Мета Component Testing:
Перевірити, що компонент працює відповідно до специфікації
Виявити логічні помилки та неправильну реалізацію на ранньому етапі
Забезпечити надійну основу для інтеграції з іншими модулями
Хто проводить?
Зазвичай — розробники
Або — автоматизовані юніт-тести як частина CI/CD
Тестувальники також можуть долучатися, якщо мова йде про більш складні або бізнес-критичні компоненти
Інструменти для Component Testing:
Java: JUnit, TestNG
JavaScript: Jest, Mocha, Jasmine
Python: pytest, unittest
C#: NUnit, xUnit
CI-платформи: GitHub Actions, Jenkins, GitLab CI
Приклад:
Є функція calculateDiscount(price, userType). Component Testing має перевірити:
як вона працює з різними типами користувачів
що відбувається, якщо передати некоректні значення
чи правильно застосовується логіка знижок
Переваги Component Testing:
Швидке виявлення помилок
Легка локалізація дефекту
Допомагає розробникам впевнено вносити зміни
Підвищує стабільність системи на наступних рівнях тестування
Висновок
Component Testing — це фундамент якісного ПЗ. Його часто недооцінюють, але саме тут виявляються помилки, які можуть обійтися дуже дорого, якщо їх пропустити далі.