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

«Зрелость» — это что-то неосязаемое, что почти невозможно измерить на глаз. В этой статье разберём, что стоит за этим словом на практике, почему готовые отраслевые модели редко приживаются без изменений и как можно оценить процесс тестирования, не начиная с нуля собственную многостраничную методологию.

Зачем вообще измерять зрелость, если тесты и так пишутся

Тестирование может работать и без формальной оценки зрелости — команда находит баги, релизы выходят, все более-менее довольны. Проблема начинается на масштабе. Как только команд становится больше одной, также как и продуктов, разные группы неизбежно приходят к разным подходам: где-то ведут тест-кейсы в таблице, где-то в голове самого опытного тестировщика, где-то автоматизация покрывает половину функциональности, а где-то её нет вовсе.

Без внятного способа сравнить эти команды между собой руководитель QA оказывается в положении, где решения принимаются на ощущениях типа «вроде как у этой команды с процессами получше, надо делать так как у них» и т. п. Это плохая основа для распределения ресурсов, найма и разговора с бизнесом о том, почему тестирование стоит определённых денег.

Модель зрелости — это, по сути, линейка. Она не делает тестирование лучше сама по себе, но даёт общее понимание: что значит «хорошо», что значит «пока рано», и какой конкретный шаг ведёт от одного к другому.

Что предлагают готовые модели и почему их редко берут "как есть"

В индустрии тестирования есть два известных фреймворка для оценки зрелости.

Начнём с термина, на который они обе опираются. CMMI (Capability Maturity Model Integration) — модель зрелости процессов разработки ПО в целом, не только тестирования. Её разработал Software Engineering Institute при Carnegie Mellon University: в 1991 году вышла предшественница, Capability Maturity Model (CMM), а в 2000-м — собственно CMMI как её развитие. По сути это отраслевой стандарт: он описывает пять уровней зрелости организации — от «процессы хаотичны и зависят от конкретных людей» до «процессы измеряются, управляются и постоянно улучшаются на основе данных». CMMI используют для сертификации целых компаний, и он охватывает всю разработку — от требований до релиза, тестирование в нём лишь одна из областей.

Но для полноценной оценки зрелости именно команды тестирования эта модель не подходит — CMMI не даёт ответа, насколько глубоко проработаны конкретно QA-практики. Поэтому на основе той же логики были созданы две специализированные модели — конкретно под тестирование.

TMMi (Test Maturity Model Integration) — специализированная модель, построенная по той же логике, что и CMMI, но сфокусированная только на тестировании. Она описывает путь от уровня, где тестирование существует лишь для того, чтобы убедиться, что программа не падает сразу после запуска, до уровня, на котором дефекты предотвращаются на этапе проектирования, а не отлавливаются постфактум.

TPI Next — более гранулярная модель: 16 ключевых областей (от тест-менеджмента и коммуникации в команде до инструментов и тестового окружения) и 4 уровня зрелости для каждой. Модель матричная — можно быстро увидеть, где команда сильна, а где явно отстаёт.

Обе модели логичны и проверены временем, но у них есть общая проблема: они создавались для крупных организаций с выделенными процессными ролями и рассчитаны на месяцы внедрения силами консультантов. Для команды из 5–15 тестировщиков это, как правило, избыточно — слишком много терминологии, слишком мало связи с конкретными задачами конкретного продукта.

Поэтому многие компании поступают иначе: берут идею уровней зрелости из TMMi и TPI Next, но строят собственную, урезанную модель под свою специфику. Разберём, как это выглядит на практике.

Живой пример

В июле 2026 года QA Head Т-Банка опубликовал на Хабре подробный разбор того, как компания строила собственную модель зрелости QA — Quality Maturity Model (QMM). Кейс интересен именно тем, что в компании изначально пробовали взять готовые решения — CMMI и внутреннюю модель от AvitoTech — и отказались от обеих: одни оказались перегружены и ориентированы на разработку, а не на QA, другие не покрывали нужный объём задач.

Отправной точкой стала конкретная проблема: в одном из управлений было 17 команд с нулевым уровнем зрелости QA. Не велась работа с метриками, не было роадмапа развития процессов и бесконтрольно рос бэклог дефектов.

Модель, которую в итоге собрали, устроена так:

• 4 уровня зрелости команды — от начального до продвинутого, где команда сама поддерживает и развивает свои практики без внешнего давления;
• 15 конкретных навыков, каждый — с собственной шкалой из 4 уровней: автоматизация тестирования, работа с техдолгом, метрики автоматизации, метрики качества, нагрузочное тестирование, тестовые данные, работа с дефектами, управление тестовой документацией и другие;
• правило перехода на следующий уровень — не 100%, а 85% навыков должны соответствовать требованиям следующего уровня. Это защищает от ситуации, когда одна слабая практика блокирует признание прогресса по всем остальным;
• обязательный этап ревью: оценку, которую команда выставляет себе сама, проверяет опытный QA-лид — чтобы исключить завышение результатов.

