Тест-план і стратегія тестування

Що таке тест-план і що в ньому має бути?

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

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

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

Що таке тестова політика і тестовий підхід? Як вони співвідносяться зі стратегією і планом?

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

Які типи тестових стратегій виділяє ISTQB?

ISTQB розрізняє кілька типів; п'ять, які варто вміти назвати: аналітична — обсяг тестування виводиться з аналізу, найчастіше ризиків (що ризикованіше, те тестуємо глибше); методична — систематичне застосування стандартних наборів перевірок: чеклистів, таксономій дефектів; регресійно-обережна (regression-averse) — головний страх зламати наявне, тому ставка на автоматизовану регресію і повторне використання тестів; реактивна — тести проєктуються під час виконання за фактом знахідок, основа — exploratory; процесно-відповідна (process-compliant) — тестуємо так, як велить зовнішній стандарт чи регулятор (медицина, авіоніка, фінанси). Важливо додати: у реальних командах стратегія майже завжди гібридна — автоматизована регресія плюс ризик-орієнтований скоуп нових фіч плюс exploratory там, де вимоги тонкі.

Що таке master test plan і чим він відрізняється від планів рівнів?

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

Навіщо тест-плану розділ «поза скоупом» (features not to be tested)?

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

Що таке критерії входу і виходу? Що грає їхню роль в Agile?

Критерії входу (entry criteria) кажуть, коли фазу тестування можна починати: білд задеплоєний, вимоги тестопридатні, дані й середовище готові. Критерії виходу (exit criteria) — коли фазу можна вважати завершеною: заплановані тести виконані, покриття досягнуте, немає відкритих критичних дефектів. Сенс обох — прибрати суперечки «можна вже починати?» і «можна вже релізити?» з зони емоцій у зону домовленостей. В Agile-командах роль entry-критеріїв грає Definition of Ready, а exit-критеріїв — Definition of Done: зміст той самий, форма інша.

Чим критерії призупинення відрізняються від критеріїв виходу?

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

Чому оцінювати тестування важче, ніж розробку?

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

Які техніки оцінки тестування знаєш?

Зручно групувати їх у три родини. Перша — оцінка за історичними даними: за співвідношенням (ratios) — з історії організації відомо, що тестування коштує, скажімо, 40% зусиль розробки; та екстраполяція — міряємо фактичні витрати в перших ітераціях і продовжуємо тренд; сильні фактами, але потребують накопиченої історії. Друга — експертна оцінка: оцінюють ті, хто робитиме роботу; канонічний формат — Wideband Delphi, полегшена командна версія — planning poker. Третя — триточкова оцінка (three-point estimation) з формулою зваженого середнього. Практичне правило: техніки комбінують — беруть експертну оцінку і звіряють з історичним співвідношенням; якщо розійшлися вдвічі, це привід шукати, чого не врахували, а не всереднювати.

Розкажи, як працює триточкова оцінка (three-point estimation).

Замість одного числа даємо три: оптимістичне O (все йде ідеально), найімовірніше M і песимістичне P (усе, що могло піти не так, пішло). Далі зважена формула: очікувана оцінка E = (O + 4×M + P) / 6, стандартне відхилення SD = (P − O) / 6. Приклад: оцінили фічу як O = 5, M = 8, P = 17 людино-днів — тоді E = (5 + 32 + 17) / 6 = 9, SD = 2, і відповідь менеджеру звучить «9±2 дні», тобто чесний діапазон від 7 до 11. Формула навмисно тягне оцінку до найімовірнішого значення (вага 4), але песимістичний хвіст не дає їй бути наївною. На співбесіді вміння назвати формулу і порахувати приклад — помітний плюс.

Що таке Wideband Delphi і навіщо там анонімність першого раунду?

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

Що треба врахувати при плануванні ресурсів тестування, крім людей?

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

У вас Scrum і тест-планів немає. Означає, що планування тестування теж немає?

Це питання-пастка: зміст планування нікуди не зникає, зникає лише окремий документ. Скоуп тестування обговорюється на plannings, ризики — на refinement, entry-критерії живуть у Definition of Ready, exit-критерії — у Definition of Done, а скоуп регресії визначається ризик-орієнтовано. ISTQB 4.0 явно виносить участь тестувальника в плануванні релізу та ітерації як окрему активність. Практичний наслідок: тестувальник, який мовчить на плануванні, а потім скаржиться, що «на тестування не залишили часу», — сам пропустив момент, коли цей час закладався. Відповідь «в Agile план не потрібен» — червоний прапорець для інтерв'юера.

