Author: adminknowledgeserf

Техніки тестування “чорної скриньки” (Black box testing techniques) — це підхід до тестування програмного забезпечення, при якому тестувальник не має доступу до внутрішнього коду або структури програми. Вся увага зосереджена на перевірці функціональності та взаємодії між користувачем і системою, без знань про те, як саме реалізовані ці функції.

Основні техніки тестування чорної скриньки:

1. Тестування еквівалентних класів (Equivalence Class Partitioning): програму тестують шляхом поділу вхідних даних на класи еквівалентності. Кожен клас містить такі ж або подібні значення. Якщо програма коректно обробляє одне значення з класу, можна вважати, що вона коректно обробляє всі інші значення цього класу.
2. Тестування граничних значень (Boundary Value Analysis): це техніка тестування, де перевіряються крайні значення вхідних даних. Зазвичай помилки найчастіше виникають саме на межах допустимих значень. Наприклад, якщо програма приймає числа від 1 до 10, то тестувальник може перевірити значення 1, 10, а також значення, які знаходяться поруч: 0, 11.
3. Тестування таблиць прийняття рішень (Decision Table Testing): використовується для систем, де вхідні дані можуть мати кілька можливих комбінацій, що призводять до різних результатів. Тестувальник створює таблицю, в якій зазначені всі можливі комбінації вхідних значень і відповідні результати для кожної з них.
4. Тестування переходів станів (State Transition Testing): у випадку програм, які мають різні стани (наприклад, система, яка переходить від одного стану до іншого в залежності від подій), тестувальник перевіряє, чи система коректно реагує на події, що викликають зміну стану.
5. Тестування на основі сценаріїв використання (Use Case Testing): тестування фокусується на перевірці, чи система виконує необхідні операції для користувача в рамках певних сценаріїв. Це допомагає перевірити, чи система відповідає вимогам і чи забезпечує належний досвід користувача.

Переваги тестування чорної скриньки:

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

Недоліки:

• Не дозволяє виявити помилки в коді — оскільки тестувальник не має доступу до коду, він не може виявити проблеми, які пов’язані з внутрішньою логікою або архітектурою програми.
• Обмеженість тестових випадків — неможливо протестувати всі можливі варіанти роботи системи, тому тестування часто є неповним.

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

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

Основні характеристики Acceptance Testing

Мета: підтвердити, що система працює так, як очікується з точки зору бізнесу та користувача.

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

Що перевіряється?

• Виконання бізнес-вимог
• Реальні користувацькі сценарії (User Stories або Use Cases)
• Інтерфейс, функціонал, зрозумілість, надійність

Етапи Acceptance Testing

Підготовка	•Збір бізнес-вимог •Розробка acceptance-критеріїв •Створення тест-кейсів (user scenarios)
Виконання	•Клієнт/користувач виконує сценарії •Збирається зворотний зв’язок •Документується результат (успішно/неуспішно)
Результати	•Якщо всі ключові вимоги виконані — продукт приймається •Якщо є критичні дефекти — продукт відправляється на доопрацювання

Види Acceptance Testing

Тип	Опис
User Acceptance Testing (UAT)	Тестування кінцевими користувачами. Найпоширеніший тип.
Business Acceptance Testing (BAT)	Фокус на досягнення бізнес-цілей і процесів.
Contract Acceptance Testing	Перевірка відповідності вимогам контракту між замовником і постачальником.
Regulation Acceptance Testing	Перевірка відповідності стандартам (наприклад, GDPR, ISO).
Alpha Testing	Внутрішнє тестування клієнтом або співробітниками розробника.
Beta Testing	Зовнішнє тестування обраними користувачами перед запуском.

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

• Чи можна успішно увійти в додаток
• Чи працює переказ коштів
• Чи відображаються правильні залишки на рахунках
• Чи коректно приходять push-сповіщення тощо

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

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

1. Типи інтеграцій:
   • Інтеграція з іншими системами: Перевіряється, як система працює в контексті з іншими системами. Наприклад, перевіряється, як програма взаємодіє з іншими базами даних, сторонніми API чи сервісами.
   • Інтеграція з апаратними засобами: Якщо система має взаємодіяти з апаратними пристроями (наприклад, датчиками, принтерами), тестується коректність їх інтеграції.
   • Мережеві взаємодії: Тестуються протоколи зв’язку між системами, перевіряється коректність передачі даних через мережу, стійкість до помилок і безпека.
2. Об’єкти тестування:
   • API: Інтерфейси для взаємодії з іншими системами або компонентами.
   • Бази даних: Перевірка того, як дані зчитуються і передаються між різними компонентами.
   • Веб-сервіси: Тестування взаємодії через SOAP, REST або інші протоколи.
   • Сторонні сервіси: Перевірка інтеграції з іншими сторонніми системами, такими як платіжні шлюзи, системи електронної пошти або постачальники даних.
3. Тестування взаємодії між різними типами компонентів:
   SIT передбачає перевірку того, як система працює з різними типами компонентів — від програмних модулів до апаратних пристроїв і сторонніх сервісів. Це тестування зв’язків між різними частинами системи, що важливо для забезпечення її належної роботи в реальних умовах.
4. Підвищена увага до неочевидних помилок:
   SIT дозволяє виявити помилки, які можуть не бути помітними на рівні компонентного тестування або системного тестування. Наприклад, це можуть бути помилки, пов’язані з нестабільними або неправильно налаштованими інтерфейсами між системами.
5. Часова точка виконання:
   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).

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