Agile для QA: Scrum і Kanban

Як правильно читати цінності Agile-маніфесту? «Працюючий продукт важливіший за документацію» означає, що документація не потрібна?

Ні — і це найпоширеніша помилка читання маніфесту. Кожна з чотирьох цінностей має форму «X важливіше за Y», і автори прямо пишуть: цінність правої частини визнається, просто ліва цінується більше. Тобто документація, процеси, контракти і плани не скасовуються — вони перестають бути самоціллю. Для тестувальника це означає, що тест-документація не зникає, а худне до корисного мінімуму: чеклист замість покрокового тест-кейсу там, де кроки очевидні, acceptance criteria замість багатосторінкового ТЗ. «У нас Agile, тому нічого не документуємо» — карго-культ, а не цінність: через пів року ніхто не знає, як має працювати продукт. Відповідь «Agile — це коли без документації» на співбесіді одразу видає, що кандидат маніфесту не читав.

Розкажіть про Scrum: ролі, події, артефакти.

Scrum — легкий фреймворк, побудований довкола спринтів: ітерацій фіксованої довжини, не довших за календарний місяць (на практиці найчастіше 1–2 тижні), кожна з яких закінчується інкрементом — придатним до використання шматком продукту. Зон відповідальності три: Product Owner відповідає за цінність продукту і порядок Product Backlog, Scrum Master — за те, щоб Scrum працював (фасилітує події, допомагає прибирати перешкоди, але не роздає задачі), Developers — усі, хто створює інкремент, включно з QA. Подій пʼять: сам спринт як контейнер, Sprint Planning, Daily Scrum на 15 хвилин, Sprint Review і Sprint Retrospective — і кожна існує як петля зворотного звʼязку, а не ритуал. Артефакти три, у кожного своє зобовʼязання (commitment): Product Backlog з Product Goal, Sprint Backlog зі Sprint Goal, Increment з Definition of Done. Сильна відповідь пояснює призначення, а не перелічує назви: «Daily — щоб синхронізуватися і підсвітити блокери» звучить переконливіше за «це коли всі розповідають, що робили вчора».

Чи є у Scrum окрема роль тестувальника? Хто тоді відповідає за якість?

Окремої ролі «тестувальник» у Scrum немає: QA-інженер у термінах Scrum Guide — один із Developers, тих, хто створює інкремент. Це не бюрократична дрібниця, а пряме втілення whole-team approach (підхід «якість — справа всієї команди»): за якість відповідає вся команда, а не тестувальник-«воротар» наприкінці конвеєра. Тестування — частина розробки, а не окремий цех, тому тестувальник не «пропускає» реліз — він дає команді інформацію для рішення. Практичний наслідок: якщо тестування стало вузьким місцем, розробник може прогнати чеклист по чужій сторі, написати відсутній автотест чи підняти тестовий стенд — «я розробник, я не тестую» не є Agile-аргументом. Саме цим питанням інтервʼюер фільтрує, чи бачить кандидат себе частиною команди, чи «приймальником» наприкінці конвеєра — друге вважається червоним прапорцем.

Що робить QA на кожній події Scrum?

Скрізь потроху, і в кожної події своя функція. На Sprint Planning QA озвучує обсяг тестування: які перевірки складні, чи потрібні тестові дані й середовища — щоб оцінка спринту включала тестування, а не лише код. На Daily Scrum синхронізується з командою: що заблоковане, які сторі готові до перевірки. На Sprint Review показує знайдені обмеження і бере участь у демо інкремента стейкхолдерам. На Retrospective піднімає процесні проблеми — «тестування отримує все в останній день» розбирається саме тут, а не терпиться мовчки. Окремо стоїть рефайнмент беклогу — формально не подія з таймбоксом, але для QA це найважливіша зустріч тижня, бо там можна вплинути на якість ще до написання коду.

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

Kanban — метод керування безперервним потоком задач: ітерацій немає взагалі. Роботу візуалізують на дошці, де колонки — стани процесу, і обмежують кількість задач у роботі одночасно через WIP-ліміти. Це pull-система: задачу не «кидають» на наступний етап, її тягнуть із попередньої колонки, коли звільнилося місце. Замість velocity тут метрики потоку: lead time, cycle time, throughput; зміни можна вносити будь-коли через беклог, не чекаючи наступної ітерації. Тому Kanban частіше беруть команди підтримки й супроводу — усі, у кого потік задач непередбачуваний: баг із проду не чекатиме початку спринту.

