Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Всем привет! На связи снова Петрова Марина — 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
После выбора модели нам предстояло подготовиться к самой оценке. Мы планировали оценить, во всех ли командах процессы соответствуют второму уровню зрелости — управляемому.
Процесс подготовки состоял из двух этапов:
Изучения теории.
Адаптации критериев оценки: поскольку эталонная система TMMi не предназначена для оценки процессов в Agile-командах, мы планировали самостоятельно ее адаптировать.
Изучение методологии оценки
Чтобы правильно и эффективно провести оценку, сначала мы погрузились в теорию. Основную часть материалов нашли на официальном сайте TMMi, но использовали и другие источники. Познакомились с материалами на английском и русском языках:
TMMi-framework-r1-3 — подробное описание модели TMMi (релиз 1.3 от 2022 года).
TMMi.TAMAR — подробное описание вариантов оценки и требований к их проведению.
Авторы TMMI выделяют два формата оценивания: формальный и неформальный. Провести формальную оценку и официально присвоить компании уровень зрелости могут только аккредитованные специалисты. Неформальную оценку может провести как внешний, так и внутренний эксперт в области тестирования — в этом случае уровень TMMi присваивается неофициально.
TMMi-Framework-Russian-Translation-LeanPubBook — правила проведения оценки для второго уровня на русском языке. Хотя перевод 2011 года можно считать уже неактуальным, материал хорошо помог нам при подготовке.
TMMi-in-the-Agile-world-V1.4 — описание специфических критериев и практик для оценки команд, которые работают по Agile.
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. Начну со сложностей и ошибок.
Первоначальную оценку по TMMi мы проводили по стандартным критериям, неадаптированным к Agile. Сложилось ложное впечатление, что основная часть практик неприменима в рамках нашей компании, но при дальнейшем погружении мы разобрались и исправились
Интересные статьи
Интересные статьи
