Сформулируйте проверяемые критерии приёмки сайта

Возьмите пять требований из своего брифа или проекта ТЗ. Выберите разные задачи: обращение посетителя, работу редактора, отображение страницы, интеграцию и передачу результата. Если проекта ещё нет, используйте учебные задания ниже, а затем замените их собственными сценариями.

После урока другой участник должен суметь повторить вашу проверку и объяснить, выполнено ли требование. Общую структуру документа и заполненный пример каталога смотрите в руководстве по техническому заданию. Здесь работаем с отдельными требованиями, а не составляем ТЗ заново.

Разделите намерение и критерий

«Удобная форма» описывает намерение. «После отправки всё работает» оставляет неизвестными получателя, содержание сообщения и поведение при ошибке. Даже «форма отправляется за две секунды» не объясняет, что считать отправкой и в каких условиях измерять время.

Сначала запишите задачу человека. Затем укажите исходное состояние, действие и наблюдаемый результат. Число добавляйте только там, где оно помогает принять решение и согласованы условия измерения. Красивый интерфейс нельзя полностью описать одним числом: для визуальной части пригодятся согласованный макет, набор состояний и порядок рассмотрения расхождений.

Заполните карточку требования

Скопируйте таблицу в документ проекта. Одна карточка описывает один связный сценарий; отдельную ошибку можно оформить связанной карточкой с собственным идентификатором.

Не записывайте пароли и реальные персональные данные в общедоступное ТЗ. Для примеров используйте подготовленные тестовые данные, а способ получения доступа опишите отдельно.

Разберите заполненный пример

Ниже — вымышленный проект, не описание действующего сайта или обещание конкретной реализации CoreWeb.

F-01. Посетитель передаёт запрос по оборудованию. Страница карточки оборудования на русском языке, согласованная тестовая сборка, тестовый получатель заявок. В форме есть имя, контакт и описание задачи. В карточке заранее указана модель оборудования.

1. Откройте карточку и заполните форму согласованными тестовыми значениями.
2. Отправьте запрос один раз и дождитесь завершения операции.
3. Сверьте результат на странице с записью у тестового получателя.

Ожидаемый результат: система подтверждает успешный приём запроса только после подтверждения его принятия сервером. У получателя есть запись с переданными значениями и моделью из исходной карточки. Текст на странице не обещает, что менеджер уже прочитал запрос. Для проекта отдельно согласуется, означает ли приём постановку в очередь или доставку в конечную систему.

F-02. Ошибка обязательного поля: при пустом контакте посетитель получает понятное указание на поле и способ исправления; остальные введённые значения сохраняются, успешная отправка не показывается. Проверяющий исправляет значение и повторяет F-01.

F-03. Отказ системы: в согласованном тестовом окружении имитируется недоступность получателя. Страница показывает предусмотренное для этого случая состояние, сохраняет введённые данные и позволяет действовать по согласованному сценарию повтора. Если запрос принят в очередь, нужно отдельно проверить её обработку: отсутствие записи у получателя в эту секунду ещё не доказывает потерю заявки.

Доказательства: версия сборки, время проверки, ID тестовой записи, результат сравнения полей и снимки состояний без чувствительных данных. Открытый вопрос Q-01: кто получатель и как подтверждается конечная доставка? Пока это не определено, карточку нельзя считать полностью согласованной.

Проверка одной удачной отправки не закрывает F-02/F-03, а работа с тестовым получателем не подтверждает production-доставку. Итог каждой проверки фиксируйте отдельно.

Перепишите три формулировки

Сначала составьте собственные карточки, затем сверьтесь с ориентирами ниже. Не копируйте пример формы во все задания: у редактора и посетителя разные действия и доказательства.

Ориентир для CMS. Выберите одну операцию, например создание новости. Зафиксируйте роль редактора, поля и исходный статус. Опишите создание черновика, предпросмотр и публикацию. Проверьте, что черновик отсутствует в публичном списке, а опубликованная запись отображает согласованные поля. Доступ к настройкам, которые редактор менять не должен, оформите отдельной проверкой прав. Практические операции есть в руководстве по выбору CMS.

Ориентир для телефона. Назовите конкретный шаблон, согласованные устройства или размеры окна, содержимое и состояния: меню открыто, длинный заголовок, форма с ошибкой. Опишите наблюдаемый результат, например доступность кнопки отправки без перекрытия меню и возможность прочитать сообщение об ошибке. Один снимок главной не подтверждает все шаблоны и взаимодействия.

Ориентир для скорости. Сначала договоритесь, что измеряете: загрузку определённой страницы или завершение операции. Укажите инструмент, условия, набор запусков и способ обработки результатов. Порог впишите после согласования, а не выбирайте произвольное число. Пока условия или целевое значение неизвестны, оформите открытый вопрос. Лабораторная проверка в одних условиях не обещает такое же время каждому посетителю.

Проведите независимую самопроверку

Передайте одну карточку человеку, который её не писал. Попросите назвать необходимые данные, повторить действия и показать доказательство результата. Если ему приходится угадывать роль, текст состояния или место получения заявки, уточните карточку.

Для каждой из пяти карточек ответьте: может ли проверка закончиться отрицательным результатом? Понятно ли, чем «не выполнено» отличается от «не удалось проверить из-за отсутствия доступа»? Известно ли, где фиксировать расхождение и кто решает открытый вопрос? Формулировка, которую невозможно опровергнуть никакой проверкой, ещё слишком расплывчата.

Сохраняйте результат как «прошло», «не прошло» или «не проверено» с причиной и ссылкой на доказательство. Отсутствие доступа не превращается в успешную проверку. Если меняется согласованное требование, запишите новую версию и влияние на объём работ; не подменяйте этим исправление несоответствия уже согласованному критерию.

Что должно остаться после урока

Подготовьте пять заполненных карточек своего проекта, связанные негативные сценарии и список открытых вопросов с ответственными. У каждой карточки должны быть условия, действия, результат и способ подтверждения. Хотя бы одну проверьте независимым чтением и исправьте найденные неоднозначности.

Отметка о выполнении ниже означает, что вы подготовили этот материал. Она не подтверждает приёмку сайта. Свяжите карточки с соответствующими разделами ТЗ и проверьте, что они укладываются в карту страниц и согласованный состав проекта.

Сформулированные требования соберите в чек-лист приёмки сайта перед запуском. Отдельно отмечайте подтверждённое, расхождения и ещё не выполненные проверки.