Що таке WIP-ліміт і навіщо він потрібен?

WIP-ліміт (work in progress limit) — максимум задач, які можуть одночасно перебувати в колонці дошки, і це серцевина методу Kanban. Логіка проста: чим більше задач у роботі паралельно, тим довше їде кожна з них — команда перемикається між усім одразу і не завершує нічого. Обмеживши WIP, команду змушують «перестати починати і почати завершувати». Другий ефект — видимість вузького місця: якщо колонка Testing уперлася в ліміт, це бачить уся команда, і проблема стає командною, а не особистою проблемою тестувальника. Без лімітів та сама дошка перетворюється на звалище, де перед Testing висить двадцять задач і QA хронічно «не встигає».

Чим Scrum відрізняється від Kanban? Коли б ви обрали кожен?

Головна різниця — в механізмі обмеження роботи: Scrum обмежує обсяг фіксованого спринту, Kanban — кількість задач у роботі через WIP-ліміти. Далі відмінності ланцюжком: у Scrum каденція спринтів і небажані зміни всередині спринту, у Kanban безперервний потік і зміни будь-коли через беклог; у Scrum метрики velocity і виконання Sprint Goal, у Kanban — lead time, cycle time і throughput; Scrum визначає ролі (PO, Scrum Master, Developers), Kanban власних ролей не приписує. Вибір залежить від характеру роботи: продуктовій команді з плановими релізами природніший Scrum, команді підтримки з непередбачуваним потоком (баги з проду не чекатимуть планування) — Kanban. Поширені й гібриди: команда працює спринтами, але з дошкою, WIP-лімітами і метриками потоку.

Що таке lead time, cycle time і throughput?

Це три основні метрики потоку в Kanban. Lead time — час від появи задачі до її доставки, тобто те, що відчуває замовник: «я попросив — я отримав». Cycle time — час від початку роботи над задачею до завершення: скільки задача реально їхала конвеєром, без очікування в черзі. Throughput (пропускна здатність) — скільки задач команда завершує за період. Різниця lead проти cycle практична: якщо cycle time — два дні, а lead time — три тижні, робота йде швидко, але задачі довго лежать у черзі, і оптимізувати треба чергу, а не людей.

Що таке Definition of Done і чим він відрізняється від acceptance criteria?

Це класична пастка на співбесіді. DoD — спільний для всієї команди чеклист, що означає «задача справді готова»: типово — код написаний і пройшов ревʼю, юніт-тести зелені, acceptance criteria перевірені, автотести написані чи оновлені, білд розгорнутий на тестовому середовищі, критичних багів немає. Різниця з AC у масштабі: AC — свої в кожної сторі і кажуть, що має робити конкретна фіча; DoD — один на команду і каже, коли будь-яка задача вважається готовою. DoD — офіційна частина Scrum, у Scrum Guide 2020 це зобовʼязання артефакту Increment: задача, що не відповідає DoD, не «майже готова» — вона не готова і в інкремент не входить. Для QA принциповий пункт «тестування пройдене» в DoD — це формальна гарантія, що тестування не можна «зрізати» під тиском дедлайну.

Що таке Definition of Ready і чи є він частиною Scrum?

DoR — дзеркальний до DoD чеклист на вході: коли user story достатньо готова, щоб брати її в спринт. Типовий склад: зрозуміла цінність, є acceptance criteria, сторі тестопридатна, залежності розвʼязані, оцінка проставлена. Деталь, яку люблять перевіряти на співбесідах: у Scrum Guide DoR немає — це поширена практика спільноти, а не частина фреймворку; офіційно визначений лише DoD. Силабус ISTQB CTFL 4.0 ставить обидва поняття на знайомі місця: DoR — критерії входу, DoD — критерії виходу (ті самі entry/exit criteria зі STLC). QA має вболівати за обидва списки: слабкий DoR — у спринт залітають сторі без AC, і тестувати доводиться «на око»; слабкий DoD — «готово» означає «розробник закомітив», і баги ловляться після релізу.

Знайшли баг по сторі поточного спринту і баг у старій функціональності. Що робити з кожним?

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

Що таке story points і чому їх не можна конвертувати в години?