Коли тест-план має бути формальним документом, а коли досить сторінки у вікі?

Форма плану — функція контексту, а не якості команди. Формальний документ потрібен там, де його читає зовнішня сторона: регульовані домени (медичне ПЗ, авіоніка, фінанси), аутсорс-контракти, де план — частина угоди, сертифікаційні аудити; тут доречні шаблони ISO/IEC/IEEE 29119-3, версіонування і підписи погодження. Для продуктової команди норма — одна сторінка у вікі на реліз: скоуп, поза скоупом, ризики, підхід, оцінка, критерії, відповідальні. Критерій вибору простий: план мають читати — документ, який відкривали двічі (автор і аудитор через рік), не працює як інструмент комунікації, скільки б розділів за IEEE 829 у ньому не було. І в обох формах план — живий артефакт: змінився скоуп чи поповзла оцінка — план оновлюється, інакше він починає брехати.

Менеджер питає: «Скільки днів треба на тестування фічі?» Чому відповідь одним числом — погана і як відповісти правильно?

Одне число без допущень — це обіцянка, яку порушить перший же блокер, бо тривалість тестування залежить від кількості багів у білді, а її наперед не знає ніхто. Правильна відповідь — діапазон плюс явні допущення: «за нашою оцінкою 9±2 дні, за умови що стенд готовий у понеділок, а критичних багів буде не більше п'яти». Це не перестраховка, а інженерна чесність: допущення показують, за яких умов оцінка валідна, і заздалегідь легалізують перегляд строків, якщо умови зламалися. Різниця між «тижня два, мабуть» і оцінкою з допущеннями — це різниця між виконавцем, якому дедлайн спустять згори, та інженером, який керує своєю частиною проєкту.

Уяви: тобі дали нову фічу і два тижні. Як спланував би тестування?

Тут перевіряють структуру мислення, а не готовий шаблон, тому відповідь має пройти по ключових рішеннях плану. Спочатку тестова основа і скоуп: з вимог, макетів і специфікацій виводжу, що саме перевіряємо, і явно фіксую, що поза скоупом — з погодженням стейкхолдерів. Далі ризики: де логіка нова чи вимоги мінялись — туди більше глибини (ризик-орієнтований підхід), плюс проєктні ризики на кшталт спільного стенду. Потім оцінка: декомпозиція на перевірки, врахування циклів «баг → фікс → ретест», three-point для діапазону — і озвучення з допущеннями. Далі критерії: виходу (вимірні — «0 відкритих критичних, середні погоджені з PO») і призупинення (фейл смоуку, лежачий стенд). Наприкінці ресурси й залежності: хто що робить, коли готовий стенд і білд, де буфер. Усе це — на одній сторінці у вікі, яка оновлюється, коли реальність розходиться з планом.

Три кейси з робочого життя QA: скласти план на одну сторінку для нової фічі, дати менеджеру оцінку через three-point і не зламатись, коли за три дні до релізу ліг стенд. Скрізь — які рішення приймаються і чому саме вони, а не документ, є тест-планом.

Кейс 1. «Фіча і два тижні»: план на одну сторінку вікі

Команді віддали фічу «експорт звітів у PDF» у реліз 3.2, на тестування — два тижні. Замість шаблону на 16 розділів QA сідає і приймає рішення в такому порядку.

Тестова основа → скоуп. З вимог і макетів виводимо, що перевіряємо: генерація PDF для трьох типів звітів, права доступу до експорту, поведінка на великих звітах. Плюс регресія модуля звітів — фіча чіпає спільний код рендерингу.

Анти-скоуп. Експорт у Excel відкладений на 3.3 (фіча-флаг вимкнено) — явно пишемо «поза скоупом» і погоджуємо з PO. Тепер баг у Excel-гілці після релізу — прийнятий ризик, а не пропуск QA.

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

Оцінка, критерії, люди. Оцінка діапазоном з допущеннями (розбір у кейсі 2), критерії виходу — вимірні, призупинення — окремим рядком. Результат:

Тест-план: реліз 3.2 (експорт звітів у PDF)

Скоуп:        експорт 3 типів звітів, права доступу, великі звіти (1000+ рядків);
              регресія модуля звітів (сюїта smoke + reports)
