Тестові середовища і виконання тестів

Зміст

Розробник пише в чат «задеплоїв фікс на стейдж», менеджер питає «який pass rate на релізному білді», хтось панікує «прод лежить, котимо hotfix». Якщо половина цих слів звучить як шум — ця глава саме про них: про робочу мову, якою команда щодня говорить про виконання тестів. Середовища, тестові дані, білди й статуси — це не «теорія для сертифікації», а лексикон першого ж стендапу. І класика співбесід для trainee: «чим blocked відрізняється від failed?» і «чим реліз відрізняється від деплою?» — питання, на яких видно, чи працювала людина в реальному проєкті.

Глава — продовження STLC: життєвий цикл тестування: там фази циклу цілком, тут — глибше про фази виконання і завершення. Якщо проходиш розділ уперше й послідовно, цю главу можна пропустити і повернутися пізніше — наступні глави спираються на неї лише окремими термінами. Але перед співбесідою повернись обовʼязково: питають звідси багато.

Середовища: dev, test, stage, prod

Чому код не їде з ноутбука розробника одразу до користувачів? Бо будь-яка зміна потенційно щось ламає, і чим пізніше поломка виявиться, тим дорожче обійдеться. Тому між «написав код» і «користувач бачить фічу» будують ланцюжок середовищ (environments) — окремих інсталяцій застосунку зі своїми серверами, базою та конфігурацією. Кожна зупинка ловить свій клас проблем: dev — «код взагалі не працює», test — «фіча працює не так», stage — «в бойовій конфігурації все розвалюється», prod — те, що прослизнуло повз усіх.

Середовище	Хто працює	Навіщо	Дані
dev	Розробники	Розробка і дебаг; нестабільне, ламати можна	Мінімальні, синтетичні
test (QA)	Тестувальники	Основний обсяг тестування	Тестові, підготовлені під кейси
stage (staging, preprod)	QA, бізнес, DevOps	Фінальна перевірка в умовах, максимально наближених до prod; часто тут UAT	Реалістичні, знеособлені
prod (production)	Реальні користувачі	Живий продукт; тестування мінімальне й обережне	Реальні

Назви — не стандарт, а конвенція команди: десь є окремий UAT, десь sandbox чи demo для клієнтів, десь test і stage злиті в одне. На співбесіді важить не завчений список, а розуміння призначення: чим ближче середовище до prod, тим воно стабільніше, тим суворіші доступи й тим дорожче на ньому щось зламати.

Чим середовища відрізняються насправді — і чому це болить QA:

Конфігурація. Інші змінні оточення, вимкнені чи ввімкнені фіче-флаги, інші ліміти. Фіча, якої «немає» на test, може бути просто вимкнена прапорцем.
Інтеграції. На test платіжка працює в тестовому режимі або замінена заглушкою, пошта не надсилається назовні, зовнішні API — часто моки. На prod усе справжнє.
Дані. На test — сотні записів, на prod — мільйони. Пагінація, пошук і продуктивність поводяться зовсім інакше.
Інфраструктура. На prod зазвичай є CDN, кешування, балансувальник навантаження — на test їх може не бути. Через кеш prod може показувати стару версію фронтенду ще довго після деплою — механіка розібрана в главі Кешування.
Моніторинг і доступи. На prod — алерти, логи, обмежені права; «потикати руками в базі» там не вийде і не можна.

Звідси головний практичний висновок: фраза «баг не відтворюється» дуже часто означає «відтворюється, але не на твоєму середовищі». Перше, що з'ясовують при розборі дефекту, — де саме його бачили: яке середовище, який білд, які дані. Тому в баг-репорті поле «середовище» обовʼязкове — детальніше в главі Баг-репорт і життєвий цикл дефекту.

І про тестування на prod: воно існує, але обмежене. Типовий приклад — смоук після релізу: швидко пройти критичні сценарії, щоб переконатися, що деплой нічого не поклав. Обережність тут буквальна: тестове замовлення на prod проходить через справжню платіжну систему, а тестовий лист летить реальному користувачеві.

Тестові дані: підготовка, ізоляція, деперсоналізація

Майже кожен тест-кейс починається з передумов: «користувач з роллю адміністратора», «товар із нульовим залишком», «підписка, що спливла вчора». Це і є тестові дані (test data) — стан системи, без якого перевірку не виконати. Три речі, які про них треба розуміти на рівні trainee: як їх готують, чому їх ізолюють і чому не можна просто взяти дані з prod.

