Доброго времени, Хабр! Меня зовут Эдвард Аджей, я QA Head в Т-Банке. Год назад в одном из управлений было 17 команд с нулевым уровнем зрелости QA. Возникали сложности с автоматизацией, не велась работа с метриками качества и не было роадмапа развития процессов, накапливался техдолг по тестированию. Бесконтрольно формировался бэклог дефектов.
За три квартала мы внедрили внутреннюю модель зрелости QMM — живой инструмент, который помог снизить количество пропущенных дефектов в проде в разы, поднять автоматизацию на 30—40% и сэкономить до 15% времени QA-инженеров. Работа функции по обеспечению качества стала управляемой и прозрачной.
Но самое неожиданное — не метрики. А то, как модель изменила культуру: команды перестали ждать указаний и сами начали проводить оценку по QMM, активно формировать планы развития.
В статье рассказываю, как мы строили модель, почему отказались от готовых решений, как автоматизировали оценку и какие подходы оказались ненужными продуктовым командам. А еще есть рабочий прототип, который можно запустить у себя.
Почему не взяли CMMI и создали свое
Рынок разработки клиентских сервисов и ПО динамично развивается: функциональность продуктов растет, количество команд увеличивается — и каждая из них движется в своем направлении. В таких условиях высокое качество продукта — один из ключевых факторов успеха бизнеса, а измеримая и управляемая работа с качеством напрямую влияет на клиентский опыт. Чтобы снизить риски и помочь командам развиваться в правильном направлении, профессии QA нужны четкие ориентиры.
В Т-Банке много команд разработки — каждая со своими особенностями, технологическим стеком и подходами к обеспечению качества. С одной стороны, это здорово: способствует инновациям и гибкости. С другой стороны, может возникать ряд проблем:
❌ Разнородность подходов. Команды используют различные подходы к автоматизации тестирования, ведению тестовой документации, контролю дефектов, работе с метриками и так далее. Это приводит к дополнительным трудозатратам на выработку решений, которые можно было бы переиспользовать.
❌ Отсутствие оценки и, как следствие, разнородности. Нет способа комплексной оценки уровня зрелости выстроенных процессов QA в разных командах и отделах.
❌ Отсутствие ориентира. Команды не имеют четких ориентиров в развитии процессов QA. При этом сами команды запрашивали такие ориентиры — это одна из ключевых потребностей, чтобы профессия QA могла помочь в развитии зрелости.
❌ Отсутствие шаринга ресурсов. Нет возможности поделиться ресурсами между командами, отделами или управлениями, так как при разнородности подходов возникают большие трудозатраты на онбординг.
Мы изучили существующие модели зрелости, такие как CMMI, модель зрелости от AvitoTech, и другие, и пришли к выводу, что готовые решения нам не подходят. Одни не покрывали необходимый объем, другие были перегружены и ориентированы на более общие процессы разработки. Нам нужна была модель, специализированная под возможность оценки зрелости команд с точки зрения процессов QA.
Определили, какие потребности должен закрывать инструмент:
✅ Развитие инженерной культуры. Необходимо дать командам четкий ориентир для развития и повышения профессионального уровня.
✅ Оценку зрелости процессов QA. Это возможность оценить зрелость процессов QA в каждой команде в разрезе определенного набора подходов, таких как, например, автоматизация, метрики качества, нагрузочное тестирование, анализ покрытия кода, работа с дефектами и так далее.
✅ Поддержка новых команд. Предоставить новым командам возможность внедрять нужные подходы и правильно развивать их согласно рекомендациям.
✅ Обеспечение доступности знаний. Сделать информацию о подходах и рекомендациях доступной всем сотрудникам компании.
✅ Гибкое развитие зрелости. Предоставить возможность плавного развития зрелости по каждому подходу, учитывая индивидуальный темп команд.
После определения потребностей мы сформировали рабочую группу из экспертов профессии QA. Выбранные эксперты представляли разные команды, направления и бизнес-линии, что обеспечило разносторонний взгляд при проработке модели. Потом мы определили ключевые подходы, из которых будет состоять модель, и описали все уровни зрелости для каждого навыка.
Устройство модели QMM: уровни зрелости, навыки и подходы
Quality Maturity Model (QMM) — структурированный подход к оценке текущего состояния процессов QA в командах разработки. Помогает выявлять процессы QA, которые стоит улучшить, а еще определить приоритетные направления развития навыков и подходов.
Модель состоит из нескольких компонентов:
Уровни зрелости команды.
Набор навыков и подходов, каждый из которых содержит 4 уровня зрелости.
Мы выделили четыре уровня зрелости команды, каждый из которых характеризуется степенью развития процессов QA, используемыми инструментами и подходами к управлению качеством. Команды могут находиться на разных уровнях по разным направлениям, и это нормально.
После того как определились с детализацией по каждому уровню зрелости команды, наша фокус-группа проработала навыки. Каждый навык разбили на несколько уровней зрелости. Навык состоит из требований к уровню, артефактов для подтверждения уровня и рекомендаций по развитию.
Учет специфики команд. В нашей компании есть специфика разделения на типы команд:
Product Team. Команда решает продуктовые задачи, разрабатывает продукт (или его часть, если он большой) и улучшает различные продуктовые метрики. За командой может быть закреплен руководитель продукта, у команды есть все компетенции для решения продуктовых задач. Через свой продукт команда может влиять на бизнес, помогать компании достигать высоких целей.
Platform Team. Команда занимается разработкой и поддержкой платформы или инфраструктуры, на которой работает компания. Отвечает за создание технической основы, необходимой для работы сервисов и приложений. А еще предоставляет продуктовым командам self-service, упрощающие выполнение задач по унификации процессов и предотвращению дублирования кодовой базы.
Service Team. Команда разрабатывает сервисы или инструментарий для целей продуктовых команд. Продукт сервисной команды служит для упрощения рутины продуктовой команды, может помогать в повышении скорости разработки и поставки бизнес-ценностей. Для данного типа команды характерно более тесное взаимодействие с продуктовыми командами.
Мы решили, что важно учитывать специфику команд. Например, если платформенная команда нуждается в высокой стабильности и надежности, у них должен быть хорошо прокачан навык автоматизации и нагрузочного тестирования.
Продуктовая команда может разрабатывать внутренний сервис, у которого небольшой объем обращений к сервисам. В таком случае навык по нагрузочному тестированию менее приоритетный и можно сконцентрироваться на других навыках. Для команд, где нет тестовых стендов или взаимодействия с внешними сервисами, некоторые практики могут быть неприменимы.
Сейчас наша модель охватывает 15 навыков:
Автоматизация тестирования в процессах поставки.
Процессы ревью.
Организация работы с техдолгом.
Работа с пирамидой тестирования.
Метрики автоматизации.
Метрики качества.
Нагрузочное тестирование.
Поддержка тестового стенда.
Тестовые данные.
Agile Testing.
Тестовая стратегия.
Работа с дефектами.
Управление тестовой документацией.
Работа с инцидентами.
Влияние на customer experience.
В планах — расширить модель. Мы постарались подробно описать все необходимые требования к каждому уровню зрелости навыка, примеры артефактов и рекомендации для перехода с каждого уровня зрелости на следующий.
Раньше я публиковал статью по работе с техническим долгом, которая демонстрирует достаточно зрелый подход, раскрывает детали и выходит за рамки профессии QA.
Шаблон для работы с моделью зрелости QMM
Для облегчения оценки зрелости QA в командах мы разработали специальный шаблон. По нему создается страница оценки команды по модели зрелости с перечнем навыков и подходов. Этот шаблон структурирует процесс самооценки и позволяет каждой команде сформировать индивидуальный отчет, отражающий текущий уровень зрелости.
Модель можно использовать:
Для первичной оценки текущего состояния QA-процессов в команде.
Выявления слабых мест и приоритетных направлений развития.
Планирования работ по улучшению процессов QA.
Отслеживания прогресса развития команды во времени.
Сравнения зрелости между командами внутри отдела/управления.
Формирования ОКР и целей по развитию QA-компетенций.
Чтобы гарантировать качество проведения оценки по модели зрелости, есть этап «Ревью эксперта профессии QA». Эту роль выполняет опытный QA Lead отдела или направления, который хорошо разбирается в практиках и подходах QMM. Бывают кейсы, когда команда может завысить себе оценку — случайно или намеренно. В такой момент эксперт может дать объективную обратную связь, оценить артефакты и оставить рекомендации по улучшению уровней.
Правило перехода между уровнями зрелости. Изначально правило выглядело так: если у команды подходы на уровне «Развитие(1)», но при этом хотя бы один из подходов на уровне «Начальный(0)», в таком случае ставим уровень зрелости «Начальный(0)». После того как команда подтягивает все подходы до уровня 1, общий уровень зрелости будет «Развитие(1)».
После того как мы опробовали модель на фокус-группе пользователей и собрали обратную связь, одним из изменений было снижение порога перехода на следующий уровень.
Теперь при оценке общего уровня зрелости команды требования к переходу на следующий уровень — 85% от навыков следующего уровня. Например, всего в модели 15 навыков, из них 1 неприменим в команде. Получается что реально используемых навыков 14. Из них 12 на уровне 1 и еще два навыка на уровне 0. Получаем: 12 / 14 = 0,857, или 85,7%. Значит, можем поставить уровень зрелости 1.
Опыт внедрения модели зрелости QMM
Теперь поделюсь опытом внедрения в управление разработки социальных платформ инструмента QMM. Управление было новым, собранным из разных команд, ранее не взаимодействующих друг с другом или полностью новых.
Мы не знали, как команды живут в части процессов QA, какие у них сложности, сильные и слабые стороны. Чтобы понять исходное состояние, я поставил отделам управления задачу провести оценку по модели зрелости, чтобы определить текущее состояние процессов QA внутри команд.
Мой план состоял из таких пунктов:
Определить текущее исходное состояние по процессам QA. Снять замеры.
Выделить фокусные направления развития.
Начать работу над фокусными направлениями. Поставить цели и ОКР.
Проанализировать результаты.
После того как команды провели оценку по модели, я выступил экспертом и провел ревью этих оценок. Часть ревью делегировал своим подчиненным QA-лидам, а еще свел результаты в одну сводную таблицу по управлению. Большинство команд получили нулевой уровень зрелости — это подсветило большой объем необходимой работы по выстраиванию процессов QA в таких командах.
Фокусными направлениями определили автоматизацию и выравнивание пирамиды, работу с техдолгом, метрики качества и автоматизации и нагрузочное тестирование. Направления выбрали на основе тех проблем и потребностей, которые обнаружили в новых командах.
Дальше шла обширная работа по целям и их достижению. Нужно было подтягивать критично важные навыки и процессы QA. На основе модели я составил план развития, разбил его на задачи и поставил их QA-лидам, а они QA-инженерам в квартальные цели. Закрыв фокусные направления, команды постепенно подтягивали остальные практики и подходы для достижения следующего уровня зрелости.
После работы над каждым навыком проводилась повторная переоценка на соответствие требованиям и прикреплялась доказательная база в виде артефактов, подтверждающих переход на следующий уровень.
Подводя итог, хочу похвастаться, что за три квартала удалось перетащить 17 команд с уровня 0 на 1, а еще 3 команды находятся в процессе перехода на уровень зрелости 2.
Какой эффект от перевода на следующий уровень зрелости? В среднем каждый следующий уровень модели дает 10—15% улучшения метрик по времени на тестирование, кратное снижение количества пропущенных дефектов прода, рост процента автоматизации в среднем на 30—40%, снижение техдолга внутри QA-профессии.
Большой шаг к автоматизации модели зрелости QMM
Наша модель QMM имеет описание требований и всю механику работы на страницах в wiki. А чтобы как-то анализировать уровень зрелости команд внутри управлений (допустим, 20—30 команд), приходилось изощряться, строить большие таблицы, которые достаточно сложно заполнять, поддерживать и анализировать. А еще это большая рутина!
Это и подтолкнуло меня к автоматизации модели зрелости. Я решил попробовать собрать проект MVP для QMM — необходимый минимум, который позволил бы в едином удобном пространстве вести оценку зрелости команд, то чего мне так не хватало на wiki-страницах, и снизить рутину.
Возможности, которые мне удалось реализовать в MVP проекта QMM:
Реализован CRUD операции по командам. Можно добавлять, редактировать и удалять команды.
Реализована звезда навыков, которая показывает уровень зрелости по всем навыкам модели зрелости
Реализована возможность указать и валидировать уровень навыков.
Аналитический модуль содержит метрики по командам, динамику зрелости среднее значение зрелости внутри отдела и управления.
Реализован расчет уровня зрелости команды на основе правила, которое я ранее упоминал, в котором для перехода на следующий уровень нужно 85% навыков.
Используются искусственные тестовые данные, чтобы показать концепцию работы и визуального подхода к построению удобного инструмента оценки зрелости команд. Это не наши внутренние требования, а возможность дать пощупать инструмент.
А здесь спрятали много классных скриншотов проекта:
Создание команды происходит через простенькую форму, после чего команда отображается в оргструктурном дереве.
После выбора команды попадаем на главную страницу команды. Там отображается звезда навыков, тип команды, критичность и общий уровень зрелости.
Во вкладке «Company Metrics» аналитический модуль: количество команд, статус по оценке, средний уровень навыков, динамика зрелости команд, пай-чарт распределения по уровням.
Аналитический модуль содержит рейтинг команд и можно устраивать некое соревнование по качеству =) А также тепловая карта.
Хотя что нам смотреть скриншоты? Можно посмотреть реальный работающий прототип на GitHub!
Что дала QMM: экономия 10—15%, рост автоматизации, развитие инженеров и команд
Снижение трудозатрат. С развитием уровня зрелости по QMM снижаются трудозатраты за счет повышения зрелости практик и подходов QA. Например, внедрение автоматизации и выстраивание правильной пирамиды тестирования на этапе разработки позволяет сократить количество разрабатываемых проверок на этапе QA, снизить количество объемных системных тестов в сторону их переноса на более низкие слои, исключить дублирование тестов. В конечном итоге это освобождает ресурс QA.
Экономия может составлять в диапазоне 10—15% затрачиваемого времени на процессы QA — зависит от зрелости подхода. Например, если возьмем человеко-часы QA-инженеров с уровнем зрелости процессов «Развитие(1)», возьмем также их ФОТ и сделаем расчеты с учетом экономии 10% их времени, на дистанции это уже выглядит весьма весомо.
Снижение стоимости дефектов. Стоимость исправления дефекта в продуктиве может быть в 5—10 раз выше, чем на более ранних стадиях. Например, зрелость подхода по работе с метриками качества и покрытием тестами позволяет контролировать количество дефектов, снижая риски возникновения на более поздних стадиях разработки ПО.
Увеличение эффективности использования ресурсов. В модели есть подходы по унификации процессов, внедрения метрик, автоматизации и нагрузочного тестирования. С развитием зрелости этих подходов в QMM команда может выполнять больше задач за одно и то же время. Так бизнес получает больше ценности, используя тот же объем ресурсов.
Повышение стабильности продукта. Зрелые QA-процессы обеспечивают стабильность выпускаемых версий, что снижает вероятность критических сбоев в продукте. Это укрепляет доверие со стороны пользователей и клиентов, снижает нагрузку на техподдержку и уменьшает вероятность финансовых потерь из-за ошибок в продукте.
Сейчас оценку по модели зрелости успешно прошли более 200 команд. Мы собрали обширный и ценный набор данных, стали гораздо лучше понимать текущее состояние процессов QA в различных командах. Полученные данные не только отражают текущий уровень зрелости, но и позволяют выявить области для улучшения, определить приоритетные направления развития и разработать индивидуальные планы роста каждой команды, способствуя повышению общей эффективности и качества наших продуктов.
Модель зрелости процессов обеспечения качества (QMM) стала результатом осознанной потребности в систематизации и улучшении подходов к QA в масштабе нашей компании. В условиях динамично развивающегося рынка и растущей конкуренции обеспечение высокого качества продуктов является критически важным фактором успеха, и QMM — инструмент для достижения этой цели.
Перспективы развития инструмента QMM:
Расширение модели за счет включения новых навыков и подходов, таких как работа с искусственным интеллектом (AI) в QA. Это позволит учитывать последние тенденции в области тестирования.
Автоматизация оценки нужна, чтобы снизить трудозатраты экспертов QA для ревью оценки по модели зрелости.
Автоматизация заполнения модели. Интеграция QMM с внутренними ресурсами, позволяющими в автоматическом режиме подгружать необходимые данные по командам.
Вклад во внутреннее QA-community, обмен опытом и зрелыми практиками QA между командами, который позволит ускорить процесс повышения зрелости QA во всей организации.
Заключение
Модель зрелости процессов обеспечения качества — это ценный инструмент для повышения эффективности и качества процессов QA. А еще она нужна для развития инженерной культуры.
QMM — это инвестиция в будущее, направленная на повышение эффективности использования ресурсов, создание более надежных, стабильных и удобных продуктов для клиентов.
Поделитесь в комментариях вашим мнением о модели зрелости. Возможно, у вас есть свои внутренние инструменты оценки — будет интересно обменяться опытом!