Від специфікації до цінності для користувача
Специфікація описує, що зробити, а продукт існує, щоб вирішити задачу користувача. Фіча може відповідати специфікації на 100% і все одно не працювати для людей: кнопка є, але її не видно; форма приймає дані, але користувач не розуміє, що робити далі. QA, який мислить продуктово, перевіряє обидва рівні: «зроблено правильно?» і «зроблено те, що потрібно?».
User story фіксує потребу: «Як роль, я хочу дію, щоб результат». Якість історії швидко оцінюють за INVEST: Independent (незалежна), Negotiable (обговорювана), Valuable (цінна), Estimable (оцінювана), Small (мала), Testable (тестована). Якщо історію не можна протестувати, вона ще не готова до розробки.
Acceptance criteria роблять історію перевірюваною. Зручний формат Given / When / Then:
- Given — початковий стан (користувач увійшов, у кошику один товар);
- When — подія або дія, яку перевіряємо (натискає «Оформити»);
- Then — спостережуваний результат (бачить підтвердження, на пошту прийшов лист).
Один сценарій — одна поведінка. Критерій на кшталт «працює швидко» не годиться: потрібне число й умови («відповідь пошуку до 1 с для 95% запитів на каталозі з 10 000 товарів»).
Питання до PM, які варто ставити до початку розробки: яку проблему розв’язуємо і для кого? Як зрозуміємо, що вдалося (метрика)? Що поза межами цього релізу? Що має статися, якщо сервіс недоступний або дані порожні? Чи є обмеження: платформи, країни, законодавство, доступність?
Баг чи фіча, ризики за впливом на бізнес, MVP
Баг чи фіча? Критерій — не «хто це написав», а очікувана поведінка. Якщо поведінка суперечить специфікації чи розумним очікуванням користувача — це дефект. Якщо очікування ніде не описане або це бажання нової можливості («додайте експорт у PDF») — це запит на зміну, і рішення про пріоритет за власником продукту. Спірні випадки не вирішують «в багтрекері війною»: QA описує вплив на користувача, а PM вирішує.
Ризик за впливом на бізнес. Часу завжди менше, ніж ідей для тестів. Для кожної зміни питаємо: наскільки поганим буде збій (гроші, дані, репутація, юридичні наслідки) і як ймовірно, що він трапиться (нова складна логіка, частий код, інтеграції). Оплата, реєстрація, права доступу, робота з персональними даними — зверху списку; зміна кольору підказки — знизу. Це допомагає чесно сказати: «ось що ми перевірили глибоко, а ось що лише поверхнево».
Тестування від шляху користувача. Окремі екрани можуть працювати, а шлях — ні. Пройдіть сценарій цілком: прийшов з реклами → зареєструвався → знайшов товар → оплатив → отримав лист → повернувся за статусом. Дивіться на стики: передачу даних між кроками, поведінку «назад», перезавантаження, слабкий інтернет, мобільний екран.
MVP і компроміси. MVP — найменший реліз, що перевіряє гіпотезу про цінність. Він навмисно не повний, і це нормально. Роль QA тут — не блокувати, а зробити компроміси явними: що відомо й не виправлено, який вплив, як обмежити (feature flag, частина аудиторії, примітка в release notes). Рішення «випускаємо з цим обмеженням» ухвалює власник продукту, але робить це зі знанням ризику.
Edge cases, що мають значення. Не всі крайні випадки однаково важливі. Спершу ті, що торкаються реальних людей: довге ім’я або апостроф у прізвищі, кирилиця й емодзі, інший часовий пояс, порожній стан («у вас ще немає замовлень»), повторне натискання на кнопку оплати, втрата зв’язку посеред дії.