Підготовка. Дані або створюють заздалегідь (набори облікових записів і сутностей «під кейси», часто їх називають фікстурами — fixtures), або генерують безпосередньо перед тестом. Заздалегідь — швидше на старті, але набори старіють і «розʼїжджаються» з реальністю; на льоту — надійніше, але кожен тест стає довшим. У ручному тестуванні зазвичай комбінують: базові акаунти живуть постійно, специфічний стан створюється в передумовах кейсу.

Ізоляція. Кожен тест має працювати зі своїми даними. Якщо два тестувальники (або ручний прогін і автотести) редагують той самий обліковий запис, результати починають залежати від порядку дій: тест А поміняв пароль — тест Б не може залогінитись, і це виглядає як баг застосунку, хоча застосунок ні до чого. Найпростіший прийом ізоляції — унікальні дані на кожен прогін:

// Унікальний email на кожен запуск — тести не зіштовхуються
const email = `qa+${Date.now()}@example.com`;
await page.getByLabel('Email').fill(email);

Це концепція, а не повний рецепт: стратегія тестових даних для автоматизації (сідінг бази, фабрики, очищення після прогону) — окрема тема розділу про автоматизацію.

Деперсоналізація. Спокуслива ідея: скопіювати базу з prod на test — от і «найреалістичніші дані». Проблема в тому, що там персональні дані живих людей: імена, пошти, телефони, адреси, історія замовлень. Витік з тестового середовища (де доступи традиційно слабші за прод) — це справжній витік персональних даних з юридичними наслідками: у ЄС це регулює GDPR, в Україні — закон «Про захист персональних даних». Тому перед перенесенням дані знеособлюють. Три підходи, від радикального до м'якого:

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

Для QA підсумок такий: реалістичність даних — цінність, але вона ніколи не переважує приватність. «Скинь мені дамп проду» — питання, яке має викликати рефлекторне «а він знеособлений?».

Білд, деплой, реліз, hotfix: словник

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

Білд (build) — зібраний з вихідного коду артефакт: конкретна версія застосунку, яку можна встановити. У білда є ідентифікатор (номер, хеш коміту), і саме він відповідає на питання «а ЩО ми зараз тестуємо». Один і той самий білд може побувати на всіх середовищах по черзі.
Деплой (deploy, deployment) — процес встановлення білда на конкретне середовище. «Задеплоїли білд 2.14.0 на stage» — технічна дія, користувачі її не бачать.
Реліз (release) — момент, коли функціональність стає доступна користувачам, і сама ця опублікована версія. Деплой — технічна подія, реліз — продуктова: код можна задеплоїти на prod і тримати вимкненим за фіче-флагом, тоді деплой уже відбувся, а реліз — ще ні.
Hotfix — терміновий фікс критичної проблеми на prod, який їде скороченим шляхом: без повного циклу тестування, з перевіркою самого фікса й мінімальною регресією навколо нього. Hotfix — це завжди усвідомлений ризик в обмін на швидкість.

Поруч живуть ще два слова: release candidate — білд-кандидат, який стане релізом, якщо тестування не знайде блокерів, і rollback (відкат) — повернення попередньої версії, коли реліз пішов не так. А в номерах версій на кшталт 2.14.1 часто вгадується семантичне версіонування (semantic versioning): мажорна.мінорна.патч — зламні зміни, нова функціональність, виправлення.

Чому це словник QA, а не тільки DevOps: тестувальник щодня відповідає на питання «на якому білді відтворено баг» і «чи потрапив фікс у цей білд». Без прив'язки до білда результат тестування висить у повітрі — незрозуміло, що саме перевірено і чи актуальна перевірка після наступного деплою.

Статуси виконання: passed, failed, blocked, skipped

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

Статус	Що означає	Типовий приклад
passed	Фактичний результат збігся з очікуваним	Усі кроки пройдені, все як у кейсі
failed	Фактичний результат розійшовся з очікуваним	Замість сторінки підтвердження — помилка 500
blocked	Виконати неможливо через зовнішню перешкоду	Тестове середовище лежить; попередній крок зламаний дефектом
skipped	Свідомо не виконували	Функціональність вимкнена на цьому середовищі; кейс поза скоупом прогону

