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