эскалировать?. мне не очевидно, зачем QA разбираться с актуализацией кода разных бранчей.

Решит. Перед тем, как замержить в мастер, мержите мастер в фича ветку, прогоняете все тесты, разбираете падения и фиксите тесты/заводите баги, после этого мержите фича ветку в мастер

например если у вас выкатки не релизные а теговые по фичам) ну как один из примеров)

тут есть проблема которую нужно как то решить либо чинить тесты сразу либо нет. Есть на это ресурсы? ок. Нет? ну... Другой вопрос, что проект стал развиваться и возможно тесты нужно будет переписывать несколько раз, возможно лучше подождать пока продукт стабилизируется.

тоже не вариант, пару лет не будет стабилизации) + будет рефакторинг) и вот тут как раз важны будут тесты регресса.

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

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

что то я запутался) вы хотите и тесты не анализировать и что бы они актуальные были?

ну ответ тот же успеваете делайте, нет ну будет какой то компромис

Нуууу, это ведь всё тестовый процесс) Тестовые сценарии, руками протестить, написать автотесты, проанализировал результат)

ну это понятно) просто думал кто-то делал что-то подобное в ркупном проекте и поделится подводными камнями) ишибками и советами)

ну мой пример из крупного проекта) тесты отключали до лучших времен))

а как происходил процесс? Вы понимали что функционал в какой-то из веток нарушит работу тестов и отключали их везде?

ну тесты не давали создать билд т к падали люди лезли разбираться и отключали т к они либо флакали, либо становились не актуальными и их нужно было переписать. Так же тут есть опция починить тест сразу, что и делается в случае unit тестов за которые точно разработчики отвечают как  то так

Есть ещё альтернативный вариант - писать автотесты только на относительно стабильный участок кода, который не меняется каждую неделю. А изменяемые часто вещи оставить на тестирование вручную, пока они не станут стабильными. Иногда поддержание кода автотестов стоит дороже, чем ручное тестирование. Здесь нужно найти какой-то баланс. Нельзя сказать нечто конкретное, не варясь именно в вашей инфраструктуре.

Плюс, если у вас постоянно в продукте меняются интерфейсы, то стоит выяснить почему так происходит. Не всегда этому есть крайне важная причина. Иногда разработчики могут что-то поменять, так как им внезапно захотелось рефакторинга (не шучу, честное слово).

P.S. Это лишь одно из мнений дополняющее все остальные. Ничего большего. :)

я думал один из столпов автотестов)

вот мне часто кажется, что злоупотребляют изменениями. Часто меняют ключи, назвения, структуру, потому-что удобнее, чем копаться в старом коде. Вот если есть совет как лучше отлавливать такое и доносить, что так делать плохо, тоже был бы благодарен)

Nope.

ну тут еще стоит разобраться плохо делают или хорошо) звучит как хорошо.

А что говорят разработчики/техлид/цто/whatever на вопрос «а зачем мы здесь поменяли структуру/ключи/формат»?