Ключова межа проходить не між «добре» і «погано», а між «виконали» і «не виконали»:

Два уточнення, на яких сипляться кандидати:

failed ≠ баг. Failed означає лише розбіжність з очікуванням. Перш ніж заводити дефект, перевіряють, чи не винні тест, дані або середовище: застарілий кейс, чужі дані, недодеплоєний білд. Якщо розбіжність підтверджена — далі баг-репорт, це тема глави Баг-репорт і життєвий цикл дефекту.
blocked ≠ skipped. Blocked — «хотіли виконати, але не змогли»: перешкода зовнішня, і коли її приберуть, тест повернеться у прогін. Skipped — «вирішили не виконувати»: рішення власне, причина — скоуп, конфігурація чи пріоритети. Позначити заблокований тест як skipped означає сховати проблему: у звіті ніхто не побачить, що частина функціональності лишилася неперевіреною не з наших міркувань, а через дефект чи зламаний стенд.

Конкретні назви статусів залежать від системи керування тестуванням (TMS): десь є окремі untested, in progress, retest. Це деталі інструмента — важлива логіка чотирьох базових станів.

І про сумарну цифру: pass rate 95% сам по собі не означає «майже готово». Пʼять відсотків failed можуть бути оплатою замовлення, а можуть — друкарською помилкою в футері. Статуси рахують, але рішення ухвалюють, дивлячись на те, ЩО саме впало і заблоковане, — про метрики і їхні пастки детальніше в главі Метрики тестування і звітність.

Звіт про результати і закриття циклу

Тестування — це сервіс, який постачає інформацію про якість, і звіт — його головний продукт. Наприкінці циклу (реліз, спринт, етап) команда тестування готує звіт про результати (test summary report, у термінах ISTQB — test completion report). Його читають люди, які не бачили жодного тест-кейсу, тож звіт відповідає на їхні питання, а не переказує прогін:

що перевірено, а що ні — скоуп і явний перелік неперевіреного з причинами (не встигли, було заблоковано);
зведення результатів — статуси, динаміка, порівняння з критеріями виходу (exit criteria) з тест-плану — самі критерії розібрані в главі про STLC;
відкриті дефекти — не кількістю, а сутністю: які саме, якої важливості, що з ними вирішили;
ризики — що може статися, якщо релізити з поточним станом;
відхилення від плану — що пішло не так і чому.

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

Після звіту цикл закривають (test completion): результати й тестові артефакти архівують із привʼязкою до версії, корисні кейси з прогону поповнюють регресійний набір — навіщо він і як живе, розказано в главі Смоук, саніті, регресія і ретест, — а команда фіксує висновки (lessons learned): що в процесі варто змінити до наступного циклу. Без закриття досвід циклу випаровується, і наступний реліз наступає на ті самі граблі.

Типові помилки

«На stage працює — значить, і на prod буде» — виглядає як логічний висновок, а насправді stage відрізняється конфігурацією, обсягом даних, кешем і навантаженням; тому після деплою на prod усе одно роблять смоук.
«Баг не відтворюється — закриваємо» — виглядає як плаваючий дефект, а насправді часто просто інше середовище, інший білд чи інші дані; спершу звіряють, де саме відтворювали.
Заблокований тест позначили skipped — виглядає як охайний прогін без «червоного», а насправді звіт приховав, що функціональність не перевірена через зламаний стенд чи блокуючий дефект.
Failed одразу конвертують у баг-репорт — виглядає як швидка реакція, а насправді чимала частина таких «багів» — застарілі кейси, чужі дані або недокачений білд; спершу перевір тест і середовище.
«Скопіюємо прод-базу на тест, буде реалістично» — виглядає як найкращі тестові дані, а насправді це персональні дані реальних людей на середовищі зі слабкими доступами; спершу знеособлення.
«Задеплоїли — отже, зарелізили» — виглядає як синоніми, а насправді деплой — технічна подія, реліз — продуктова; код на prod може тижнями жити вимкненим за фіче-флагом.

Підсумок