За три квартала работы по этой модели 17 команд, начинавших с нулевого уровня, поднялись на уровень выше, ещё три — были в процессе перехода на второй уровень. Измеримый эффект: количество пропущенных в продакшен дефектов снизилось в разы, доля автоматизации выросла на 30–40%, а на процессы QA стало уходить на 10–15% меньше времени команды.

Интересное наблюдение: самым неожиданным результатом стали не цифры, а изменение поведения команд — они перестали ждать указаний сверху и начали сами инициировать оценку по модели и составлять планы развития. Формальная линейка зрелости, если она понятна и не воспринимается как бюрократия, превращается в инструмент, которым команда пользуется добровольно.

Как получить похожий эффект, если у вас не 200 команд, а одна

Модель Т-Банка построена под масштаб, недоступный большинству компаний — там был отдельный ресурс на разработку методологии, фокус-группа экспертов и впоследствии даже собственный внутренний сервис для автоматизации оценки. Но принцип, лежащий в основе, применим и для команды из нескольких тестировщиков.

Три шага, с которых можно начать, не запуская отдельный проект:

1. Выберите 4–5 навыков, а не 15. Для старта достаточно оценить то, что сильнее всего влияет на риск релиза: есть ли актуальная тестовая документация, ведётся ли учёт дефектов с приоритетами, какая доля регресса покрыта автоматизацией, есть ли базовые метрики качества (например, число дефектов, найденных после релиза, против найденных до).

2. Опишите для каждого навыка 3–4 уровня, а не абстрактную шкалу «плохо/хорошо». Уровень должен быть проверяемым: не «автоматизация развита», а «60% регрессионных сценариев покрыты автотестами и запускаются в CI/CD при каждом релизе».

3. Проведите первую оценку сами — и зафиксируйте её. Не для отчёта руководству, а как точку отсчёта. Модель зрелости бесполезна, если её не с чем сравнивать через квартал.

Здесь же стоит честно сказать: сама методология оценки — то, какие навыки в неё включить и что считать «уровнем 2», а что «уровнем 3» — это работа команды, а не программного продукта. Ни TMS, ни любой другой инструмент не построит эту модель за вас. Но инструмент способен снять с этой работы самую нудную часть: сбор данных, на основании которых оценка вообще становится возможной.

Что здесь может сделать TMS — а что нет

У большинства команд уже есть TMS для ведения тестовой документации — вопрос «в каком она состоянии». Часто тест-кейсы годами накапливались без единой структуры: одинаковые шаги описаны по десять раз в разных формулировках, теги и атрибуты никто не завёл, а история прогонов обрывается там, где кто-то в команде перестал её вести. Отдельная классика — интерфейс инструмента настолько перегружен, что реальную актуализацию документации откладывают, потому что просто больно туда заходить. В таком состоянии оценить зрелость так же невозможно, как и без инструмента — данные формально есть, но им нельзя доверять и с ними неудобно работать.

В DoQA для этого есть дашборд по каждому рабочему пространству: сколько новых тест-кейсов, чек-листов и багов появилось за период и с какой динамикой, как менялась активность команды, какая доля прогонов завершается успешно, а какая проваливается. Отдельно доступны отчёты по прогонам — их можно выгрузить в PDF и показать на встрече с руководством, не пересобирая вручную. Это данные, которые как раз и нужны, чтобы предметно ответить на вопрос «на каком мы уровне» — вместо «кажется, на 1/2/3/4 и вроде бы неплохо всё идёт».

DoQA ИИ в этой части тоже полезен без прямого отношения к модели зрелости: ревью тест-кейсов с рекомендациями по структуре и полноте описания снимает часть работы по актуализации документации — а именно устаревшая, неполная документация — один из тех навыков, что чаще всего оказывается на нулевом уровне зрелости у команд, которые никогда его не оценивали.

Иными словами: TMS не скажет вам, какой у вас уровень зрелости. Но без TMS вы, скорее всего, даже не соберёте данные, чтобы задать себе этот вопрос всерьёз.

Что в итоге

Модель зрелости QA — это не сертификат и не разовый аудит, а рабочий инструмент сравнения «где мы сейчас» и «куда движемся». Готовые фреймворки вроде TMMi и TPI Next дают полезный словарь и структуру, но крупным компаниям чаще приходится строить собственную, урезанную версию под свою специфику — как это сделал Т-Банк, получив измеримый эффект за три квартала без готовых решений.

Для команды меньшего масштаба смысл тот же: не 15 навыков и 4 уровня с первого дня, а 4–5 понятных, проверяемых метрик и честная точка отсчёта. Дальше — вопрос дисциплины и данных, которые для этой оценки нужно откуда-то брать.

Если у вас в команде тестовая документация до сих пор живёт в разрозненных таблицах — начать оценивать зрелость процесса будет сложно уже на первом шаге. Попробуйте DoQA — 14 дней бесплатно, без ограничений по функциональности, чтобы для начала просто увидеть свои процессы в одном месте.