Story points — відносна оцінка обсягу роботи над сторі з урахуванням складності та невизначеності. Ключове слово — відносна: 5 поінтів означає «приблизно як та сторі на 5, яку ми вже робили», а не «пʼять годин». Для оцінки беруть ряд, схожий на Фібоначчі (1, 2, 3, 5, 8, 13): що більша задача, то грубіша оцінка — і це чесно відображає невизначеність. Конвертація поінтів у години вбиває сенс відносної оцінки й повертає команду до торгів за естімейти. Для QA тут критичне інше: оцінка сторі має включати тестування, інакше воно стає невидимою роботою — спринт набирають під velocity, а перевіряти набране фізично нема коли. Класичний приклад: сторі «додати поле знижки в замовлення» — розробки на день, а перевірок на три (комбінації знижок, валюти, відʼємні значення, перерахунок наявних замовлень); якщо QA мовчить на оцінці, сторі отримає 2 поінти і зламає спринт.

Що таке velocity і чому не можна порівнювати velocity двох команд?

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

Навіщо planning poker, якщо можна просто спитати найдосвідченішого в команді?

Саме тому й потрібен: одночасне відкриття карт прибирає ефект якоря, коли перший голос — зазвичай найгучніший сеньйор — тягне за собою решту. Механіка: кожен учасник мовчки обирає карту з оцінкою, всі відкривають одночасно; якщо оцінки розійшлися, крайні голоси пояснюють свою логіку, і раунд повторюють до збіжності. Головна цінність — не карти, а дискусія, яку викликає розбіжність: якщо розробник показав 2, а QA показав 8, часто «2» просто не бачить половини сценаріїв перевірки. Силабус ISTQB CTFL 4.0 описує planning poker як варіант техніки Wideband Delphi — командної оцінки, заснованої на досвіді.

Яка роль QA на рефайнменті беклогу?

Для тестувальника рефайнмент — найважливіша зустріч тижня, важливіша за Daily: саме тут QA впливає на якість найдешевшим способом — питаннями до сторі, якої ще не існує в коді. Типовий арсенал: що станеться в негативному сценарії (нуль, порожньо, тисяча символів, кирилиця); як фіча взаємодіє з наявними і що буде зі старими даними; де межі — ролі, права, ліміти, конкурентні дії двох користувачів; і головне — «як ми це перевіримо?». Останнє питання — індикатор тестопридатності: якщо команда не може відповісти, сторі не готова до спринту, і зʼясувати це на рефайнменті дешевше, ніж у передостанній день спринту. Це прямий наслідок принципу раннього тестування — дефект у вимозі, знайдений до коду, найдешевший з можливих. Побічний ефект регулярних QA-питань: вимоги в команді загалом точнішають, бо розробники звикають, що «happy path описаний, решта якось буде» не проходить.

Колонка Testing уперлася в WIP-ліміт, і розробники не можуть брати нові задачі. Як має відреагувати команда?

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

Розробка закінчує задачі в четвер, спринт завершується в пʼятницю. Ваші дії?

Якщо так відбувається щоспринту — це антипатерн mini-waterfall: зовні все схоже на Scrum (є Daily, є Review), а насправді всередині двотижневої ітерації живе маленький водоспад із фазою тестування в кінці, куди все й упирається. Сильна відповідь — про зміну процесу, а не про героїзм: брати участь у рефайнменті і продумувати перевірки до того, як написаний код; готувати тестові дані й середовища заздалегідь; тестувати сторі одну за одною в міру готовності, а не пачкою в останній день; коли часу однаково бракує — пріоритизувати перевірки за ризиком. І обовʼязково винести проблему на ретроспективу як командну: «тестування отримує все в останній день» — процесний дефект, який лікується процесом. Відповідь «сидів до ночі й тестував» — слабка: вона консервує антипатерн і показує «приймальника», а не члена команди, відповідальної за якість разом.

Три кейси з робочого життя QA в Agile-команді: діагностика mini-waterfall у спринті, що зовні виглядає як Scrum; Kanban-дошка, де Testing уперлася в ліміт і зупинила конвеєр; і рефайнмент однієї сторі, де питання QA міняють оцінку вдвічі. Скрізь — розбір рішень і чому саме так.

Кейс 1. Спринт закінчується авралом: діагностика mini-waterfall

Команда працює двотижневими спринтами, всі події на місці: Daily, Review, ретро. Але щоспринту повторюється той самий сценарій — розробка «закриває» задачі в четвер, спринт завершується в пʼятницю, і QA сидить до ночі. Порівняймо, як виглядає такий спринт і як має виглядати здоровий:

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