Середовища існують, щоб ловити проблеми якомога раніше й дешевше; чим ближче до prod, тим стабільніше, суворіше й дорожче помилятися. Результат тестування має сенс лише з привʼязкою «яке середовище, який білд».
Тестові дані готують під кейси, ізолюють між тестами й тестувальниками, а перед перенесенням із prod — знеособлюють: реалістичність не переважує приватність.
Білд — артефакт, деплой — встановлення білда на середовище, реліз — доступність користувачам, hotfix — терміновий фікс скороченим циклом. Це чотири різні речі, а не синоніми.
Failed — розбіжність з очікуванням (ще не баг), blocked — не змогли виконати через зовнішню перешкоду, skipped — свідомо не виконували. Плутанина в статусах спотворює картину прогону.
Звіт про результати — продукт тестування: скоуп, результати проти критеріїв виходу, дефекти й ризики. QA інформує про якість; рішення про реліз ухвалює бізнес.

Що питають на співбесіді

«Які середовища були на твоєму проєкті і чим відрізнялися?» — перевірка реального досвіду: завчений список dev/test/stage/prod без деталей видно одразу; сильна відповідь — про конкретні відмінності (дані, інтеграції, доступи) і як вони впливали на тестування.
«Чим blocked відрізняється від failed? А від skipped?» — інтервʼюер дивиться, чи розумієш різницю між «результат не збігся», «не зміг виконати» і «вирішив не виконувати», і чи згадаєш, навіщо ця різниця звіту.
«Чим реліз відрізняється від деплою?» — маркер реального проєктного досвіду; бонус — приклад із фіче-флагом: задеплоєно, але не зарелізено.
«Знайшли критичний баг на проді — ваші дії?» — очікують слово hotfix, розуміння скороченого циклу (перевірка фікса + мінімальна регресія навколо) і усвідомлення ризику такого шляху.
«Чому не можна просто скопіювати прод-базу на тестове середовище?» — перевірка, чи знаєш про персональні дані й знеособлення хоча б на рівні концепції.
«Тестування завершено — що далі? Хто вирішує, чи релізити?» — дивляться, чи розумієш роль QA: дати чесну картину якості, а не «дозволити» чи «заборонити» реліз.

Джерела

Силабус ISTQB CTFL 4.0 — розділ 1.4 (тестові активності, зокрема виконання і завершення тестування) і розділ 5.3 (моніторинг, контроль і завершення тестування, звіти про результати).
Глосарій ISTQB — канонічні означення термінів: test environment, test data, test completion report.
Semantic Versioning — специфікація семантичного версіонування, з якого походить схема «мажорна.мінорна.патч».
GDPR — Регламент (ЄС) 2016/679 — офіційний текст регламенту про захист персональних даних; контекст для деперсоналізації тестових даних.

Що таке тестове середовище і навіщо проєкту їх кілька?

Середовище (environment) — окрема інсталяція застосунку зі своїми серверами, базою та конфігурацією. Кілька їх тому, що будь-яка зміна коду потенційно щось ламає, і чим пізніше поломка виявиться, тим дорожче обійдеться — тож між «розробник написав код» і «користувач бачить фічу» будують ланцюжок зупинок. Кожна зупинка ловить свій клас проблем: dev — «код взагалі не працює», test — «фіча працює не так», stage — «у бойовій конфігурації все розвалюється», prod — те, що прослизнуло повз усіх. Практичний наслідок для QA: результат тестування має сенс лише з прив'язкою «яке середовище, який білд» — без цього незрозуміло, що саме перевірено.

Які середовища зазвичай є на проєкті і чим вони відрізняються?

Класичний ланцюжок: dev — для розробки й дебагу, нестабільний, з мінімальними синтетичними даними; test (QA) — основний обсяг тестування на підготовлених під кейси даних; stage (staging, preprod) — фінальна перевірка в умовах, максимально наближених до prod, часто саме тут проходить UAT; prod — живий продукт з реальними користувачами й реальними даними. Загальне правило: чим ближче середовище до prod, тим воно стабільніше, тим суворіші доступи й тим дорожче на ньому щось зламати. Важливо розуміти, що назви — не стандарт, а конвенція команди: десь є окремий UAT, десь sandbox чи demo, десь test і stage злиті в одне. На співбесіді цінують не завчений список, а розповідь про конкретні відмінності свого проєкту: дані, інтеграції, доступи — і як вони впливали на тестування.

Чим test-середовище відрізняється від prod, окрім того, що там немає користувачів?

