Category: Конспект тестувальника

У тестуванні програмного забезпечення важливо чітко розуміти, на якому рівні ми перевіряємо продукт. Саме тому існує поняття рівнів тестування (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 — це питання: “Чи конкретна зміна не зламала щось важливе?”

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

Confirmation testing та Regression testing — це два різних типи тестування.

Ось пояснення кожного з них та ключові відмінності:

Confirmation Testing (Підтверджувальне тестування)

Що це? Це тестування, яке проводиться для перевірки, чи була конкретна помилка виправлена. Його ще називають re-testing. Коли використовується? Після того, як розробник виправив баг, тестувальник виконує ті ж самі тест-кейси, які спочатку виявили помилку, щоб переконатися, що проблема більше не виникає. Мета: Підтвердити, що конкретний баг виправлено. Приклад: Була помилка: при введенні неправильного пароля не показується повідомлення про помилку. Після виправлення тестувальник перевіряє тільки цю функціональність, щоб упевнитися, що повідомлення тепер з’являється.

Regression Testing (Регресійне тестування)

Що це? Це тестування, яке виконується для перевірки, що нові зміни (виправлення багів, нові фічі) не спричинили нові помилки у вже працюючому функціоналі. Коли використовується? Після внесення змін у код — виправлень, оновлень або нових функцій. Мета: Переконатися, що існуюча функціональність не зламалась. Приклад: Після додавання нової кнопки на формі входу тестувальник перевіряє всю сторінку входу, включаючи правильну/неправильну авторизацію, поведінку UI, редіректи тощо.

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

Характеристика	Confirmation Testing	Regression Testing
Мета	Перевірити, чи виправлено конкретний баг	Переконатися, що нічого не зламалось після змін
Обсяг	Локалізований (тільки те, що було виправлено)	Широкий (вся пов’язана або вся система)
Засноване на	Результатах попереднього тестування (де знайдено баг)	Змінному коді або новому функціоналі
Частота	Після виправлення кожного багу	Після кожного релізу, спринту або великої зміни

Висновок

• Confirmation testing — це перевірка “Чи виправлено?”
• Regression testing — це перевірка “Чи не зламалося щось інше?”

Обидва типи тестування критично важливі для забезпечення якості програмного забезпечення.

Функціональне та нефункціональне тестування — це два основні типи тестування програмного забезпечення, які відрізняються метою перевірки: що система робить і як добре вона це робить.

Функціональне тестування (Functional Testing)

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

Нефункціональне тестування (Non-functional Testing)

Що це: Тестування, яке перевіряє якість, продуктивність і інші нефункціональні характеристики системи. Орієнтоване на: Швидкість Надійність Безпеку Зручність використання Сумісність Приклади характеристик, які тестуються: Час відгуку системи Стійкість під навантаженням Захист даних Підтримка різних браузерів або пристроїв Питання, на які відповідає: «Наскільки добре програма працює»

Основна різниця:

Критерій	Функціональне тестування	Нефункціональне тестування
Що перевіряє	ЩО система робить	ЯК система це робить
Орієнтація	Поведінка, функціональність	Продуктивність, безпека, зручність, надійність
Засноване на	Функціональних вимогах	Нефункціональних вимогах або критеріях якості
Приклади	Вхід/вихід, логін, пошук	Навантаження, час відгуку, UX, захист паролів

Підсумки:

Обидва типи є необхідними для повного тестового покриття.

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