Вернуться к статьям Приемочные сценарии до публикации
Приемка начинается со списка действий посетителя и редактора, а не с просмотра главной страницы. Для формы это путь от заполнения полей до письма и записи в CRM; для каталога — поиск, фильтр, карточка и заявка; для редактора — вход под своей ролью, создание материала, публикация и возврат к предыдущей версии. У каждого сценария есть ожидаемый результат и участник, который его подтверждает.
Устройства, браузеры и условия проверки
Проверяемый набор устройств согласуют до тестирования. В него включают реальные разрешения и браузеры аудитории, а не все варианты, которые существуют на рынке. Отдельно проверяют узкие экраны, клавиатуру на телефоне, отправку формы при плохой сети и состояние после обновления страницы: именно здесь обычно проявляются ошибки адаптива и клиентской логики.
Права редакторов и фиксация дефектов
Права тестируют отдельными учетными записями. Администратор может незаметно обойти ограничение, которое остановит редактора в рабочий день. В карточке дефекта указывают маршрут, шаги воспроизведения, устройство, ожидаемый и фактический результат; фраза «кнопка не работает» не дает разработчику достаточно данных для повторной проверки.
Приёмка проверяет сценарии, а не впечатление от главной страницы
Сайт может выглядеть корректно на ноутбуке разработчика и при этом терять обращения в мобильном браузере. Поэтому приёмочный набор начинают с маршрутов, которые важны бизнесу: просмотр услуги, поиск, отправка формы, переход из рекламного объявления, авторизация и работа редактора. Для каждого маршрута фиксируют устройство, браузер, входные данные, ожидаемый результат и человека, который подтвердил проверку.
Тест формы не сводится к нажатию кнопки «Отправить». Проверяют обязательные поля, понятность ошибок, защиту от повторной отправки, согласие, отправку уведомления и появление обращения в целевой системе. Если форма передаёт выбранную услугу, файл или источник рекламы, эти значения сравнивают с карточкой заявки. Тестовая запись должна быть помечена так, чтобы её не приняли за реального клиента.
Мобильная версия и доступность
На телефоне проверяют не только ширину макета. Важны работа меню, кликабельные зоны, клавиатура в форме, возврат со страницы оплаты или внешнего сервиса, поворот экрана и скорость при обычном мобильном соединении. Для интерфейса с клавиатурной навигацией проверяют порядок фокуса и видимость активного элемента. Такие тесты не заменяют полноценный аудит доступности, но ловят очевидные ошибки до публикации.
Права редакторов тестируют отдельными учётными записями
Администратор не может подтвердить права редактора: у него слишком широкие возможности. Для каждой роли создают или используют тестовую учётную запись и проверяют, что она может изменить разрешённый материал, не видит закрытые разделы и не может опубликовать черновик без согласования, если процесс этого требует. Отдельно проверяют историю изменений и восстановление версии.
В результатах приёмки у дефекта есть шаги воспроизведения, ожидаемый и фактический результат, приоритет и решение. Формулировка «на мобильном что-то не так» не помогает исправить проблему. После исправления повторяют именно тот тест, который выявил дефект, и связанные сценарии, если менялся общий компонент.
Частые вопросы
- Кто должен участвовать в приёмке?
Заказчик подтверждает бизнес-сценарии и контент, техническая команда проверяет инфраструктуру и интеграции, а редактор тестирует свои права. Один участник не может заменить все роли.
- Нужно ли тестировать все браузеры?
Проверяют согласованный список браузеров и устройств, который соответствует аудитории сайта и договорённостям проекта. Ключевые сценарии проходят на каждом из них.
- Как оформлять найденные ошибки?
Укажите страницу или сценарий, шаги воспроизведения, ожидаемый и фактический результат, устройство и приоритет. Это позволяет проверить исправление без повторного толкования.
Итог
Приемка дает результат, когда тесты привязаны к маршрутам и ролям, а найденные дефекты можно воспроизвести. До публикации согласуют набор устройств, критерии блокировки и порядок повторной проверки.
Как подготовить набор тест-кейсов
Тест-кейсы группируют по функциям, а не по разделам меню: формы, поиск, каталог, доступы, письма, аналитика и ошибки. Для каждого набора определяют минимальный сценарий, который повторяется после изменения общего компонента. Так можно быстро понять, какие проверки нужны после правки в шаблоне формы или на странице услуги.
Приёмка не заканчивается списком закрытых задач. Заказчик получает перечень известных ограничений, доступы к результату и понятный порядок, куда обращаться при выявлении ошибки после публикации. Это помогает не превращать первые дни после запуска в спор о том, что считалось готовым.
Приоритеты дефектов
До начала тестирования согласуют, что считается блокирующей ошибкой, а что можно вынести в следующий выпуск. Например, недоступная форма или ошибка авторизации не равны неточному отступу в редком разрешении. Общая шкала приоритетов позволяет заказчику и исполнителю принимать решения по фактам, а не по громкости обсуждения.