Практично всім, і кожна відмінність — потенційне джерело «у нас працює, а на проді ні». Конфігурація: інші змінні оточення, ліміти й фіче-флаги — фіча, якої «немає» на test, може бути просто вимкнена прапорцем. Інтеграції: платіжка в тестовому режимі або заглушка, пошта не летить назовні, зовнішні API — часто моки, тоді як на prod усе справжнє. Дані: сотні записів проти мільйонів — пагінація, пошук і продуктивність поводяться зовсім інакше. Інфраструктура: на prod зазвичай є CDN, кешування, балансувальник навантаження, яких на test може не бути, — через кеш prod може ще довго показувати стару версію фронтенду після деплою. І доступи: на prod алерти, логи й обмежені права, «потикати руками в базі» там не вийде.

Чи тестують на prod? Що там можна, а чого не можна?

Тестування на prod існує, але воно мінімальне й обережне. Типовий приклад — смоук після релізу: швидко пройти критичні сценарії й переконатися, що деплой нічого не поклав. Обережність тут буквальна, а не риторична: тестове замовлення на prod проходить через справжню платіжну систему, а тестовий лист летить реальному користувачеві. Тому основний обсяг перевірок живе на test і stage, а prod лишається для контрольних проходів по критичному й для того, чого нижче не відтворити — реальних даних, реального навантаження, реальної інфраструктури.

Що таке тестові дані і як їх готують?

Тестові дані (test data) — стан системи, без якого перевірку не виконати: «користувач з роллю адміністратора», «товар із нульовим залишком», «підписка, що спливла вчора» — усе, що стоїть у передумовах кейсу. Готують їх двома способами: заздалегідь — набори облікових записів і сутностей «під кейси», які часто називають фікстурами (fixtures), — або генерують безпосередньо перед тестом. Заздалегідь — швидше на старті, але набори старіють і «роз'їжджаються» з реальністю; на льоту — надійніше, але кожен тест стає довшим. У ручному тестуванні зазвичай комбінують: базові акаунти живуть постійно, а специфічний стан створюється в передумовах конкретного кейсу.

Навіщо ізолювати тестові дані і що буває, коли цього не роблять?

Ізоляція означає, що кожен тест працює зі своїми даними й не залежить від чужих дій. Без неї результати починають залежати від порядку дій: два тестувальники (або ручний прогін і автотести) редагують той самий обліковий запис, тест А поміняв пароль — тест Б не може залогінитись. Найпідступніше, що це виглядає як баг застосунку, хоча застосунок ні до чого — час іде на розслідування примари. Найпростіший прийом ізоляції — унікальні дані на кожен прогін, наприклад email з таймстемпом: тести перестають зіштовхуватися, бо кожен створює власного користувача. Повна стратегія для автоматизації (сідінг бази, фабрики, очищення після прогону) — окрема тема, але принцип «свої дані на кожен тест» працює вже на рівні ручного тестування.

Чому не можна просто скопіювати базу з prod на тестове середовище?

Бо в прод-базі — персональні дані живих людей: імена, пошти, телефони, адреси, історія замовлень. Тестове середовище традиційно має слабші доступи, ніж prod, тож витік звідти — це справжній витік персональних даних з юридичними наслідками: у ЄС це регулює GDPR, в Україні — закон «Про захист персональних даних». Тому перед перенесенням дані знеособлюють: генерують синтетичні з нуля, анонімізують або псевдонімізують. Реалістичність даних — цінність, але вона ніколи не переважує приватність, тож на пропозицію «скинь мені дамп проду» правильна рефлекторна реакція — «а він знеособлений?».

Чим анонімізація відрізняється від псевдонімізації?

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

Чим білд відрізняється від деплою, а деплой — від релізу?

Це три різні речі, хоч у побутовій мові всі звучать як «нова версія». Білд (build) — зібраний з вихідного коду артефакт: конкретна версія застосунку з ідентифікатором (номер, хеш коміту), яку можна встановити; один білд може побувати на всіх середовищах по черзі. Деплой (deploy) — процес встановлення білда на конкретне середовище: «задеплоїли 2.14.0 на stage» — технічна дія, користувачі її не бачать. Реліз (release) — момент, коли функціональність стає доступна користувачам, і сама опублікована версія: деплой — технічна подія, реліз — продуктова. Класична ілюстрація різниці — фіче-флаг: код задеплоєно на prod, але тримається вимкненим, тоді деплой уже відбувся, а реліз — ще ні. Для QA це щоденний словник: «на якому білді відтворено баг» і «чи потрапив фікс у цей білд» — питання, без відповіді на які результат тестування висить у повітрі.

