Home

Всем привет! На связи снова Петрова Марина — QA Lead в Сloud.ru. Сегодня поделюсь опытом оценки и оптимизации процессов тестирования с помощью модели зрелости TMMi. Наша команда использует TMMi с третьего квартала 2022 года: за это время мы не раз оценили процессы и адаптировали модель для команд, которые работают в Agile-парадигме, но обо всем по порядку.

«В сущности, все модели неправильны, но некоторые полезны» — Джордж Бокс, британский статистик

Выбор модели зрелости процессов тестирования

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

Любые процессы требуют управления, а для эффективного управления необходимы метрики. Поэтому в корпоративном QA-сообществе задались вопросами: какие процессы, направленные на обеспечение качества, обязательно должны быть при разработке IT-продукта? Как количественно оценить процессы тестирования в командах? Какие практики нужно внедрить для улучшения процессов качества? С какой периодичностью выполнять переоценку?

Очевидно — ответить на них помогла бы модель зрелости процессов тестирования. Поэтому первым делом мы заглянули в материалы по ISTQB для руководителей. В разделе «Улучшение процесса тестирования» было перечислено несколько моделей оценки процессов:

• TMMi — Test Maturity Model,

• STEP — Systematic Test and Evaluation Process,

• CTP — Critical Testing Processes, 

• TPI Next — Test Process Improvement Next.

Из них мы выбрали TMMi. Почему? Во-первых, эта модель опирается на CMMI (Capability Maturity Model Integration) — популярный и уже практически классический инструмент для оценки и улучшения процессов в области разработки программного обеспечения и управления проектами. Во-вторых, эффективность оценки по TMMi подтверждают результаты исследований: Отчет TMMi об исследовании 2021, Всемирный опрос пользователей TMMi 2023. В-третьих — только у TMMi была исчерпывающая документация с рекомендациями и примерами по применению.

Расскажу, в чем основная суть модели TMMi и самой оценки.

Особенности модели TMMi

Модель состоит из пяти уровней, каждый из которых одновременно отражает степень зрелости команды и эволюционный путь к улучшению процесса тестирования. Уровням зрелости также соответствует несколько процессных областей. Перед оценкой команда выбирает, на каком уровне зрелости хочет себя оценить.

Уровень 1: Начальный

На первом уровне нет процессных областей т. к. тестирование является хаотичным процессом. Тестирование показывает, что программное обеспечение работает без серьезных сбоев, но качество продукта, чаще всего, не соответствует ожиданиям (сервис работает медленно и нестабильно, неудобен для пользователя). 

Уровень 2: Управляемый

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

Процессные области второго уровня:

• политика и стратегия тестирования

• планирование тестирования

• мониторинг и управление тестированием

• проектирование и выполнение тестов

• тестовое окружение

Уровень 3: Определяемый

Тестирование становится систематическим и последовательным процессом, который полностью интегрирован в жизненный цикл разработки. В компании зафиксирован набор стандартных процессов, проводится нефункциональное тестирование. Улучшение процессов тестирования — неотъемлемая часть общей практики в компании.

Процессные области третьего уровня:

• подразделение по тестированию

• программа подготовки по тестированию

• жизненный цикл и интеграция тестирования 

• нефункциональное тестирование

• экспертная оценка

Уровень 4: Измеряемый

На этом этапе тестирование уже имеет конкретные цели. У команды есть метрики для оценки качества, производительности и мониторинга улучшений. Они зафиксированы на уровне организации и помогают измерить качество продукта на каждом этапе жизненного цикла. Фокус на повышении эффективности и результативности.

Процессные области четвертого уровня:

• метрики тестирования

• оценка качества продукта

• расширенная экспертная оценка 

Уровень 5: Оптимизационный

На этом этапе происходит непрерывное улучшение процессов тестирования. Эффективность растет благодаря технологическим нововведениям и поэтапному внедрению инновационных процессов.  Тестированию характерны управляемость, измеримость, результативность,  эффективность и предсказуемость.

Процессные области пятого уровня:

• предотвращение дефектов

• контроль качества

• оптимизация процессов тестирования

Как же оценить, соответствует команда выбранному уровню зрелости или нет? По методологии в каждой процессной области содержится несколько целей, а также практики, которые команда выполняет для достижения этих целей. Чтобы определить уровень зрелости процессной области, нужно оценить выполнение этих практик. Для этого в методологии есть критерии и шкала оценки. Таким образом, общая оценка зрелости команды складывается из результатов оценок практик и целей по всем процессным областям.

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

