Зачем отделять требование от критерия
Требование сообщает, что продукт должен уметь: например, пользователь отправляет заявку. Критерий превращает эту фразу в проверку: обязательные поля отмечены, неверный телефон вызывает понятную ошибку, успешная отправка создаёт запись, отправляет уведомление и показывает подтверждение без повторного списания события аналитики.
Если ограничиться словами «форма работает», заказчик и исполнитель будут проверять разные вещи. Один увидит доставленное письмо, другой — красивое сообщение, третий — отсутствие ошибок в консоли. Полнота проверки возникает только после перечисления значимых состояний.
Формула проверяемого результата
Используйте конструкцию: при заданной роли, исходных данных и условии пользователь выполняет действие, после чего система показывает или сохраняет ожидаемый результат. Дополнительно укажите среду, допустимое время ответа и то, где подтверждается серверный эффект.
| Часть | Что зафиксировать |
|---|---|
| Контекст | роль, устройство, авторизация, исходное состояние |
| Действие | один воспроизводимый шаг или короткая последовательность |
| Результат | видимое состояние и изменение данных |
| Граница | ошибочные, пустые и повторные действия |
| Подтверждение | скриншот, запись, письмо, событие или лог |
Пример для формы заявки
Посетитель открывает форму на телефоне шириной 390 пикселей, оставляет имя пустым и нажимает кнопку. Поле получает текстовую ошибку, фокус перемещается к первой проблеме, введённые данные сохраняются. После корректного заполнения кнопка блокируется на время отправки, заявка создаётся один раз, а событие цели отправляется только после ответа сервера.
Этот пример одновременно проверяет бизнес-результат, доступность, мобильное состояние, защиту от дублей и аналитику. Его можно разбить на отдельные тесты, но нельзя заменить фразой «сделать валидацию».
Критерии для контента и SEO
Для шаблона страницы задайте редактируемые title и description, единственный основной заголовок, канонический адрес, индексируемость, хлебные крошки и правила изображения для социальных сетей. Для удалённого адреса укажите редирект и отсутствие цепочки переходов. Для каталога отдельно опишите фильтры, пагинацию и пустую выдачу.
- текст и изображения не подменяются финальными материалами без согласования;
- обязательные метаданные доступны редактору;
- структурированные данные соответствуют видимому содержанию;
- ошибочные и служебные страницы не попадают в индекс случайно.
Нефункциональные критерии
«Сайт быстрый» не проверяется. Укажите набор ключевых страниц, мобильный профиль, способ замера и целевые показатели. Для пользовательского опыта полезны ориентиры LCP не более 2,5 секунды, INP не более 200 миллисекунд и CLS не более 0,1 на 75-м процентиле реальных посещений. Лабораторный тест перед запуском — прогноз, а полевые данные после запуска — подтверждение.
Для доступности перечисляют управление клавиатурой, видимый фокус, подписи полей, альтернативные тексты, контраст и сообщения об ошибках. Для безопасности — роли, права, обновления, резервное копирование и обработку персональных данных.
Кто и когда проверяет
Автор задачи готовит критерии до оценки, исполнитель уточняет технические границы, тестировщик превращает их в набор проверок, владелец результата принимает бизнес-смысл. Спорные формулировки устраняют до разработки: после готовности они превращаются в дорогую смену ожиданий.
- Провести совместный разбор критериев.
- Подготовить тестовые роли и данные.
- Проверить основной путь и негативные состояния.
- Зафиксировать дефекты со средой и шагами.
- Повторить проверку после исправления.
Что не является критерием
Название библиотеки, фраза «по макету», субъективное «удобно» и обещание «без ошибок» не дают границы готовности. Техническое решение может быть ограничением, но приёмка должна описывать проявление продукта. Не требуйте абсолютного совпадения на всех устройствах: зафиксируйте поддерживаемые диапазоны и допустимые адаптивные изменения.
Мини-проверка перед передачей в работу
Каждый критерий должен читаться без устных пояснений, иметь один смысл и воспроизводимый результат. Проверьте основной, пустой, ошибочный, загрузочный и успешный сценарии; права разных ролей; мобильное поведение; аналитику и сохранение данных. Если ответ зависит от ещё не принятого решения, это вопрос или допущение, а не готовый критерий.