Що таке hotfix і чим його шлях відрізняється від звичайного релізу?

Hotfix — терміновий фікс критичної проблеми на prod, який їде скороченим шляхом: без повного циклу тестування, з перевіркою самого фікса й мінімальною регресією навколо нього. Звичайний реліз проходить увесь ланцюжок середовищ і повний обсяг перевірок; hotfix жертвує цим заради швидкості, бо кожна година лежачого prod коштує грошей і репутації. Ключове формулювання для співбесіди: hotfix — це завжди усвідомлений ризик в обмін на швидкість, а не «нормальний процес, тільки швидше». Роль QA тут — сфокусована перевірка: переконатися, що сам фікс працює, і пройти мінімальну регресію найближчої функціональності, чесно розуміючи, що решта лишилася неперевіреною.

Що таке release candidate і rollback?

Release candidate — білд-кандидат, який стане релізом, якщо тестування не знайде блокерів: тобто «ось цю версію ми плануємо випустити, перевірте її». Rollback (відкат) — повернення попередньої версії, коли реліз пішов не так: замість терміново чинити нове — швидко повернути старе робоче. Поруч варто знати семантичне версіонування (semantic versioning), яке вгадується в номерах на кшталт 2.14.1: мажорна.мінорна.патч — зламні зміни, нова функціональність, виправлення. Для тестувальника ці терміни — частина мови релізного процесу: смоук ганяють саме на release candidate, а рішення «фіксимо вперед чи котимо rollback» ухвалюють зокрема на підставі того, що QA знайшов після релізу.

Чим blocked відрізняється від failed? А від skipped?

Ключова межа проходить не між «добре» і «погано», а між «виконали» і «не виконали». Failed — тест виконали, і фактичний результат розійшовся з очікуваним: замість сторінки підтвердження — помилка 500. Blocked — виконати неможливо через зовнішню перешкоду: середовище лежить, попередній крок зламаний дефектом; «хотіли виконати, але не змогли», і коли перешкоду приберуть, тест повернеться у прогін. Skipped — свідомо не виконували: функціональність вимкнена на цьому середовищі, кейс поза скоупом прогону; рішення власне, а не вимушене. Різниця важить для звіту: позначити заблокований тест як skipped означає сховати проблему — ніхто не побачить, що частина функціональності лишилася неперевіреною через дефект чи зламаний стенд, а не з наших міркувань.

Тест упав зі статусом failed. Це вже баг? Що робити далі?

Ні, failed означає лише розбіжність фактичного результату з очікуваним — а винен у ній не обов'язково застосунок. Перш ніж заводити дефект, перевіряють три речі: чи не застарів сам кейс (очікуваний результат міг легально змінитися), чи не зіпсовані дані (хтось інший редагував той самий акаунт), чи те середовище й той білд (фікс міг ще не доїхати, деплой міг не завершитися). Чимала частина «багів» на цьому етапі виявляється проблемою тесту, даних або стенда. І тільки якщо розбіжність підтверджена на правильному середовищі з правильними даними — далі баг-репорт. Конвертувати failed у дефект автоматично — типова помилка початківця, яка засмічує баг-трекер і підриває довіру до QA.

Розробник каже «баг не відтворюється». Які перші кроки?

Перше, що треба з'ясувати, — чи відтворюєте ви його в однакових умовах, бо «не відтворюється» дуже часто означає «відтворюється, але не на твоєму середовищі». Звіряють три речі: яке середовище (баг міг жити тільки на test через моки чи інші дані), який білд (фікс або регресія могли приїхати з останнім деплоєм) і які дані (специфічний стан акаунта чи запису). Саме тому в баг-репорті поле «середовище» обов'язкове, а відтворення прив'язують до конкретного білда. Закривати дефект як «не відтворюється» без цієї звірки — типова помилка: плаваючим дефект часто лише виглядає, а насправді просто ніхто не порівняв умови.

Pass rate прогону 95% — можна релізити?

Сама по собі цифра на це питання не відповідає. П'ять відсотків failed можуть бути оплатою замовлення — і тоді реліз неможливий, а можуть — друкарською помилкою у футері, і тоді все гаразд. Плюс за межами pass rate ховаються blocked: якщо частина критичної функціональності заблокована і не перевірена взагалі, зелена цифра створює ілюзію готовності. Тому статуси рахують, але рішення ухвалюють, дивлячись на те, ЩО саме впало і що заблоковане: важливість функціональності, серйозність розбіжностей, ризики неперевіреного. Це стандартна пастка на співбесіді: очікують не «95 — це добре», а «покажіть мені список failed і blocked».

