Manual QA

Види тестування

smoke, regression, exploratory та інші

Функціональне і нефункціональне тестування — у чому різниця?

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

Нефункціональне — як вона це робить: продуктивність (навантаження, стрес), безпека, зручність, доступність, сумісність, надійність, локалізація.

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

Чим відрізняються smoke, sanity і регресійне тестування?

Вид	Що перевіряє	Коли
Smoke	Критичні функції працюють, білд взагалі можна тестувати	На кожному новому білді
Sanity	Конкретна зміна чи фікс працює, вузько й глибоко	Після невеликого фіксу
Regression	Зміни не зламали те, що працювало раніше	Перед релізом, після змін

На співбесіді: Smoke — широка поверхнева перевірка, що білд живий і основні функції працюють. Sanity — вузька перевірка конкретної зміни чи фіксу. Регресія — перевірка, що нові зміни не зламали вже існуючу функціональність, і вона найширша з трьох.

Чим ретест відрізняється від регресійного тестування?

Ретест — перевірка, що конкретний баг виправлено: проходимо ті самі кроки, що в баг-репорті.

Регресія — перевірка, що виправлення або нова фіча не зламали інше. Ретест перевіряє одне місце, регресія — все навколо.

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

Що таке black box, white box і grey box?

Black box — тестуємо за вимогами, не знаючи коду. Основний підхід manual QA.
White box — тестуємо, знаючи внутрішню структуру: покриття гілок, умов. Зазвичай розробники.
Grey box — частково знаємо внутрішню будову: схему бази, API, логи. Наприклад, після дії в UI перевіряємо запис у БД або запит у DevTools.

На співбесіді: Black box — тестування за вимогами без знання коду. White box — з повним знанням внутрішньої логіки. Grey box — посередині: я не читаю код, але перевіряю базу, API-запити й логи. Саме так я працюю найчастіше: дія в UI, потім перевірка запиту в DevTools і запису в базі.

Що таке exploratory testing і як його робити структуровано?

Дослідницьке тестування — одночасне вивчення продукту, проєктування і виконання тестів без готових кейсів. Сильне там, де вимоги неповні або треба швидко знайти найважливіші баги.

Щоб це не було хаотичним «поклацати», використовують сесії з чартером: мета («дослідити повернення коштів з частково оплаченими замовленнями»), фіксований час (60–90 хв), нотатки, результат — баги, питання й ідеї для нових кейсів.

На співбесіді: Exploratory — це коли я одночасно вивчаю продукт, придумую і виконую тести. Щоб це було керовано, я працюю сесіями: ставлю чартер з конкретною метою, обмежую час і веду нотатки, а наприкінці маю баги, питання до команди й ідеї для нових тест-кейсів.

Що таке alpha, beta і UAT?

Alpha — внутрішнє тестування командою або співробітниками до виходу назовні.
Beta — обмежена група реальних користувачів на реальному середовищі.
UAT — приймальне тестування замовником або бізнесом: чи відповідає продукт бізнес-потребам. QA часто готує сценарії й підтримує процес.

На співбесіді: Alpha — внутрішнє тестування до виходу назовні. Beta — реальні користувачі в обмеженій групі. UAT — приймання продукту бізнесом або замовником, і моя роль там — підготувати сценарії, середовище й дані та допомогти розібратися з тим, що знайдуть.

Чим інтеграційне тестування відрізняється від end-to-end?

Інтеграційне — перевірка взаємодії двох-трьох компонентів: фронтенд і API, сервіс і база, наш бекенд і платіжний провайдер. Можна з моками інших частин.

End-to-end — повний шлях користувача через усю систему: реєстрація → поповнення → переказ → виписка, з реальними інтеграціями.

На співбесіді: Інтеграційне перевіряє стик кількох компонентів, наприклад як наш бекенд працює з платіжним провайдером. End-to-end — увесь шлях користувача через систему від початку до кінця. Інтеграційних тестів більше й вони точніше вказують на місце проблеми, а e2e перевіряють найважливіші сценарії цілком.