Подготовка к оценке по TMMi

После выбора модели нам предстояло подготовиться к самой оценке. Мы планировали оценить, во всех ли командах процессы соответствуют второму уровню зрелости — управляемому. 

Процесс подготовки состоял из двух этапов: 

1. Изучения теории.

2. Адаптации критериев оценки: поскольку эталонная система TMMi не предназначена для оценки процессов в Agile-командах, мы планировали  самостоятельно ее адаптировать.

Изучение методологии оценки

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

1. TMMi-framework-r1-3 — подробное описание модели TMMi (релиз 1.3 от 2022 года). 

2. TMMi.TAMAR — подробное описание вариантов оценки и требований к их проведению. 

Авторы TMMI выделяют два формата оценивания: формальный и неформальный. Провести формальную оценку и официально присвоить компании уровень зрелости могут только аккредитованные специалисты. Неформальную оценку может провести как внешний, так и внутренний эксперт в области тестирования — в этом случае уровень TMMi присваивается неофициально. 

3. TMMi-Framework-Russian-Translation-LeanPubBook — правила проведения оценки для второго уровня на русском языке. Хотя перевод 2011 года можно считать уже неактуальным, материал хорошо помог нам при подготовке. 

4. TMMi-in-the-Agile-world-V1.4 — описание специфических критериев и практик для оценки команд, которые работают по Agile.

5. TMMi Lightning Scan Tool v2.2 — инструмент на базе Excel для команд тестирования, которые хотят провести быструю и упрощенную неформальную оценку. Она помогает быстро выделить области для улучшения и понять текущий уровень зрелости тестирования.

Можно проверить, соответствуют ли команды второму и третьему уровню зрелости.

Шкала оценивания имеет всего 3-варианта: да, частично и нет.

Также инструмент автоматически генерирует рекомендации по улучшению процессов.

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

В наших командах мы решили проводить неформальную полную оценку. Для этого запустили опрос по матрице оценки, чтобы понять, хватает ли нашим QA компетенций для самооценки. По итогу обнаружили пробелы в области работы с рисками и инициировали внешнее корпоративное обучение. 

Также нам предстояло самостоятельно адаптировать критерии модели под Agile-процессы.

Адаптация критериев оценки для Agile-команд

На этом этапе нужно было подобрать параметры оценивания для второго уровня зрелости, определить критерии успеха по каждой практике и рассчитать формулы для вычисления оценок TMMi-целей. В эталонной модели TMMi описаны цели и практики, часть которых неприменимы для Agile-команд. Нужно было адаптировать критерии с учетом особенностей гибких методологий: итеративность, коллективная работа, быстрые изменения требований. При адаптации критериев опирались на TMMi-in-the-Agile-world-V1.4, а также те практики и инструменты, которые уже были в Cloud.ru. 

Из-за изменчивости требований и сложности подготовки конкретного плана и графика тестирования, больше всего изменений мы внесли в критерии процессной области Планирование тестирования. Также учли требования в виде User Story, DoD (Definition of Done) и Acceptance-критериев.  Некоторые практики мы полностью исключили из оценки, поскольку они не несут ценности в контексте гибкой разработки. Несмотря на явное указание в TMMi-in-the-Agile-world-V1.4, что критерии начала тестирования не подходят для оценки гибкой разработки, мы все равно включили их в оценку. Для нас они не что иное, как Quality Gates. 

Оценивать, анализировать и хранить результаты договорились в Excel. В итоге получилась таблица с двумя листами: Критерии оценки и Шаблон оценки. 

На листе Критерии оценки для всех участников процесса мы зафиксировали правила оценки и расчета уровня зрелости TMMi:

На листе Шаблон оценки вносили сами результаты. Он содержит следующие столбцы:

• Раздел TMMi — список процессных областей, целей и практик для второго уровня зрелости.

• Участники — имя и фамилия сотрудников.

• Статус — оценка конкретной практики по дискретной шкале 0, 15, 50, 85, 100.

• Критерии оценивания — список артефактов и практик, которые должны быть в команде для оценки 100.

• Результаты — ссылки на артефакты и регламенты.

• Комментарий к статусу — обоснование выбранного статуса по конкретной практике.