• Формальні події не діагноз, діагноз — момент, коли тестування отримує роботу. Якщо це завжди останні дні — всередині ітерації живе маленький водоспад із фазою тестування в кінці, і жодна кількість Daily цього не лікує.
• Проблема лікується процесом, а не героїзмом. «Сидів до ночі й тестував» консервує антипатерн: спринт знову набрали під velocity без тестування в оцінці, і наступного разу буде так само. Місце цієї розмови — ретроспектива, саме для процесних проблем вона існує.
• Половина рішення — до написання коду. Участь у рефайнменті, продумані заздалегідь перевірки, готові тестові дані й середовища переносять роботу QA з десятого дня на перший-другий.
• Друга половина — whole-team. Якщо в останній день перевірок однаково більше, ніж рук, розробники проганяють чеклисти по чужих сторі — «я розробник, я не тестую» не є Agile-аргументом.

Кейс 2. Kanban-дошка: колонка Testing уперлася в ліміт

Команда підтримки працює за Kanban. Дошка виглядає так:

Задачі F і G у Testing, ліміт колонки вичерпано. Розробник закінчив задачу H і хоче потягнути її в Testing — місця немає. Варіанти дій і їхні наслідки:

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

• Заповнена колонка Testing — не збій, а головна функція методу. Вузьке місце видно на дошці всім, і воно автоматично стає проблемою команди, а не тестувальника. Правильна рамка розмови — не «QA гальмує», а «потік стоїть, ідемо розчищати».
• WIP-ліміт змушує «перестати починати і почати завершувати». Що більше задач їде паралельно, то довше їде кожна: команда перемикається між усім одразу. Саме тому варіант «почати ще одну» — найгірший із трьох.
• Хронічно тісний ліміт Testing — сигнал для метрик. Якщо колонка впирається в ліміт щотижня, дивись cycle time: зростає — отже, вузьке місце системне, і це аргумент за автоматизацію рутинних перевірок чи перерозподіл людей, а не за мовчазне підняття ліміту.

Кейс 3. Рефайнмент сторі «додати поле знижки»: питання QA міняють оцінку

На рефайнменті сторі: «Як менеджер, я хочу вказувати знижку в замовленні, щоб давати клієнтам індивідуальні умови». Acceptance criteria одна: «У формі замовлення зʼявляється поле знижки у відсотках, сума перераховується». Розробник на planning poker показує 2 — «одне поле і формула».

QA показує 8 і пояснює логіку питаннями з типового арсеналу:

• Негативні сценарії: що при нулі, порожньому полі, відʼємному значенні, 150 відсотках, кирилиці замість числа?
• Взаємодія з наявним: як індивідуальна знижка комбінується з наявними акційними? Множаться, додаються, більша перемагає?
• Старі дані: що станеться з уже створеними замовленнями після релізу — перераховуються чи ні?
• Межі: хто має право ставити знижку — будь-який менеджер чи тільки старший? Є ліміт максимального відсотка? Що як два менеджери редагують замовлення одночасно?
• Тестопридатність: як ми це перевіримо — чи є тестові дані з різними валютами і типами замовлень на тестовому середовищі?

Product owner може відповісти лише на два питання з десяти. Результат раунду: сторі не відповідає DoR — acceptance criteria не покривають половини поведінки, тестопридатність під питанням. Сторі повертається на доопрацювання, після уточнення AC команда сходиться на 5, і в оцінку вже включені перевірки комбінацій знижок і міграції старих замовлень.

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

• Дискусія і є цінністю planning poker. Одночасне відкриття карт прибрало ефект якоря: якби перший голос був «2», решта підлаштувалася б. Розбіжність 2 проти 8 змусила розмову відбутися — і «2» просто не бачив половини сценаріїв перевірки.
• Оцінка має включати тестування. Розробки тут на день, перевірок — на три. Якби QA промовчав, сторі отримала б 2 поінти, спринт набрали б під velocity — і перевіряти набране було б фізично нема коли.
• Питання до сторі, якої ще немає в коді, — найдешевший спосіб знайти дефект. Дірка в AC про комбінації знижок, знайдена на рефайнменті, коштує пʼять хвилин розмови. Та сама дірка в передостанній день спринту — баг на проді або зірваний Sprint Goal.
• «Як ми це перевіримо?» — індикатор тестопридатності. Немає відповіді — сторі не готова до спринту, і саме слабкий DoR пускає такі сторі всередину, де їх тестують «на око».

Agile-маніфест і whole-team approach