Exploratory testing

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

Session-based testing структурує цей процес: сесія має обмежений час, зазвичай 60–120 хвилин, і конкретний charter. Charter — це місія сесії, наприклад «Дослідити оформлення замовлення з різними способами оплати, щоб знайти проблеми з валідацією». Під час сесії ведуться нотатки: що перевірено, які баги й питання знайдено.

Після сесії проводиться debrief з тімлідом або командою. Для ідей використовують евристики: граничні значення, переривання флоу, зміна мережі, паралельні дії, «тури» по продукту.

Functional, integration, system testing

Functional testing перевіряє, що система робить те, що описано у вимогах, без огляду на внутрішню реалізацію. Наприклад, фільтр товарів за ціною повертає лише товари в заданому діапазоні. Це тип тестування, а не рівень, і він застосовується на всіх рівнях.

Integration testing перевіряє взаємодію між модулями або сервісами. Наприклад, після оформлення замовлення сервіс замовлень коректно передає дані в сервіс оплати і сервіс сповіщень. Тут шукаємо проблеми на стиках: формати даних, контракти API, таймаути.

System testing перевіряє всю систему цілком у середовищі, максимально наближеному до продакшну. Наприклад, повний шлях користувача від реєстрації до отримання листа з підтвердженням замовлення. Сюди входять і функціональні, і нефункціональні перевірки.

Регресія vs ретест і скоуп регресії

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

Скоуп регресії при обмеженому часі визначаю через аналіз ризиків. Спершу — зони, яких торкнулися зміни, та суміжні модулі, з якими вони інтегровані. Далі — критичні бізнес-флоу: логін, оплата, оформлення замовлення. Потім — зони, де історично часто були баги.

Допомагає розмова з розробником про те, що саме змінювалось, і аналіз git diff. Усе стабільне й повторюване бажано покривати автотестами, а мануальний час витрачати на нові та ризикові зони.

UAT

User Acceptance Testing — фінальний рівень тестування, де замовник або кінцеві користувачі перевіряють, що система відповідає їхнім бізнес-потребам. Питання тут не «чи немає багів», а «чи вирішує продукт нашу задачу». Проводиться після system testing на середовищі, близькому до продакшну.

Виконують його бізнес-користувачі, PO або представники замовника, а не QA. Роль QA — підготувати середовище й тестові дані, допомогти скласти UAT-сценарії, пояснити, як користуватися системою. Також QA фіксує та трасує знайдені проблеми й відділяє дефекти від запитів на зміни.

Різновиди: alpha і beta testing, operational acceptance, contract acceptance. Результат UAT — рішення про приймання продукту або sign-off.

Види навантажувального тестування і JMeter

Load testing перевіряє поведінку системи під очікуваним навантаженням, наприклад 1000 одночасних користувачів у пікові години. Мета — переконатися, що час відповіді й кількість помилок у межах SLA. Stress testing навантажує систему понад норму, щоб знайти точку відмови і перевірити, як вона відновлюється.

Spike testing — різкий короткочасний стрибок навантаження, як під час розпродажу чи розсилки. Також існують soak або endurance testing — тривале навантаження годинами для пошуку витоків пам'яті, та scalability testing. Ключові метрики: час відповіді (середній і перцентилі p95, p99), throughput, відсоток помилок, використання CPU і пам'яті.

У JMeter основа — Test Plan, у ньому Thread Group задає кількість віртуальних користувачів, ramp-up і кількість ітерацій. Sampler — сам запит, наприклад HTTP Request. Assertions перевіряють відповідь: статус-код, текст чи час. Listeners збирають і показують результати, наприклад Summary Report. Також важливі Config Elements (CSV Data Set Config, HTTP Header Manager), Timers для пауз і запуск у non-GUI режимі для реальних тестів.