Когда использовать регрессионное тестирование при изменении наименования сайта?
Что проверяют
Умеете ли вы оценить влияние изменения и подобрать объём регрессии, а не отвечать «гоняем полный регресс» или «это же просто текст». Следом спрашивают, что изменится в плане, если вместе с названием меняется домен.
Как отвечать
Регрессия нужна всегда, вопрос в объёме. Начните с анализа влияния: поиск старого названия по коду, шаблонам, файлам локализации, конфигам и медиа даёт список затронутых мест.
Если меняется только название:
- интерфейс: шапка, подвал,
<title>, мета-теги и Open Graph, favicon, логотипы, страницы 404 и 500; - сгенерированное: письма, SMS, пуш-уведомления, PDF и счета. Их шаблоны часто лежат отдельно от сайта;
- юридические тексты: оферта, политика конфиденциальности, реквизиты.
Если меняется домен, объём резко растёт:
- редиректы: старые адреса отдают 301 на соответствующие новые страницы, а не на главную, без цепочек;
- авторизация: куки привязаны к домену, пользователи разлогинятся; вход через OAuth сломается, если redirect URI зарегистрирован на старый адрес;
- интеграции: callback-адреса платёжного шлюза, вебхуки, CORS, CSP, сертификаты;
- аналитика и SEO: счётчики,
canonical,sitemap.xml,robots.txt.
В автотестах проверки на текст названия и локаторы по тексту упадут, их правят в том же изменении. После выкладки полезен короткий смоук на проде.
Где спотыкаются
Проверяют только видимые страницы и пропускают письма и документы. Клиенты потом получают счёт со старым названием.
Путают 301 и 302 или ведут все старые адреса на главную. Поисковик теряет накопленный вес страниц, закладки пользователей ломаются.
Не обосновывают объём. Полный регресс на смену строки в конфиге так же плох, как его отсутствие при переезде на новый домен: ответ сильнее, когда объём привязан к риску.