Практическое руководство

Как организовать тестирование новой версии сайта

Как проверять новую версию сайта: сохраняемые и изменённые сценарии, реальные данные, устройства, ошибки и выпуск.

Материал WebexlabПодготовлено 4 мин чтения

Краткий ответ

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

Определите, что должно сохраниться

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

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

Соберите проверочную матрицу

Соберите проверочную матрицу — сравнение
ОбластьОсновной сценарийИсключение
НавигацияНайти нужную страницуСтарый адрес
ФормаПринятая заявкаОшибка и повтор
ДанныеРеальное содержаниеДлинное или пустое поле
ИнтеграцияУспешный обменОтказ источника
РедакторСохранение измененияНедостаточные права

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

Используйте подходящие данные и устройства

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

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

Учебный пример новой формы

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

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

Проверьте реальные крайние случаи

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

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

Зафиксируйте готовность и остатки

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

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

Как выбрать устройства для приёмки новой версии

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

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

Термины из материала

Следующий шаг

Применить к вашему проекту

Подготовим программу проверки новой версии сайта и сопоставим результат с согласованными сценариями.

Обсудить задачу
Все материалы блога