STLC: життєвий цикл тестування

Що таке STLC і навіщо він потрібен?

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

Назвіть фази STLC. Що на виході кожної?

Пʼять фаз: аналіз вимог → планування → дизайн тестів → виконання → закриття. Вихід аналізу — тестові умови (що перевірятимемо) і зауваження до вимог; вихід планування — тест-план з оцінкою та entry/exit criteria; вихід дизайну — пріоритизовані тест-кейси або чеклисти плюс тестові дані; вихід виконання — результати прогонів і баг-репорти; вихід закриття — підсумковий звіт і lessons learned. Кожен вихід — це вхід наступної фази, тому пропуск однієї ланки бʼє по всіх подальших: без тестових умов нема з чого дизайнити кейси, без кейсів виконання перетворюється на хаотичне клікання. У класичних шестифазних описах перед виконанням стоїть ще окрема фаза підготовки тестового середовища (test environment setup) — на співбесіді її варто згадати.

Коли починається робота тестувальника — з появи білда?

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

Що таке тестопридатність вимоги? Наведіть приклад нетестопридатної вимоги.

Тестопридатність (testability) — властивість вимоги, яка дозволяє однозначно перевірити, виконана вона чи ні. Класичний приклад нетестопридатної вимоги — «пароль має бути надійним»: неможливо написати перевірку на «надійність», бо критерій не визначений. Після уточнення в аналітика вона перетворюється на вимірну — «мінімум 8 символів, хоча б одна літера і одна цифра», — і з неї вже народжуються конкретні тестові умови: «пароль із 7 символів відхиляється», «пароль без цифр відхиляється». Оцінка тестопридатності — одна з головних робіт фази аналізу вимог: тестувальник читає вимоги не як розробник («як це зробити»), а через призму «як це перевірити і де це зламається».

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

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

Які рішення ухвалюються на фазі планування? Що таке тест-план?

Планування відповідає на питання «як тестуватимемо»: обсяг (що тестуємо, а що свідомо ні — і чому), підхід (рівні й види тестування, що автоматизуємо), ресурси й ролі (хто, на яких середовищах, з якими даними), строки й оцінка, ризики і план дій, якщо часу забракне, та критерії входу і виходу для наступних фаз. Вихід фази — тест-план (test plan). Це не обовʼязково 40-сторінковий документ: у більшості Agile-команд це сторінка у вікі або секція в тікеті. Форма не важлива — важливо, що рішення ухвалені й зафіксовані до старту, а не заднім числом. Саме на цій фазі визначаються entry/exit criteria: критерій, написаний в останній день, завжди «магічно» збігається з тим, що встигли.

Що відбувається на фазі дизайну тестів, крім написання кейсів?

Основна робота — перетворити тестові умови на готові до виконання кейси або чеклисти, але це не все. По-перше, готуються тестові дані: акаунти, товари, платіжні картки-заглушки — усе, без чого кейс не запустити. По-друге, пріоритизація: які перевірки критичні й виконуються першими, а які можна відкласти чи зрізати за браку часу — це рятує, коли строки стискаються. По-третє, трасування: кожна вимога має бути покрита хоча б однією перевіркою, і звʼязок «вимога → тест» фіксується в матриці трасування вимог (requirements traceability matrix, RTM). Вихід фази — пріоритизований набір кейсів/чеклистів плюс підготовлені дані, тобто все для того, щоб виконання стартувало без пауз «а де взяти тестовий акаунт».

З чого складається фаза виконання тестів?

Це єдина фаза, для якої потрібен білд, і вона починається зі звірки з критеріями входу: білд розгорнуто, середовище живе, кейси готові. Далі рутина: швидкий смоук — чи взагалі має сенс тестувати цей білд; прогін кейсів за пріоритетом із фіксацією статусів passed, failed, blocked, skipped; на кожен failed — баг-репорт; ретест виправлених дефектів і регресія довкола змін. Вихід фази — результати прогонів, заведені дефекти й оновлені кейси: реальність часто коригує очікувані результати, написані по вимогах. Нюанс, який цінують на співбесіді: перед виконанням у повній моделі стоїть підготовка середовища — розгорнути стенд, налити дані, перевірити доступи, — і без неї «день тестування» перетворюється на день боротьби зі стендом.

Що таке entry/exit criteria? Наведіть приклади.

