Подумалось, что зрелость тестирования похожа на CMM и тоже разбивается на несколько стадий.
Начальная стадия
Тестирование, как таковое, отсутствует. Все изменения вносятся сразу на продакшн, либо заливаются на него либо вообще без тестирования, либо с минимальным (скомпилировалось - отлично, выкладываем). Работа программиста выглядит как постоянное подпирание накренившихся модулей и затыкание протечек. Стоит разработчикам отвернуться - все тут же крашится. Новый функционал вносить страшно - можно ненароком задеть соседние модули в самых неожиданных местах. Тестировать страшно (очевидно, будет найдена куча ошибок) и совершенно не ясно с какой стороны к этому подходить.
Повторяемая стадия
Внезапно, разработчики обнаруживают, что если на бумаге описать сценарии тестирования, то тестировать становится гораздо проще, а вносить изменения не так страшно. Единственный продакшн начинает расслаиваться на отладочный, релизный и стабильный. На рабочую версию изменения не заливаются без прохождения всех описанных сценариев.
Установленная стадия
Тестирование автоматизируется. Сложный функционал вносится без опасения сломать систему. Архитектура системы начинает адаптироваться под тесты и, как следствие, понижается связанность между модулями.
Уровень 1.
Пишутся тесты для простейших классов и методов. С одним входом и выходом.
Уровень 2.
Тесты выполняются на единственной большой тестовой базе. Тесты очень хрупкие: важен порядок выполнения, регулярно возникают коллизии между тестами.
Уровень 3.
Тестовые данные разбиваются на фикстуры и каждый тест запускается в изолированной среде.
Уровень 4.
Взаимодействие с внешним миром тестируется при помощи стабов и моков.
Уровень 5.
Тестируется пользовательский интерфейс?
Пишутся интеграционные тесты?
Управляемая стадия
Видел одним глазом. Запрет на внесение нового функционала без покрытия тестами и документирования внесенного кода.
Оптимизированная стадия
1. Magic
2. ???
3. Profit
