Код, покрытый тестами: где остановиться, чтобы не слить бюджет?

Многие команды стремятся достичь 100% покрытия кода тестами. Более того, в некоторых компаниях установлены высокие KPI (95-100%) на покрытие тестами кода. Высокое покрытие тестами - это отличная инвестиция в качество продукта. Однако высокое покрытие кода не гарантирует отсутствие ошибок, но дает дополнительные затраты на их написание и поддержку. Любая инвестиция должна быть рентабельной. Как понять что вложились достаточно и дальнейшие усилия принесут больше затрат, чем пользы?

Стремление к покрытию 100% кода тестами видится как идеал для любого проекта. Но если говорить о практической стороне, то 100% покрытие кода тестами практически не выполнимо. В некоторых случаях еще и слишком затратно.

⚠ Даже 100% покрытие кода тестами не гарантирует отсутствие дефектов. Тесты могут быть написаны формально, без проверки реальной логики работы. К тому же, покрытие всех строчек кода не гарантирует, что покрываются тестами все ветви и условия.

📈 После 80-90% затраты на написание тестов очень сильно растут (иногда даже экспоненциально). При этом, если проект активно развивается, то стоимость поддержки и исправления существующих тестов вносит значительный вклад в затраты на разработку.

Согласно исследованиям, для большинства систем 80% - точка, при которой тесты рентабельны (Google, исследование UBC, практика Циана).

Почему не больше?Фокус на критических частях кода (биллинг, данные пользователей) даёт лучшую рентабельность, чем погоня за 100%. Лучше покрыть 80% качественными тестами, чем добиться 100% покрытия фиктивными.

Если приложение находится на стадии прототипирования (MVP/MLP), то покрытие в 40–60% позволит быстро итерироваться и внедрять изменения, сохраняя при этом достаточное качество ПО.

100% оправданы для критического ПО - инфраструктурного, авионики, ядра банковских систем.

📌 Тип проекта:

🚀 Стартапы или прототипы - 40–60%
🏢 Корпоративные приложения - 50–90%
🛰 Высоконадежные системы (инфраструктура, авионика, ядра финтех) - 80–95%

📌 Критичность функциональности:

ключевые модули должны быть покрыты тестами на 80–95%

📌 Стадии проекта:

🏗 запуск проекта - 40–60%
⚡ активная разработка - 50–90%
🛡 стадия поддержки - 80–95% (тесты позволяют не вносить регресс)

🎯 Фокусируйтесь на критически важных частях кода - направляйте усилия на тестирование тех частей кода, где ошибки могут привести к серьезным последствиям.
✅ Преследуйте качество, а не количество - лучше меньше тестов, но более качественных.
💰 Анализируйте стоимость ошибок - необходимо определить, во сколько обходится исправление дефекта на разных этапах и в различных частях системы, а после формируйте необходимый уровень покрытия.
🔄 Пересматривайте стратегию - оптимальный уровень покрытия может варьироваться в зависимости от типа проекта, его сложности и жизненного цикла.

📖 Интересная статья - Циан отказались от 100% покрытия. После анализа багов снизили до 80%, что почти не повлияло на пользовательский опыт, но высвободило дополнительные ресурсы.

Мой канал в telegram

#development #testing #qa #management

Код, покрытый тестами: где остановиться, чтобы не слить бюджет?

Миф о 100% покрытии

🎯 Какой процент покрытия рентабелен

⚖ Факторы влияющие на рентабельность

🛠 Практические советы по достижению рентабельного уровня

🔗 Ссылки на материалы и исследования