Що входить у звіт про результати тестування і хто ухвалює рішення про реліз?

Звіт про результати (test summary report, в ISTQB — test completion report) — головний продукт тестування як сервісу, і читають його люди, які не бачили жодного тест-кейсу. Тому він відповідає на їхні питання: що перевірено, а що ні — з причинами; зведення результатів проти критеріїв виходу з тест-плану; відкриті дефекти — не кількістю, а сутністю: які саме, якої важливості, що з ними вирішили; ризики релізу з поточним станом; відхилення від плану. Найважливіше: QA не ухвалює рішення про реліз — QA дає для нього інформацію. Рішення «випускаємо з цими багами чи ні» бізнесове, його ухвалює той, хто відповідає за продукт; роль тестувальника — щоб це рішення було поінформованим: чесний скоуп, чесні ризики, без прикрашання і без паніки. Після звіту цикл закривають: артефакти архівують із прив'язкою до версії, корисні кейси поповнюють регресійний набір, команда фіксує lessons learned — без цього наступний реліз наступає на ті самі граблі.

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

Кейс 1. «На моєму не відтворюється»: звірка перед суперечкою

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

Що звірити	Питання	Чому це важливо
Середовище	«Ти дивишся на test чи на dev?»	Інша конфігурація і фіче-флаги, інші інтеграції: на test платіжка може бути заглушкою, на dev — узагалі вимкнена. Баг може жити лише там, де інтеграція справжня чи мокнута інакше
Білд	«Який білд у тебе задеплоєний?»	Розробник часто дивиться на свіжіший код, ніж на стенді: фікс уже в нього локально, але ще не доїхав деплоєм. Порівнюють ідентифікатори — номер білда чи хеш коміту
Дані	«Яким акаунтом і на якому замовленні?»	Дефект може вимагати специфічного стану: підписка, що спливла вчора, товар з нульовим залишком. На «чистому» акаунті розробника передумова просто не виконується

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

Кейс 2. Таблиця рішень: який статус ставити

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

Ситуація	Статус	Чому
Усі кроки пройдені, результат як у кейсі	passed	Виконали, збіглося — єдиний випадок без нюансів
Замість сторінки підтвердження — помилка 500	failed	Виконали, результат розійшовся з очікуваним. Але це ще не баг — спершу перевірити кейс, дані, білд
Тестове середовище лежить, кейс не почати	blocked	Хотіли виконати — не змогли, перешкода зовнішня. Коли стенд піднімуть, кейс повернеться у прогін
Крок 3 неможливий: кнопку зламано дефектом з іншого кейсу	blocked	Та сама логіка: перешкода зовнішня (блокуючий дефект), а не наше рішення
Функціональність вимкнена фіче-флагом на цьому середовищі	skipped	Свідоме рішення не виконувати: перевіряти вимкнене — безглуздо, причина конфігураційна
Кейс про експорт у PDF, а прогін — смоук критичних сценаріїв	skipped	Поза скоупом прогону — власне рішення, не перешкода
Кейс застарів: очікуваний результат уже не відповідає вимогам	failed, але без баг-репорту	Розбіжність є, тож формально це failed — але розбір показує, що винен тест, а не застосунок: кейс іде на актуалізацію, а не в дефекти

Найдорожча помилка з цієї таблиці — позначити заблоковані кейси як skipped, щоб прогін виглядав «охайно, без червоного». У звіті ніхто не побачить, що частина функціональності не перевірена через зламаний стенд чи блокуючий дефект, — і рішення про реліз ухвалять на неповній картині.

Кейс 3. Ізоляція тестових даних: чому фіксований email — це флак

Симптом: тест реєстрації зелений на першому прогоні й червоний на всіх наступних. Або ще веселіше: локально зелений, у CI — червоний, «баг застосунку». Дивимось у тест:

// Антипатерн: фіксований email — другий прогін впаде на «email уже зайнятий»
await page.getByLabel('Email').fill('qa-test@example.com');