Критерії входу (entry criteria) — вимірні умови, за яких фазу можна починати; критерії виходу (exit criteria) — умови, за яких її можна вважати завершеною. Це ворота між фазами: entry захищає від «тестування» білда, який не проходить смоук (день спалюється на репортування того, що розробка й так знає), exit — від тестування «доки не скінчиться час». Типові entry для фази виконання: білд розгорнуто на тестовому середовищі, смоук-набір пройдено, кейси готові й проревʼювані, тестові дані та доступи підготовлені. Типові exit: 100% запланованих кейсів виконано, немає відкритих дефектів рівня critical/blocker, пріоритетні вимоги покриті виконаними тестами, підсумковий звіт підготовлено. Два правила робочих критеріїв: вимірність («якість достатня» — не критерій, «немає відкритих critical» — критерій) і визначення заздалегідь, на фазі планування. Абстрактна відповідь без конкретних прикладів на співбесіді — червоний прапорець.

Коли можна завершити тестування?

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

Чи означає завершення тестування, що всі знайдені дефекти виправлені?

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

Навіщо потрібна фаза закриття, якщо реліз уже відбувся?

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

Чим SDLC відрізняється від STLC?

SDLC — життєвий цикл усього продукту: від ідеї до підтримки, з усією командою і артефактами від вимог до релізу. STLC охоплює лише процес тестування, його мета — знайти дефекти й дати команді чесну картину якості, ключові артефакти — тест-план, тест-кейси, баг-репорти, підсумковий звіт. Головне слово у відповіді — «вкладений»: STLC не йде «після розробки» і не існує паралельно сам по собі, кожна його фаза синхронізована з відповідною фазою SDLC. Аналіз вимог у STLC відбувається тоді ж, коли команда працює над вимогами в SDLC; дизайн тестів — поки пишеться код. У V-моделі ця відповідність намальована буквально: кожній фазі розробки дзеркально відповідає свій рівень тестування. Відповідь «SDLC — про розробку, STLC — про тестування» без слова про синхронізацію — половина відповіді.

Як STLC виглядає в Agile? Він там взагалі існує?

Існує — він не зникає, а стискається до масштабу ітерації. У кожному спринті для кожної user story проходять ті самі фази: аналіз вимог, планування, дизайн, виконання, закриття — тільки за години й дні, а не тижні. Фази при цьому активно перекриваються: поки одна фіча тестується, для наступної вже аналізуються вимоги. Роль entry/exit criteria в Agile виконують Definition of Ready і Definition of Done — ISTQB 4.0 прямо ставить між ними знак відповідності. Відповідь «в Agile процесів немає» на співбесіді — миттєвий мінус: інтервʼюер перевіряє саме гнучкість мислення, розуміння, що фази — логічна послідовність, а не календарний водоспад.

Що таке моніторинг і контроль тестування і чому ISTQB не вважає їх окремою фазою?

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

Три кейси, які перетворюють схему з пʼяти фаз на робочий інструмент: одна user story, проведена через увесь цикл з артефактами кожної фази; таблиця рішень «критерій спрацював — що робимо» для типових конфліктів довкола entry/exit criteria; і мапа двотижневого спринта, яка показує, куди фази STLC діваються в Agile (спойлер: нікуди).

Кейс 1. Одна user story через пʼять фаз

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

Аналіз вимог. Білда немає, є лише story і макет. Читаємо через призму «як це перевірити і де зламається» — і одразу знаходимо дірки: що буде, якщо ввести email, який уже зайнятий іншим акаунтом? скільки живе посилання підтвердження? що станеться, якщо користувач запросив зміну двічі поспіль на різні адреси? Це питання аналітику — найдешевші «баг-репорти» циклу. Після відповідей складаємо тестові умови, ще без кроків:

• зміна на вільний email — лист приходить, до підтвердження діє старий;
• зміна на зайнятий email — відхиляється зі зрозумілою помилкою;
• протерміноване посилання підтвердження — не спрацьовує;
• повторний запит зміни — інвалідовує попереднє посилання;
• невалідний формат email — відхиляється на валідації.

Планування. Фіксуємо в тікеті секцію: тестуємо на стейджі з тестовим SMTP (реальні листи не шлемо — дивимось у поштову заглушку), негативні перевірки формату — руками один раз, основний флоу піде в регресію. Entry criteria для виконання: білд на стейджі, смоук пройдено, заглушка пошти доступна. Exit criteria: усі кейси виконано, немає відкритих critical.

Дизайн. Тестові умови розгортаються в кейси з кроками. Готуємо дані: два акаунти (основний і «власник зайнятого email»), доступ до поштової заглушки. Пріоритизуємо: основний флоу і «зайнятий email» — перший пріоритет, протерміноване посилання — другий. Кожна умова трасується до story — покриття видно без археології.

Виконання. Смоук білда — ок, можна починати. Прогін за пріоритетом: основний флоу passed; «зайнятий email» failed — система мовчки приймає дублікат, заводимо баг; «повторний запит» blocked — залежить від того самого дефекту. Після фіксу — ретест бага, регресія довкола зміни, статуси оновлено.

