«Додати кнопку публікації новини» здається короткою задачею. Але під час здавання з’ясовується, що автор очікував попередній перегляд, редактор — захист від випадкового оприлюднення, а замовник — відсутність чернеток у відкритому списку. Критерії приймання задачі допомагають домовитися про результат до написання коду. Розберемо це на навчальній редакційній системі, де потрібно перевести одну новину з чернетки в публікацію.
Це вигаданий приклад вимог, а не опис стандартної поведінки WordPress чи іншої CMS і не клієнтський кейс. Нижче запропоновано конкретний набір правил, який команда може прийняти або змінити до оцінювання роботи. Потрібні спільний документ, представник замовника, розробник і людина, яка перевірятиме результат. Доступ до продуктивного сайту, встановлення інструментів і зміна реальних записів для цієї вправи не потрібні.
Обмежте задачу одним переходом стану
Почніть із речення про користь: редактор може оприлюднити підготовлену новину, а відвідувач бачить лише дозволений публічний матеріал. Воно пояснює мету, але ще не є критерієм перевірки. Поруч окремо запишіть межі: у цю задачу не входять відкладена публікація, погодження кількома редакторами, email-розсилка та автоматичне поширення в соцмережах. Інакше одна кнопка непомітно перетвориться на нову редакційну платформу.
Для навчального прикладу домовляємося про дві ролі. Автор створює та зберігає чернетку, редактор публікує її. Відвідувач без входу не має доступу до чернетки. Це вимоги до нашої умовної системи, не рекомендація змінити ролі на вашому сайті. Якщо в реальному проєкті права інші, спочатку виправте цю домовленість: наступні очікування залежать саме від неї.
Створіть картку контрольних даних у документі: новина NEWS-DEMO-01, заголовок «Тестова новина», текст «Матеріал для перевірки», початковий стан «Чернетка». Ідентифікатор і вміст умовні. Зазначте також порожній список опублікованих новин у тестовому наборі. Контрольна картка дозволяє двом людям незалежно зрозуміти, який запис шукати і чому результат не слід оцінювати за випадковим матеріалом на робочому сайті.
Окремо запитайте, що означає оприлюднення: поява в списку, відкриття за прямим посиланням, доступність для пошуку чи всі ці події. Для вправи погодимо лише відкриття сторінки та появу в публічному списку. Індексація Google не входить у критерій: це не безпосередня дія кнопки, якою команда повністю керує. Не обіцяйте пошукову видимість одразу після натискання.
Перетворіть домовленість на спостережувані приклади
Замість «публікація працює правильно» запишіть критерій П1: коли редактор відкрив збережену NEWS-DEMO-01 і підтвердив публікацію, система показує стан «Опубліковано»; відвідувач без входу відкриває її сторінку та знаходить один запис у публічному списку. Обидва перегляди мають містити погоджені заголовок і текст. Тут названі початкові умови, дія та видимий результат, а не внутрішня реалізація.
Критерій П2 стосується меж повноважень: автор, який не має права публікації, не може перевести цю новину в публічний стан. При спробі виконати дію поза дозволеним інтерфейсом сервер також має відмовити, а запис залишається чернеткою. Відсутність кнопки сама по собі не доводить захисту. Конкретний спосіб технічної перевірки узгоджує розробник; перевіряють лише дозволені тестові облікові записи, без пошуку чужих доступів.
Критерій П3: відвідувач без входу не отримує заголовок і текст чернетки ні через пряме посилання, ні через публічний список. Вид службової відповіді або сторінки повідомлення треба погодити окремо. Не залишайте формулювання «чернетка прихована» без пояснення, звідки саме. Перевірка повинна охопити не тільки візуальну картку, а й відкриту відповідь сервера, якщо система віддає матеріал через публічний API.
Для впорядкування таких прикладів можна використовувати схему «Дано — Коли — Тоді». Її призначення та відповідні ключові слова описані в документації Gherkin. У нашій вправі достатньо звичайного документа: встановлювати Cucumber не потрібно. Текстовий сценарій не стає виконаним автоматизованим тестом лише тому, що написаний у схожому форматі; для автоматизації потрібна окрема реалізація перевірок.
Додайте два крайові випадки до тих самих правил. Якщо заголовок порожній, публікація не відбувається, редактор бачить пояснення біля відповідного поля, а введений текст зберігається у формі. Якщо редактор повторно підтверджує вже виконану публікацію, нова копія новини не створюється. Це наші погоджені очікування, а не твердження, що будь-яка CMS уже поводиться саме так.
Не змішуйте критерії з дорученнями на реалізацію. «Додати поле status у таблицю» може бути технічним підзавданням, але не пояснює, що отримує редактор. Так само «написати три тести» не доводить виконання П1–П3, якщо тести перевіряють інші гілки. Спочатку визначте спостережуваний результат; вибір структури даних, маршруту й компонентів залиште технічному плану.
Проведіть приймання без зміни правил наприкінці
Перед початком розробки попросіть іншу людину прочитати картку й пояснити очікуваний результат своїми словами. Якщо залишилися запитання про роль, стан, обов’язкове поле або місце видимості, задача ще має невизначеність. Зафіксуйте відповіді та версію домовленості. Нове побажання після реалізації обговорюйте як зміну обсягу, а не оголошуйте автоматично помилкою розробника.
Для приймання використайте погоджену тестову копію та навчальні дані без персональної інформації. Навпроти кожного критерію запишіть перевірену збірку, фактичний результат і короткий доказ. Не позначайте успіх наперед. Якщо правило порушене, опишіть окремий багрепорт із кроками відтворення та посиланням на конкретний критерій, щоб перевірка не перетворилася на нову суперечку про очікування.
Висновок: критерії приймання зменшують неоднозначність, коли називають стан, роль, дію та результат, який можна перевірити. Для цієї вправи готовність означає виконання П1–П3 і погоджених крайових випадків, а не просто появу кнопки. Якщо задачу на сайт складно оцінити через нечіткі очікування, AriZone може допомогти розділити вимоги, визначити межі та підготувати перевірювані приклади до розробки.
Залиште коментар