Поза скоупом: експорт у Excel (фіча-флаг вимкнено до 3.3) — погоджено з PO 12.05
Ризики:       нова версія PDF-бібліотеки; вимоги до шаблону мінялись двічі;
              staging спільний з командою billing (наші вікна після 14:00)
Оцінка:       8±2 л/д (three-point; допущення: білд у вт, критичних багів ≤ 5)
Критерії виходу: сюїти виконані на 100%, критичних/високих — 0 відкритих,
              середні погоджені з PO
Призупинення: фейл смоуку або недоступність сервісу генерації PDF понад 2 год
Люди:         Ірина — функціональні перевірки, Тарас — регресія + права доступу

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

• Кожен рядок — рішення, а не розділ шаблону. «Поза скоупом» з датою погодження, ризики з причинами, оцінка з допущеннями. Заповнюючи рядок «ризики», довелося подумати про ризики — у цьому половина цінності планування.
• Анти-скоуп погоджений, а не просто записаний. Без підпису PO це особиста думка QA; з погодженням — усвідомлено прийнятий командою ризик.
• Критерії виходу вимірні. Не «багів немає» (недосяжно — отже, декорація), а «0 критичних відкритих, середні погоджені» — це можна перевірити і цим можна аргументувати реліз.
• План живий. Якщо вимоги до шаблону зміняться втретє — оновлюється скоуп і оцінка, інакше сторінка почне брехати всім, хто її відкриє.

Кейс 2. Триточкова оцінка: від декомпозиції до «8±2»

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

Крок 1 — декомпозиція. Функціональні перевірки трьох типів звітів, негативні кейси і права доступу, великі звіти, регресія модуля. На чистому білді це приблизно 4 людино-дні чистого виконання.

Крок 2 — три сценарії. Оптимістичний O = 4: білд чистий, стенд не падає. Найімовірніший M = 7: звична кількість багів, кілька циклів «репорт → фікс → ретест». Песимістичний P = 16: PDF-бібліотека сиплеться на великих звітах, вимоги до шаблону знову міняються, стенд у вікнах.

Крок 3 — формула.

E  = (O + 4×M + P) / 6 = (4 + 28 + 16) / 6 = 8    людино-днів
SD = (P − O) / 6       = (16 − 4) / 6     = 2

Відповідь менеджеру: «8±2 людино-дні — тобто від 6 до 10, за умови що білд у вівторок і критичних багів не більше п'яти».

Крок 4 — звірка з історією. Розробка фічі оцінена у 20 людино-днів; в організації тестування історично коштує близько 40% зусиль розробки — це теж 8 л/д. Дві незалежні техніки зійшлися — оцінці можна вірити. Якби ratios дав 16, а three-point — 8, це не привід брати середнє 12, а привід шукати, чого не врахували: можливо, у 20 днях розробки сидить міграція даних, яку теж доведеться тестувати.

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

• Песимістичний сценарій — не «все помножити на два», а перелік конкретних речей, які можуть піти не так: саме він змушує згадати про нову бібліотеку і спільний стенд. Вага 4 при M тягне оцінку до реалістичного, хвіст P не дає їй бути наївною.
• Допущення — частина оцінки, а не дрібний шрифт. «Білд у вівторок» і «критичних ≤ 5» — умови валідності: якщо білд приїхав у четвер, перегляд строків легалізований заздалегідь, без виправдовувань.
• Цикли баг-фікс-ретест сидять у різниці між O і M. Чисте виконання — 4 дні; усе понад це — вартість дефектів, якої не буває в оцінці «за кількістю тест-кейсів».

Кейс 3. Стенд ліг за три дні до релізу: критерій призупинення в дії

Середа, до релізу три дні. Ранковий смоук червоний: сервіс генерації PDF віддає помилки, лежить уже другу годину. Половина команди за інерцією «дотискає» перевірки, які ще якось відкриваються.

У плані з кейсу 1 записано: «Призупинення: фейл смоуку або недоступність сервісу генерації PDF понад 2 год». Далі — не суперечка, а процедура:

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

