Есть домены и проекты, где такой подход оправдан. Знаю embedded проекты, где большой порог вхождения и не только сложная логика, но и сложная техническая часть, а супер-подробные тест-кейсы являются спасением для новых людей в команде, что позволяет сократить онбординг с трех месяцев до одного-полутора. Потом такие тест-кейсы можно отдавать на автоматизацию. Там такой подход оправдан, но написание тест-кейсов занимает больше половины рабочего времени.
Всегда помните и используйте как аргумент, что самая большая проблема в любом тест-кейсе – это не написать его, а поддерживать его во времени. В целом, вам нужно просчитать, сколько времени занимает онбординг нового человека до момента самостоятельной работы + оценить сопутствующую продукту документацию (спеки, мануалы, хелпы). После этого посчитать, сколько времени вы тратите на написание одного теста в вакууме, спрогнозировать как часто он может меняться, узнать о приблизительном времени жизни проекта, прикинуть сколько примерно таких тестов может быть в системе. Тогда вы сможете нормально обосновать, что онбордин занимает столько-то времени, а создание-поддержание тестов такой вот детализации для всего проекта столько-то времени. Цифры можно сравнивать, остальное это гадание на кофейной гуще. На основании количественных показателей, можно аргументировано сделать выводы о целесообразности.
Если по цифрам увидите, что не целесообразна детализация такая, как они хотят, выйдите к руководству с контр-предложением, чтобы показать ваши знания, но и не отмести их идею. Приоритизируйте функционал по критичности, чтобы выделить самый важный, потом по стабильности – то, что не будет меняться в ближайшее время. Пересечение даст вам такой ранжированный список кандидатов на автоматизацию в первую очередь – критичный и более-менее стабильный функционал будет вверху. Предложите руководству, что тест-кейсы, которые будут по этому критерию выше оговоренной точки, будут максимально подробные, потому что это самый критичный функционал, плюс они первыми пойдут в автоматизации. Остальное по мере наличия времени и ресурсов.
Занимаясь написанием тестов, никогда не пишите один и тот же шаг разных тест-кейсов руками дважды – сделайте себе библиотеку, откуда будете брать шаги, прекондишены, тестовые значения. Как только нужно расписать точно такой-же шаг, как вы уже делали, вносите его в доку, которую организуйте так, чтобы было легко искать и копируйте. Для тестовых значений обязательно набейте простую таблицу типичных позитивных и негативных инпутов, чтобы не тратить время на придумывание, что вписать.
И начните вести статистику. Будущему вам нужно знать, сколько багов, которые были найдены в системе, были найдены благодаря тест-кейсам - сколько благодаря супер-подробным тест-кейсам, сколько благодаря обычным. Сколько багов «утекло», то есть было найдено не вами, а клиентами, несмотря на ваши тест-кейсы. Тогда можно поднимать вопрос, что может быть важнее покрыть каждое требование не одним позитивным кейсом, а увеличить их количество, перенаправив ресурсы с написания очень подробных кейсов на это дело.
