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

1. Все виды тестов должны писать именно разработчики.

К этому экстремальщики пришли ещё в нулевые, о чем и написали в поворотной для индустрии книге Continuous Delivery. Потом это подтвердилось в исследованиях DORA. И, например, в гугле оно сейчас именно так.

Почему так? Потому что тест, поведение и код связаны между собой один к одному. Меняя одно, вы просто обязаны поменять другое

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

Если вы признали ошибку, есть ли вариант выкарабкаться?

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

2. Тесты - командная практика.

Достаточно, чтобы хотя бы один человек в команде не писал тесты или писал их как-то не так, чтобы в тестах появились многочисленные дыры. А если в тестах есть дыры, то к тестам нет доверия. И все прахом - рефакторинг уже небезопасен, релиз по одним лишь автотестам невозможен.

Когда в 22 году компания, где я работал в замечательной экстремальной команде, перестала работать с русскими, я снова начал искать способ попасть к каким-нибудь экстремальщикам. И... у нас я таких не нашёл. Пришлось начать собеседоваться на лидовые позиции, чтобы сделать свою команду.

И вот тут обнаружилась другая проблема: работодатели лидов рассматривают, как правило, в частично или полностью набранные команды. А если людей подбираю не я, то и нет никакой гарантии, что они будут писать тесты. И, значит, нужно было искать место, где бы мне доверили набор всей команды. И вот эта ставка сработала идеально.

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

3. Безукоризненная дисциплина.

Я часто встречал людей, которые вроде очень серьёзно относятся к тестам, но когда речь доходит до дела, они так торопятся и боятся сорвать сроки, что тесты тут же отбрасываются, как бедный родственник. Когда ты добил фичу, и она работает, а сверху торопят со следующей, тут уже правда, как будто, не до тестов. Буквально месяцок в таком темпе, и вы уже вряд ли восстановите покрытие в ближайшей перспективе.

Решение должно быть волевым: без тестов фича не готова. Но, если честно, я знаю всего 2 варианта, как этого добиться.

Либо адамантиевая дисциплина и несгибаемая воля лида и команды, не позволяющие, невзирая ни на какие опоздания по срокам, сдвинуться с места, если тесты не написаны.

Либо более надёжный, но технически менее простой вариант - тдд. С тдд вы никогда не попадёте в такую ситуацию, когда все работает, и осталось только покрыть тестами, но между тестами и новой фичей вы вынуждены выбрать новую фичу из-за давления сроков и бизнеса.

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

4. Несостоятельные тесты.

Вот допустим, что все разработчики пишут тесты, покрытие 100%. Значит ли это, что у вас полностью автоматическое тестирование? Нет.