Обновление автотеста - проблема разработчика который этот автотест сломал: нелььзя мёрджить код на котором падают тесты.

Боль началась с того момента, как появилась задача на обновление теста.

а у нас думаю совсем по другому:)

Ну или может попросить тестировщика помочь починить тест, если сам не может: садимся за парное программирование, клавиатура - у разработчика, тестировщик говорит что делать и где править

Когда фича зависит от того упадёт ли тест - постепенно исчезают все xpath и заменяются нормальными селекторами и как следствие - перестают падать.

У нас начинается регресс, автоматизатор запускает автотесты и потом тестировщики их разбирают, перепроходят, страдают...

Короче как в анекдоте про пожарного. Все нравится в своей работе, но как регресс, то хоть увольняйся

Я больше про не стабильные автотесты

Главное - не давать ставить таймауты побольше 😉 У нас это прописано как "требование по производительности": Страница грузится не более 30 секунд, элемент на странице обновляется не более 10 секунд. Да, в этом плане у нас плохо, что долго, но зато точно не будет страниц, которые грузятся дольше. + есть набор тестов, где эти параметры выставлены в 10 и 3 секунд соответственно и те тесты что там падают - идут на разбор к ребятам, которые чинят проблемы производительности.

разработчик считает, что он реализовал функционал и он готов..
а то что мерж потом ломает фукнционал , это проблема уже не его..  - он так думает

Ну вот, как только их начинают править разработчики - они сразу становятся сильно стабильнее 😉

Вот тут, помимо идеи "написал код, который сломал тест - чини тест", помогает ещё решительное выбрасывание всего, что реально нестабильное и не стабилизируется.

Это точно. Особенно, если без этой операции фича не едет релизится.
Единственная проблема, особо гордые чуваки, которые почему-то решили, что писать такой вид кода - это не для бояр

я бы не был так категоричен..
все зависит от приложения

Конечно зависит, всё от всего зависит.
Но если регресс занимает много времени, а ещё важнее - занимает львиную долю от всего доступного времени на тестирование, то польза от ручного труда падает.

Там где могли кинуться на новые фичи или просто лишний раз эксплоративно по продукту пройти, приходится раз за разом стабильный набор действий проходить.

Если у тебя тестируется то, что по видеопроводу приходит сигнал без артефактов и есть куча полубесплатных студентов, то можно и ручной регресс делать

Конечно, вопрос стоимости стабильных автотестов

Понятно, что отрисовку какого-нибудь OpenGL безартефактную проще мясной нейросеткой проверить

Это прямо вот 100%.