• Записаний критерій перетворює конфлікт на процедуру. Без нього рішення «зупиняємось чи мучимось» приймається в середу під тиском і емоційно; з ним — «за планом ми призупиняємо і повідомляємо, ось лист». Саме тому критерії призупинення пишуть заздалегідь, а не в момент пожежі.
• Призупинення — не вихід. Команда не «завершила фазу», їй тимчасово безглуздо працювати: більшість перевірок заблоковано. Плутанина цих понять — типова помилка, яку ловлять на співбесідах.
• Відновлення дзеркальне, але не тотожне паузі. Спершу ретест самого фікса і повторний смоук; а якщо фікс зачепив спільний код — частина зелених результатів середи більше нічого не гарантує, їх перепроганяють.
• План оновлюється після інциденту. «8±2» спиралось на допущення, яке зламалось; мовчки залишити стару оцінку на сторінці — значить брехати всім, хто відкриє план у п'ятницю.

Ієрархія артефактів

• Знаю ланцюжок: політика (навіщо тестуємо) → стратегія (як тестуємо взагалі) → підхід (як у цьому проєкті) → план (хто, що, коли конкретно).
• Можу пояснити різницю термінів життя: стратегія живе роками на рівні організації і не знає про конкретний реліз; план — тижні–місяці, до кінця релізу.
• Можу назвати типи стратегій за ISTQB — аналітична, методична, регресійно-обережна, реактивна, процесно-відповідна — і сказати, що в реальних командах стратегія майже завжди гібридна.
• Знаю, що таке master test plan поряд із планами рівнів і чому в невеликій продуктовій команді все схлопується в один документ — і це нормально.

Вміст і сенс тест-плану

• Розумію, що тест-план — це зафіксовані рішення, а не документ; половина цінності виникає в самому процесі планування.
• Можу перелічити типовий вміст за ISTQB CTFL 4.0: контекст і скоуп, допущення й обмеження, стейкхолдери, реєстр ризиків (продуктових і проєктних), підхід, бюджет і розклад.
• Можу пояснити, чому «поза скоупом» — найнедооціненіший розділ: баг у явно виключеній і погодженій зоні — усвідомлено прийнятий ризик, а не провал QA.
• Знаю, що структуру плану історично диктував IEEE 829, а сучасний стандарт — ISO/IEC/IEEE 29119-3; знаю назви, але не заучую 16 розділів — важливіші питання, які план закриває.

Критерії

• Знаю різницю критеріїв входу (коли можна починати фазу) і виходу (коли вона завершена) та що в Agile їхню роль грають Definition of Ready і Definition of Done.
• Знаю різницю «критерії призупинення vs критерії виходу»: «пауза, тестувати безглуздо» проти «фаза завершена» — і приклади призупинення: фейл смоуку, блокер у ключовому флоу, лежачий стенд.
• Розумію, що відновлення не дорівнює «продовжити з того ж місця»: ретест фікса + повторний смоук, іноді перепрогін частини пройдених тестів.
• Можу пояснити, чому «усі тести пройдені, багів немає» — декоративний exit-критерій, і як виглядає робочий: «0 відкритих критичних, відомі середні погоджені з PO».

Оцінка тестування

• Можу пояснити, чому оцінка тестування залежить від якості білда (кожен баг = репорт + очікування фікса + ретест + шматок регресії) і тому завжди діапазон з допущеннями.
• Знаю три родини технік: історичні дані (ratios, екстраполяція), експертні (Wideband Delphi, planning poker), триточкова оцінка — і що їх комбінують: розійшлися вдвічі — шукати, чого не врахували, а не всереднювати.
• Пам'ятаю формули three-point: E = (O + 4×M + P) / 6, SD = (P − O) / 6 — і можу порахувати приклад: 5/8/17 → 9±2.
• Розумію сенс анонімності першого раунду Wideband Delphi — прибрати тиск авторитету, щоб решта не підлаштувалась під першу озвучену оцінку.

Ресурси і форма плану

• Можу пройтися чеклистом ресурсів: люди і ролі (з резервом на відпустки), середовища (дата готовності — явна залежність у плані, бо зривається найчастіше саме вона), тестові дані, інструменти й доступи, календар із буфером на цикли «баг → фікс → ретест».
• Знаю, де живе планування тестування в Scrum без формального плану: скоуп — на plannings, ризики — на refinement, критерії — у DoR/DoD.
• Можу пояснити критерій вибору форми: зовнішній читач (регулятор, аудит, контракт) → формальний документ за 29119-3; продуктова команда → сторінка у вікі. Головне — план мають читати.
• Розумію, чому неоновлюваний план гірший за відсутній: він упевнено повідомляє застарілі скоуп і строки всім, хто його відкриє.