Month: September 2025

Component Testing (модульне тестування)

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 — це фундамент якісного ПЗ. Його часто недооцінюють, але саме тут виявляються помилки, які можуть обійтися дуже дорого, якщо їх пропустити далі.

У тестуванні програмного забезпечення важливо чітко розуміти, на якому рівні ми перевіряємо продукт. Саме тому існує поняття рівнів тестування (Test Levels).

Що таке Test Level (Рівень тестування)?

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

Основні рівні тестування:

1. Component Testing (Тестування компонентів)

Інше назва: Unit Testing

• Мета: перевірити окремі функції або модулі в ізоляції
• Хто проводить: зазвичай розробники
• Що тестується: одна функція, метод або клас

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

2. Component Integration Testing (Інтеграція компонентів)

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

• Мета: виявити помилки у взаємодії між компонентами
• Фокус: API, обмін даними, виклики між модулями
• Методи: Top-down, Bottom-up, Big Bang

Приклад: перевірка взаємодії форми входу з бекендом авторизації.

3. System Testing (Системне тестування)

Тестування всієї системи як єдиного цілого.

• Мета: перевірити, чи відповідає система специфікаціям
• Типи: функціональне, нефункціональне
• Хто проводить: тестувальники

Приклад: перевірка всього процесу покупки — від вибору товару до отримання email-підтвердження.

4. System Integration Testing (Інтеграція систем)

Перевірка взаємодії між системою і зовнішніми сервісами або іншими системами.

• Мета: переконатися, що інтеграція працює коректно
• Фокус: зовнішні API, бази даних, сторонні сервіси
• Виклики: нестабільні середовища, складність відтворення помилок

Приклад: тестування інтеграції з платіжною системою або службою доставки.

5. Acceptance Testing (Приймальне тестування)

Фінальна перевірка перед випуском продукту.

• Мета: впевнитися, що продукт задовольняє бізнес-вимоги
• Хто проводить: замовник, кінцеві користувачі, тестувальники
• Типи: UAT (User Acceptance Testing), Alpha/Beta Testing

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

Висновок

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

Exploratory Testing (дослідницьке тестування) — це нестандартизований підхід до тестування, при якому тестувальник одночасно вивчає продукт, проектує тести і виконує їх, не дотримуючись жорстко прописаних тест-кейсів.

Що таке Exploratory Testing?

Це тип тестування, коли:

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

Основні риси Exploratory Testing

Характеристика	Пояснення
Неформальність	Зазвичай не використовуються формальні тест-кейси
Одночасність	Планування, виконання і аналіз тестів відбуваються одночасно
Креативність	Тестувальник застосовує власну креативність та логіку
Адаптивність	Підхід змінюється на ходу в залежності від результатів
Документування	Мінімальне або по факту: тестувальник записує результати під час або після тесту

Коли використовувати Exploratory Testing?

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

Переваги

• Виявляє нестандартні, складні або граничні баги
• Дає можливість протестувати те, що не враховано в тест-кейсах
• Швидке охоплення системи
• Підходить для Agile / Scrum, де зміни постійні

Недоліки

• Важко відтворити тести, якщо не задокументовано кроки
• Залежить від досвіду тестувальника
• Менше контрольоване з точки зору менеджменту
• Не замінює формального тестування при критичних системах (медичне ПЗ, банківські системи тощо)

Приклад

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

Висновок

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

Smoke Testing та Sanity Testing — це два типи поверхневого тестування, які використовуються для швидкої перевірки стабільності та готовності програмного продукту до подальшого (глибшого) тестування. Вони дуже схожі, але виконуються в різних ситуаціях і з різною метою.

Smoke Testing (Димове тестування)

Що це? Це початкове базове тестування програми після нового білду, щоб перевірити, чи основні функції працюють, і чи взагалі є сенс проводити подальше тестування. Назва походить з апаратного тестування: якщо пристрій “не димить” після увімкнення, з ним можна працювати далі. Коли виконується? Після отримання нового білду, перед будь-яким глибшим тестуванням. Мета: Перевірити, що критичні функції (логін, навігація, запуск основних модулів) працюють, і продукт не «падає» одразу. Визначити, чи взагалі білд придатний для подальшого тестування. Характеристики: Високорівневе тестування Покриває всю систему поверхнево Автоматизоване або ручне Швидке: займає кілька хвилин до години

Sanity Testing (Тестування працездатності)

Що це? Це поверхневе тестування конкретної частини програми, зазвичай після виправлення багу або незначної зміни, щоб переконатися, що ця зміна працює як очікується, і не зламала нічого критичного поруч. Коли виконується? Після невеликих змін у коді, наприклад: Виправлення багів Локальні зміни в логіці Невеликі UI-оновлення Мета: Перевірити, що нововнесені зміни працюють і що ключова пов’язана функціональність не порушена. Характеристики: Низькорівневе, вузьконаправлене тестування Фокусується на одній функціональності або модулі Зазвичай ручне Виконується швидко (але може бути частиною регресії)

Основні відмінності

Характеристика	Smoke Testing	Sanity Testing
Мета	Перевірити стабільність системи загалом	Перевірити логіку після конкретної зміни
Коли використовується	Після кожного нового білду	Після фіксу або малої зміни
Покриття	Широке, поверхневе	Вузьке, глибше в рамках однієї фічі
Фокус	Основні функції програми	Конкретна зміна чи баг
Автоматизація	Часто автоматизоване	Переважно ручне
Чи продовжувати тестування?	Якщо пройдено — запускається повне тестування	Якщо пройдено — можна не запускати повну регресію

Висновок

• Smoke Testing — це питання: “Чи система взагалі працює?”
• Sanity Testing — це питання: “Чи конкретна зміна не зламала щось важливе?”

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