100%-ное тестовое покрытие не обеспечить никак, увы.
У меня вот, например, тож есть такой проект - пишется уже очень долго, думаю там и за 15000 часов перевалило. (я его приводил в пример в первом посте). Как вышел я с ситуации - писал, но повторюсь
С меня требовали покрытие кейсами или чек-листами. Я уперся, потому что понимал, что покрыть кейсами никак нереально, затраты времени неописуемые(для полного покрыти нужно оченьмного времени потратить). Таки доказал, что это не возможно и оно того не стоит. Требовали дальше покрытие чек-листами. Я снова уперся, не захотел писать детализированный чек-лист (для нормального покрытия нужна хорошая детализация)- это тоже очень много времени потянуло бы. Я написал чек-лист с функционалом, который самый юзабельный, который пользователь 100% использует. А время, которое я потратил бы на написание детализированного чек-листа и прохождение его, я кинул на exploratory тестирование.
Выкатили нам билд с изменениями - мы тестим по чек-листу. Далее мы выполняем exploratory. Нада сказать, что качество проекта не страдает. Жалоб на него очень мало, хотя проект довольно таки сложный и логика запутанная, очень много разных прав в системе.
Поэтому: на моем примере, такой подход прошел. Да, у меня не описано все тест кейсами и чек-листами, ни матрицами, ничен не описано толком, но качество проекта приемливо и всех устраивает, а не к этому ли мы стремимся, коллеги? Поэтому, я считаю - что такой подход допустим.
Вот по сути и тестовое покрытие. Чек-лист + exploratory.
ЗЫ: изменения в проект вносятся постоянно. Проект давно в эксплуатации.
Замечу: у нас нет текучести кадров. Поэтому в проекте ориентируются все хорошо. Такой подход при частом смене штата может не пройти.
Ваша ситуация: вносятся изменения в проект...
Я бы поступал так в вашей ситуации:
1. Пинать прогеров, чтобы писали что могли задеть, когда вносили изменения. Тут 2 варианта есть дальше
а) Написали что могли сломать. Вы именно это все глядите (я бы тестировал, так как я описал выше, exploratory тут лучше всего годится по-моему). Если далее обнаружится ошибка в том, что прогеры не описали - их проблемы, их ответственность. Если в том что писали - тут да, проглядели
б) НЕ написали что могли сломать. Гадайте время на тестирование такое, чтобы хватило. Не дают это время - пожалуйста, техника risk based всегда рядом. Расписываем и пугаем начальство и заказчика если нада. Согласны на это - все, мы прикрылись. Не согласны - дискутируем и ищем решение.
Вот ответ на то, как быть с изменениями. Я бы поступал так.