• Розумію формат цінностей маніфесту «X важливіше за Y»: права частина визнається, просто ліва цінується більше — «Agile — це коли без документації» видає, що маніфест не читаний.
• Можу пояснити whole-team approach: за якість відповідає вся команда, тестувальник дає інформацію для рішення, а не «пропускає» реліз як воротар наприкінці конвеєра.
• Розумію ланцюжок «готовність до змін → постійна потреба в регресії → автоматизація»: кожна зміна ризикує зламати старе.

Scrum

• Знаю три зони відповідальності (accountabilities): Product Owner — цінність і Product Backlog, Scrum Master — щоб Scrum працював (не менеджер і не роздає задачі), Developers — усі, хто створює інкремент; окремої ролі «тестувальник» немає — QA один із Developers, і це пряме втілення whole-team approach.
• Можу пояснити призначення кожної події як петлі зворотного звʼязку і що там робить QA: Planning — озвучити обсяг тестування, Daily — синхронізація довкола Sprint Goal (блокери, готові до перевірки сторі), а не звіт Scrum Master-у, Review — демо й знайдені обмеження, Retro — процесні проблеми на кшталт «усе в останній день».
• Знаю три артефакти та зобовʼязання кожного: Product Backlog + Product Goal, Sprint Backlog + Sprint Goal, Increment + Definition of Done.

Kanban

• Можу пояснити WIP-ліміт: що більше задач паралельно, то довше їде кожна; ліміт змушує «перестати починати і почати завершувати».
• Розумію pull-механіку: задачу тягнуть, коли звільнилося місце, тому заповнена колонка Testing зупиняє конвеєр — і це функція методу, а не збій: вузьке місце стає проблемою команди, а правильна реакція — «йдемо допомагати тестувати».
• Знаю метрики потоку і різницю між ними: lead time (від появи задачі до доставки — те, що відчуває замовник), cycle time (від початку роботи до завершення), throughput (скільки задач за період).
• Можу порівняти Scrum vs Kanban за чотирма осями: каденція (спринти vs потік), обмеження (обсяг спринту vs WIP-ліміти), метрики (velocity vs lead/cycle time), ролі (визначені vs не приписані) — і сказати, кому природніший який: продуктова команда з плановими релізами vs підтримка з непередбачуваним потоком.

DoR і DoD

• Знаю різницю DoR vs DoD: критерії входу сторі в спринт vs критерії виходу задачі (ISTQB CTFL 4.0 мапить їх на entry/exit criteria) — і пастку співбесіди: DoD визначений у Scrum Guide 2020 (зобовʼязання артефакту Increment), а DoR у гайді немає, це практика спільноти.
• Можу пояснити різницю DoD vs acceptance criteria: DoD один на команду і каже, коли будь-яка задача готова; AC — свої в кожної сторі і кажуть, що має робити фіча; пункт «тестування пройдене» в DoD — формальна гарантія, що тестування не зріжуть під дедлайн.
• Знаю долі багів у спринті: баг по сторі поточного спринту лагодиться одразу (сторі не відповідає DoD, поки баг живий), баг старої функціональності їде в беклог.

Оцінка: story points, velocity, planning poker

• Розумію відносність story points («як та сторі на 5, яку ми вже робили», не «пʼять годин») і чому конвертація в години вбиває сенс оцінки.
• Можу пояснити, чому оцінка сторі має включати тестування: інакше воно стає невидимою роботою — сторі «розробки на день, перевірок на три» отримує 2 поінти і ламає спринт.
• Знаю, що velocity — прогноз місткості спринту для конкретної команди, а не метрика продуктивності: порівнювати команди безглуздо (різні «лінійки»), а щойно метрика стає ціллю — вона перестає вимірювати.
• Можу пояснити механіку planning poker: одночасне відкриття карт прибирає ефект якоря, головна цінність — дискусія при розбіжності оцінок; в ISTQB це варіант Wideband Delphi.

QA у спринті та рефайнмент

• Розпізнаю антипатерн mini-waterfall: усі події Scrum на місці, але тестування завжди в останні дні спринту — водоспад у двотижневій обгортці, який жодна кількість Daily не лікує.
• Знаю здорову модель тестування в спринті: питання до вимог на рефайнменті ще до коду, перевірки й тестові дані заздалегідь, сторі тестуються в міру готовності, наприкінці — коротка регресія і смоук, пріоритизовані за ризиком.
• Маю арсенал QA-питань на рефайнменті: негативні сценарії (нуль, порожньо, тисяча символів), взаємодія з наявними фічами і старими даними, межі (ролі, права, ліміти, конкурентні дії) і «як ми це перевіримо?» — індикатор тестопридатності: немає відповіді — сторі не готова до спринту.