Закриття. У коментарі до story: 5 кейсів, 4 passed, 1 дефект знайдено і виправлено, відкритих critical немає — exit criteria виконано. Кейс основного флоу переїжджає в регресійний набір. Lessons learned одним рядком: питання про зайнятий email треба було ставити на groomingу — дефект був закладений ще у вимогах.

Кейс 2. Ворота в дії: таблиця рішень за entry/exit criteria

Критерії пишуться на плануванні, а працюють у момент конфлікту — коли є тиск «та почнімо вже» або «та релізьмо вже». Типові ситуації і рішення, які з критеріїв випливають:

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

Кейс 3. Куди діваються фази у двотижневому спринті

Питання «а в Agile ваш STLC ще існує?» найкраще розбирати на календарі реального спринта. Фази не зникають — вони стискаються до масштабу однієї story і накладаються одна на одну:

Два висновки для співбесіди. Перший: у спринті одночасно живуть кілька story на різних фазах — одна у виконанні, друга в дизайні, третя в аналізі; саме це мають на увазі слова «фази перекриваються». Другий: lessons learned у Scrum нікуди не зникли — вони називаються ретроспективою, а entry/exit criteria — Definition of Ready і Definition of Done. Змінилися назви й масштаб, не суть.

Фази та артефакти

• Знаю пʼять фаз STLC у порядку: аналіз вимог → планування → дизайн тестів → виконання → закриття.
• Розумію ключову ідею моделі: у кожної фази є вхід, діяльність і вихід-артефакт — і можу назвати ланцюжок виходів: тестові умови → тест-план → тест-кейси й тестові дані → результати прогонів і баг-репорти → підсумковий звіт.
• Знаю, що білд потрібен лише для фази виконання: три фази з пʼяти відбуваються до того, як зʼявиться що запускати.
• Памʼятаю, що в класичних шестифазних описах перед виконанням стоїть окрема фаза підготовки тестового середовища (test environment setup).
• Розумію, що фази — логічна послідовність, а не календарний водоспад: вони перекриваються й повторюються (поки одна фіча у виконанні, друга — у дизайні).

Ранні фази: аналіз, планування, дизайн

• Можу пояснити тестопридатність (testability) на прикладі: «пароль має бути надійним» — нетестопридатна вимога, «мінімум 8 символів, літера і цифра» — тестопридатна.
• Знаю різницю: тестова умова — «що перевіряємо» (без кроків, з фази аналізу), тест-кейс — «як саме» (кроки й очікуваний результат, з фази дизайну).
• Розумію, чому питання аналітику на фазі аналізу — найдешевший «баг-репорт» усього циклу.
• Можу перелічити рішення фази планування: scope, підхід, ресурси й ролі, строки, ризики, entry/exit criteria — і знаю, що тест-план не зобовʼязаний бути 40-сторінковим документом.
• Знаю, що на дизайні крім кейсів готують тестові дані, пріоритизують перевірки і трасують їх до вимог через матрицю трасування (RTM).

Entry/exit criteria

• Можу дати означення: entry criteria — вимірні умови, за яких фазу можна почати; exit criteria — умови, за яких її можна вважати завершеною.
• Знаю конкретні приклади для фази виконання: вхід — білд розгорнуто, смоук пройдено, кейси проревʼювані; вихід — 100% запланованих кейсів виконано, немає відкритих critical/blocker.
• Знаю два правила робочих критеріїв: вимірність («якість достатня» — не критерій) і визначення заздалегідь на фазі планування, а не по факту.
• Можу пояснити, чому exit criteria майже ніколи не означають «усі дефекти виправлені»: відомі мінорні баги їдуть у реліз свідомо, з оцінкою ризиків і фіксацією у звіті.
• Знаю Agile-аналог критеріїв: Definition of Ready і Definition of Done (ISTQB 4.0 прямо ставить знак відповідності).
• Можу відповісти на питання-пастку «коли можна завершити тестування»: не «коли все перевірено» (вичерпне тестування неможливе), а коли виконані заздалегідь визначені exit criteria.

Закриття, SDLC vs STLC, Agile

• Можу назвати три складові фази закриття: підсумковий звіт (test summary report / test completion report), lessons learned, актуалізація регресійного набору — і розумію, що без них цикл не завершується, а обривається: досвід губиться, набір кейсів гниє.
• Можу пояснити різницю SDLC і STLC через слово «вкладений»: STLC — не окремий паралельний процес, а розгортка тестувальної частини SDLC, синхронізована з ним по фазах (у V-моделі — буквально дзеркально).
• Знаю, що в Agile STLC не зникає — стискається до масштабу спринта, фази проходять для кожної user story і перекриваються.
• Розумію, що моніторинг і контроль за ISTQB — наскрізна активність усього циклу (звірка прогресу з планом і коригування), а не окрема фаза в черзі.