NovПосле релиза я проверяю не только новую страницу
Новая функция может сломать старую. Почему релиз NovAsia нужно смотреть по зависимостям, а не только по задаче разработчика.
Материал отражает практическую позицию указанного эксперта. Как готовятся и проверяются публикации — в редакционной политике NovAsia.
Новая страница может работать идеально и всё равно оказаться плохим релизом.
Она добавила компонент, который изменил старые карточки. Новый фильтр затронул URL. Обновление данных неожиданно сломало сравнение. Эти ошибки не находятся, если после задачи смотреть только на то, что только что создали.
После изменений в общем компоненте я беру несколько разных типов страниц — каталог, профиль застройщика и карточку проекта — и ищу регресс не только там, ради чего был релиз.
Сначала определяю радиус изменения
Не все релизы требуют одинаковой проверки. Правка одного текста почти не затрагивает соседние страницы. Изменение общей карточки, маршрутизации, источника данных или механизма языка может повлиять на десятки типов интерфейса.
Перед выпуском я стараюсь понять, что переиспользует изменённую часть: какие шаблоны подключают компонент, где ещё используется поле, какие маршруты зависят от правила, какие интеграции получают те же данные. Это и есть радиус изменения.
Такой подход экономит время лучше, чем попытка каждый раз проверить весь сайт. Мы тестируем шире там, где изменение действительно общее, и точечно — там, где оно локальное.
Проверка должна повторять реальные действия
Открыть страницу недостаточно. Нужно пройти сценарий: от каталога к проекту, добавить объект в сравнение, переключить язык, отправить форму, вернуться на мобильный экран.
Для изменения общей карточки я отдельно смотрю несколько типов страниц. Для работы с данными — места, где это поле появляется повторно. Для маршрутов — старые ссылки и перенаправления. Если затронут фильтр, проверяю не только красивый набор параметров, но и пустой результат, возврат назад и повторное открытие сохранённого адреса.
Есть ещё неприятный класс ошибок: всё работает в свежем браузере разработчика, но ломается после старого кэша, на узком экране или при возвращении назад. Такие случаи не всегда поймает простой автоматический тест.
После выпуска нужен способ быстро заметить то, что пропустили
Даже хорошая проверка не гарантирует, что все реальные комбинации были пройдены до публикации. Поэтому релиз удобнее считать управляемым, когда можно быстро понять, где возникла проблема и что именно изменилось.
Для меня это означает понятные журналы ошибок, возможность связать сбой с конкретной версией, предсказуемый откат критического изменения и небольшой набор контрольных страниц, которые легко перепроверить сразу после выпуска.
Чем больше переиспользования в системе, тем выгоднее разработка — и тем шире зона проверки. Релиз заканчивается не в момент, когда новый код работает. Он заканчивается, когда ключевые старые сценарии тоже остались живы.