← Все кейсы

Дизайнер переименовал класс — положил весь регресс

 Знакомая каждому QA картина: дизайнер обновил кнопку «Купить» — поменял класс с .btn-buy на .button--primary. Функционально ничего не сломалось, но 40 тестов, где был жёсткий селектор .btn-buy, дружно упали. Полдня разбора «это настоящая ошибка или просто переехал класс».

    Корень проблемы — хрупкие селекторы

 Тест, привязанный к конкретному классу или XPath, ломается от любой косметики. Он проверяет не «есть ли кнопка купить», а «есть ли элемент ровно с этим классом». Для пользователя кнопка на месте — для теста катастрофа. Это главный источник «ложных падений» и недоверия к автотестам.

    Как это делает TestMW

 Мы не привязываемся к одному селектору. За «человеческим» указанием — например, button:has-text("Купить") — стоит цепочка кандидатов: по роли, по тексту, по aria-атрибутам, по подписи. Робот пробует их по очереди и находит кнопку, даже если класс переименовали.

 А если шаг всё-таки упал — включается AI-анализатор падений. Он снимает состояние страницы, ставит диагноз понятным языком («кнопка найдена по тексту, но перекрыта баннером cookie») и предлагает патч сценария. Тест буквально подсказывает, как себя починить.

Пример анализирования и исправления теста с помощью AI

 В истории с переименованным классом наши тесты бы даже не заметили подмены — кнопка же по тексту «Купить» осталась той же. Ноль ложных падений, ноль потраченного на разбор времени.