100% трассируемое покрытие тестами: миф или реальность

«У нас 80% покрытия», фраза, которая успокаивает менеджеров и почти ничего не говорит о качестве. Покрытие по строкам кода легко накрутить и легко обмануть: тесты есть, метрика зелёная, а критичные сценарии не проверены. В AI SDLC покрытие измеряется иначе, по трассируемости артефактов.

Почему процент строк обманчив

Строчное покрытие отвечает на вопрос «выполнилась ли эта строка во время теста», но не на вопрос «проверили ли мы, что система делает то, что требовалось». Можно иметь 90% строк и при этом ни одного теста на ключевое бизнес-правило.

Тесты из трёх источников

Тесты не пишутся вручную постфактум, а создаются из моделей предыдущих этапов. Каждый источник отвечает за свой уровень проверки.

• Требования → функциональные тесты: проверяем, что система делает то, что нужно бизнесу
• Архитектура → интеграционные тесты: проверяем взаимодействие компонентов
• Код → unit-тесты: проверяем логику на самом нижнем уровне

Почему тесты не устаревают

Самая дорогая проблема тестирования, не написать тесты, а поддерживать их в актуальном состоянии. Поскольку в AI SDLC тесты создаются из моделей, при изменении кода или требований они автоматически актуализируются. Устаревшие и дублирующие тесты просто не накапливаются.

Сквозная цепочка требование → use case → тест → дефект всегда показывает, что именно покрыто и почему. Когда находится баг, видно, какое требование он затрагивает и какие тесты должны были его поймать, а значит, и где пробел в покрытии.

Что это даёт на практике

• Меньше регрессий: изменения не ломают непокрытые сценарии незаметно
• Быстрый аудит качества: трассируемость, готовый аудиторный след
• Прозрачность для бизнеса: видно, какие требования реально проверены