Наш шаблон можно брать за основу и адаптировать его. В таблице нет конкретных критериев оценивания — лучше рассчитывать их с учетом особенностей конкретной команды, а иногда и отдельно для конкретной группы продуктов. В таблице есть пояснения к ячейкам. Красным цветом выделены практики, которые, как правило, не актуальны для Agile. Если в вашем случае они нужны — смело включайте в оценку.

Оценка зрелости процессов в командах

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

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

Первую оценку мы провели в интерактивном формате на общей встрече, чтобы коллегам было проще разобраться что к чему. По итогу оценки каждая команда составила Roadmap на квартал, в котором обозначила проблемы, зоны роста и практики, которые планировала внедрить. 

После каждой оценки (на момент выхода статьи мы провели их 5) мы делали сводный анализ по всем командам для поиска точек роста QA-комьюнити — стандартизации процессов, поиска новых инструментов и best-practice. 

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

Выводы и результаты оценки

В завершение хочу выделить позитивные и негативные моменты от внедрения оценки TMMi. Начну со сложностей и ошибок.

1. Первоначальную оценку по TMMi мы проводили по стандартным критериям, неадаптированным к Agile. Сложилось ложное впечатление, что основная часть практик неприменима в рамках нашей компании, но при дальнейшем погружении мы разобрались и исправились????

2. Мало QA-специалистов знакомо с моделями зрелости процессов тестирования, в том числе с TMMi (по опыту проведения собеседований). На изучение методологии нужно время, что снижает скорость проведения оценки.

3. В тестировании есть процессы, которые иногда выходят за рамки ответственности специалистов, например, реализация тестового окружения. Включать подобные практики в оценку или нет — технический лидер решает самостоятельно.

4. Оценка и переоценка — это дополнительная нагрузка на команду. 

5. С ростом числа команд Excel-таблицы становятся неудобными, нужно прокачивать навык использования электронных таблиц (макросы, сводные таблицы) или переходить на другие инструменты для хранения результатов.

Несмотря на все нюансы, модель помогает QA-сообществу Cloud.ru придерживаться общих стандартов, процессов и обмениваться опытом. Вот несколько улучшений и артефактов, которые случились после внедрения модели (скорее всего они и так случились бы с течением времени, но TMMi значительно ускорила их появление):

1. Обнаружили, что у команды недостаточно знаний и навыков в области управления рисками тестирования. В итоге организовали внешний тренинг для развития этой компетенции.

2. Создали универсальный корпоративный шаблон стратегии тестирования продукта. Стратегия тестирования помогает нам улучшить коммуникацию внутри команд и понимание процессов тестирования продукта, а также сбиться по ожиданиям от деятельности инженеров тестирования.

3. Стандартизировали шаблон ошибки для проектов в Jira — это помогло унифицировать процесс работы с ошибками, ускорить сбор метрик и создание новых Jira-проектов.

4. Создали в Jira дашборд с метриками ошибок по продуктам, который используем для анализа эффективности процессов тестирования и разработки.

5. Сформировали корпоративный реестр рисков тестирования — таблицу со списком рисков, их источников, возможных последствий и рекомендуемых мер профилактики. Дашборд помогает при планировании новой функциональности продуктов.

6. Сформировали прозрачный Roadmap развития процессов тестирования — на базе TMMi-оценки каждая команда планирует, как внедрить новые практики и улучшить существующие.

7. Задокументировали все процессы тестирования, которые есть в командах. Это помогло стандартизировать процессы и повысить скорость онбординга QA в компании.

Итак, за год использования модели нашей команде удалось продвинуться по целям во всех пяти процессных областях второго уровня зрелости. При этом упор мы делали на те области, которые получили минимальный балл после первой оценки: 2.1 Политика и стратегия тестирования и 2.2 Планирование тестирования. 

На гистограмме можно увидеть прогресс зрелости процессов тестирования по компании в целом за год — с третьего квартала 2022 года по третий квартал 2023 года. 

В наших планах довести уровень зрелости процессов тестирования до третьего уровня, а достижение четвертого и пятого — на усмотрение команды. 

А какие подходы к оценке и улучшению процессов тестирования используете вы? Делитесь в комментариях????

Что еще полезного есть в блоге:

• Измеряй и властвуй: как мы покрытие автоматическими тестами измеряли

• Создание системы документирования, или как в Cloud.ru от «ворда» к docs as code за месяц переходили. Часть 2

• Про формат Talks на YouTube-канале Cloud.ru Tech 

Обсудить в форуме