Что именно принимают

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

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

Как превратить пункт ТЗ в сценарий

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

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

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

Список браузеров и размеров экрана согласуют заранее. Документация Playwright об эмуляции показывает, что параметры устройства, области просмотра и окружения задаются отдельно. Из этого следует практическое правило: запись «проверено на мобильном» слишком неопределённа для повторения.

Чек-лист перед приёмкой

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

Условный пример: скидка в корзине

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

Запись «скидки не работают» теряет важную деталь. Точная карточка указывает товар, исходную цену, количество, шаг перехода и ожидаемое сохранение суммы. Скриншоты двух состояний связываются одним номером проверки. Это иллюстрация метода, а не описание реального проекта или установленного нарушения.

Что должно остаться по итогам

Результат приёмки — перечень проверенных требований с понятными основаниями статусов. К нему прилагают список открытых вопросов, условия повторной проверки и реестр файлов. Итоговое «всё работает» без охвата оставляет неизвестным, проверяли ли личный кабинет, обработку отказов или только главную страницу.

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