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

Но 1 из тестировщиков обнаружил что конкретный тест не ловит конкретный дефект. И выяснилось что когда-то (1,5 года назад) в коде было создано нечто вроде заглушки, которая пропускает этот тест, а в отчете устанавливает ему статус Passed. Тот кто это сделал - уже давно уволился, однако этот инцидент послужил поводом к внедрению практики code-review.

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

Если кодинг это твоя единственная задача - тогда логично преследовать цель "код должен быть идеальным и красивым"... Но кодинг это далеко не единственная задача тестирования. И когда трудозатраты на кодинг увеличиваются во много раз - это не может не ударить по остальным задачам.

Выход в пром тоже отложили. Мол пока код автотестов недостаточно красивый - в пром выходить нельзя. (хотя проект уже лет 8 как в проме и за это время красота автотестов никого не волновала)