Регрессия после правок дизайна: что проверить, чтобы не сломать то, что уже работало
Коротко: любая правка по дизайну — даже точечная, по одному комментарию из ревью — может задеть то, что никто не трогал. Поправили отступ в хедере — поехала карточка на соседней странице с тем же шаблоном. Такую проверку можно сделать своими силами по чек-листу ниже, а можно отдать внешней команде — например, специалисты по тестированию и IT-аудиту YuSMP Group берут на себя именно такие прогоны после релиза.
Смоук, регресс и «просто посмотреть» — почему это разные проверки
Смоук-тест отвечает на вопрос «сайт вообще жив после деплоя?»: открываются ли ключевые страницы, работает ли форма, не упал ли сервер. Это быстрая и грубая проверка, за пару минут. Регрессионное тестирование — совсем другое: это проверка, что уже работавшая функциональность не сломалась после изменения. А «просто посмотреть страницу глазами» — это ни то, ни другое: человек смотрит на то место, которое правил, и физически не видит побочный эффект в другом разделе сайта. Именно поэтому после правок дизайна нужен не беглый просмотр, а прицельная регрессионная проверка — по тем местам, которые теоретически могли задеть изменения.
Где прячется регрессия после правок по дизайну?
Правки дизайна редко живут в вакууме — чаще всего они используют общие компоненты и шаблоны, и именно это создаёт риск. Вот типичные места, где регрессия прячется чаще всего:
Правка в одном компоненте задевает соседний блок — например, изменили высоту карточки товара, и у неё поехала раскладка грид-сетки на странице категории. Изменение отступов ломает мобильную версию — десктоп выглядит аккуратно, а на узком экране текст наезжает на кнопку. Правка цвета или шрифта портит контраст и доступность — текст стал красивее на вид, но перестал читаться людьми с нарушением зрения. И наконец, правка в общем шаблоне задевает сразу все страницы, которые его используют, — а их может быть десятки.
Короткий сценарий из практики
Клиент оставил комментарий в Konndor: «сделайте кнопку CTA чуть крупнее и ярче». Разработчик внёс правку — и всё отлично смотрелось на той самой странице, где комментарий был оставлен. Но тот же компонент кнопки использовался на соседнем лендинге, и там увеличенная кнопка перекрыла поле формы захвата лида. Заметили это не сразу — а только когда упала конверсия на лендинге, который никто специально не проверял, потому что правку туда никто не вносил.
Кто должен проверять правки — дизайнер, разработчик или отдельный QA
На практике чаще всего происходит так: дизайнер утвердил макет, разработчик внёс правку и бегло посмотрел на результат, и все решили, что раз выглядит хорошо — можно релизить. Проблема в том, что «посмотрел и вроде ок» — это взгляд человека, который точно знает, что именно изменилось, и смотрит ровно туда. Он почти никогда не проверяет страницы, которые не трогал напрямую. Формальная проверка — это не недоверие к команде, а просто другой набор действий: заранее составленный список мест, которые нужно перепроверить, независимо от того, кажется это нужным или нет. В небольшой команде эту роль может взять на себя тот же разработчик, если у него есть чек-лист и время. В более крупных и частых релизах эту функцию логично выносить в отдельную проверку — свою или внешнюю.
Чек-лист: что проверить после внесения правок дизайна
Соседние страницы на том же шаблоне или с тем же компонентом — в первую очередь. Мобильная версия — отдельно от десктопа, а не «ну она же адаптивная». Формы и интерактивные элементы рядом с местом правки — кнопки, поля, выпадающие списки. Контраст и доступность, если менялись цвета или шрифты. Скорость загрузки, если правка затронула изображения или добавила новые ассеты. Кроссбраузерность по 2–3 ключевым браузерам аудитории продукта. И отдельным пунктом — визуальное сравнение «до/после»: для этого существуют специализированные инструменты вроде Percy или BackstopJS, которые автоматически подсвечивают пиксельные отличия между версиями страницы.
Когда стоит привлечь внешний аудит, а не проверять «на глаз»
Свой чек-лист закрывает большинство повседневных случаев. Но есть ситуации, где самопроверки уже недостаточно: крупный релиз с несколькими параллельными правками одновременно, изменение общего шаблона или компонента, который используется на десятках страниц, или просто отсутствие в команде отдельного человека, который формально отвечает за QA. В таких случаях разумнее не полагаться на беглый просмотр, а заказать независимую проверку — так регрессия находится до того, как её заметят пользователи, а не после.
Вопросы по теме
Нужно ли тестировать все страницы сайта после одной маленькой правки? Нет — но нужно проверить все страницы, которые используют тот же шаблон или компонент, который правили, даже если правка выглядит точечной.
Чем регрессия после дизайна отличается от регрессии после разработки фичи? Регрессия после фичи обычно связана с логикой и данными — что-то перестало считаться или сохраняться. Регрессия после дизайна чаще визуальная и затрагивает соседние элементы интерфейса, а не бэкенд — но от этого она не менее заметна пользователю.
Подробнее о разнице между регрессионным, смоук- и ретест-подходами можно почитать в материале Otus о регрессионном тестировании.