Перший прогін створив користувача — і назавжди зайняв цей email. Другий прогін чесно отримує від застосунку відмову «такий користувач уже існує», тест червоніє, хоча застосунок працює правильно. Той самий механізм б'є і по ручному тестуванню: два тестувальники редагують один обліковий запис, тест А поміняв пароль — тест Б не може залогінитись.

Лікування — унікальні дані на кожен прогін:

// Унікальний email на кожен запуск — прогони не зіштовхуються
const email = `qa+${Date.now()}@example.com`;
await page.getByLabel('Email').fill(email);
await page.getByRole('button', { name: 'Зареєструватися' }).click();
// Асертимо на дані ЦЬОГО прогону, а не на глобальний стан
await expect(page.getByText(email)).toBeVisible();

Що тут дивитися і чому:

Унікальність робить тест незалежним від історії. Скільки б разів прогін не запускався і скільки б людей не працювали на тому самому середовищі — кожен запуск створює власного користувача й нікому не заважає.
Ознака проблеми ізоляції — залежність від порядку. Тест падає лише після іншого тесту, лише на другому прогоні, лише в CI з паралельними воркерами — це майже завжди спільні дані, а не баг застосунку.
Це концепція, а не повний рецепт. Доросла стратегія тестових даних для автоматизації — сідінг бази, фабрики, очищення після прогону — окрема тема; але правило «свої дані на кожен тест» окупається вже з першого флаку, який не довелося розслідувати.

Середовища

Знаю призначення dev, test, stage і prod: кожна зупинка ловить свій клас проблем, і чим раніше — тим дешевше.
Розумію, що назви середовищ — конвенція команди, а не стандарт; важить призначення, а не завчений список.
Можу перелічити, чим середовища різняться насправді: конфігурація і фіче-флаги, інтеграції (моки vs справжні платіжки й пошта), обсяг даних, інфраструктура (CDN, кеш, балансувальник), моніторинг і доступи.
Розумію, чому «баг не відтворюється» найчастіше означає «інше середовище, інший білд або інші дані» — і що звіряти першим.
Знаю, що тестування на prod існує, але обмежене (смоук після релізу) і буквально обережне: тестове замовлення йде через справжню платіжку.

Тестові дані

Знаю два способи підготовки: фікстури заздалегідь vs генерація перед тестом — і компроміс кожного (швидкість старту vs старіння наборів).
Можу пояснити, навіщо ізоляція даних і як унікальні дані на прогін (email з таймстемпом) прибирають зіткнення тестів, що виглядають як баги.
Розумію, чому копія прод-бази на test — це витік персональних даних з юридичними наслідками (GDPR, закон «Про захист персональних даних»).
Знаю різницю: синтетичні дані vs анонімізація vs псевдонімізація — і чому псевдонімізовані дані досі треба вважати персональними.

Білд, деплой, реліз

Можу розвести чотири терміни: білд — артефакт з ідентифікатором (без привʼязки до нього результат тестування висить у повітрі), деплой — встановлення білда на середовище, реліз — доступність користувачам, hotfix — терміновий фікс скороченим циклом.
Наведу приклад «задеплоєно, але не зарелізено»: код на prod за вимкненим фіче-флагом.
Розумію, чому hotfix — усвідомлений ризик: перевірка самого фікса плюс мінімальна регресія замість повного циклу.
Знаю терміни поруч: release candidate, rollback, семантичне версіонування (мажорна.мінорна.патч).

Статуси виконання

Знаю чотири базові статуси і що межа проходить між «виконали» і «не виконали», а не між «добре» і «погано».
Можу пояснити, чому failed ≠ баг і що перевірити перед баг-репортом: актуальність кейсу, чужі дані, недодеплоєний білд.
Розрізняю blocked («хотіли, але не змогли — перешкода зовнішня») і skipped («свідомо не виконували») і чому підміна blocked на skipped ховає проблему у звіті.
Розумію, чому pass rate 95% сам по собі не означає «майже готово»: рішення ухвалюють, дивлячись на те, ЩО саме впало і заблоковане.

Звіт і закриття циклу

Знаю структуру звіту про результати: скоуп і неперевірене з причинами, результати проти критеріїв виходу, дефекти сутністю, ризики, відхилення від плану.
Можу пояснити принцип «QA не ухвалює рішення про реліз — QA дає для нього інформацію»; рішення бізнесове.
Знаю, що відбувається при закритті циклу (test completion): архівація артефактів з прив'язкою до версії, поповнення регресійного набору, lessons learned.