← Все кейсы

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

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

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

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

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

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

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

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

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