Привет, Хабр! Меня зовут Кияшева Екатерина, я занимаюсь качеством. Сегодня хочу поделиться опытом о метриках качества системно. Предложить примеры, провести взаимосвязи: Метрики ⇔ Процессы ⇔ Области управления. Эта статья для руководителей, кто и сам ищет решения, чтобы метрики: 

• не ломали команду,

• не показывали погоду, 

• работали в пользу продукта и бизнеса. 

Ограничения и рекомендации:

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

2. Модель охватывает все стороны управления QA — это большой пласт. Одно предложение в тексте может означать месяц согласований, поэтому подобные изменения внедряют по частям. В статье есть карта «частей» с рекомендациями по сборке собственного роадмапа. Описание — в Навигаторе.

3. Метрики качества раскрывают уютный хаос — это выгодно на дистанции, но неприятно в моменте. Готовность к «рабочим моментам в полях» и культура общей безопасности обязательны для получения честных данных.

4. Я выбрала метрики завершенного цикла (рефлексии): они строятся на основе операционных и служат фундаментом для стратегических. Это позволило рассмотреть QA со всех ракурсов и не закопаться в деталях. Определение типов метрик приведено в разделе «О метриках».

---

Навигатор 

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

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

Для составления персонифицированной карты понадобится 4-5 мини-статей. Логика такая:

1. Выберите первую мини-статью. Вспомните проблему или задачу о метриках, подберите наиболее близкий к ней «разрез» и «уровень», откройте ссылку на их пересечении.

2. Выберите еще три мини-статьи, руководствуясь следующей логикой. Если первая статья:

   1. из разреза «Примеры метрик» — ищите внутри нее ссылки с 👈 ,

   2. из разреза «Область управления» или «Процесс» — рассмотрите строку в матрице целиком — все статьи про процесс и первую метрику из списка.

По задумке, набор должен попасть в любой контекст 🙂

Разрезы:

1. Область управления — зоны воздействия на качество продукта. Полезно к прочтению, если сделали все известное, но качества все равно нет.  

2. Процесс — особенности QA и логика выстраивания работ в процесс. Полезно к прочтению, если собственные метрики вызывают недоверие. 

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

Уровни: 

На 1 уровне,  тестирование рассматривается, как черный ящик — на вход поступают единицы продукта, на выходе они преобразуются в тестовые артефакты. 

• На 2 уровне тестирование декомпозировано на типы активностей, и уже они рассматриваются, как черный ящик. 

О метриках 

Категории метрик:

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

2. Завершенного цикла. Подытоживают веху: в Scrum это релиз, в Kanban — отчетный период, например месяц. Полезны для объективной оценки результатов и рефлексии в пользу улучшений. [Статья про них].

3. Стратегические. Показывают движение к большим целям. Это метрики крупных периодов, касающиеся рентабельности QA и установки KPI.

Про метрики и процессы

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

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

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

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

Здоровый процесс помогает команде:

• Делать с первого раза. Исчезает нужда в бесконечных уточнениях, а мискоммуникация перестает провоцировать переделки.

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

• Прогнозировать объем, качество и сроки. Результат на базе повторяющихся действий предсказуем.

Если процесс отвечает данным требованиям, он уже поддается измерениям и не требует от команды особых усилий ради отчетности. Фраза «нам это нужно делать для метрик» (и больше ни для чего) — серьезный повод насторожиться. Она сигнализирует о том, что действия оторваны от реальности, а в системе зарождается «процессобесие». Любой процесс, придуманный в вакууме ради красивых цифр, идет во вред реальной работе.

Про разработку и чтение метрик

Чтобы метрики работали, я использую несколько проверенных правил — на них построены все примеры в этой статье. О них — по порядку.

Принципы дизайна метрик:

• Проверка «на лету». Относительные показатели обязаны подтверждаться абсолютными в той же таблице. Это позволяет проверять корректность цифр прямо в ходе чтения.

• Логика «слева направо». Метрики, собранные в систему, отражают прогресс. Последовательность показателей должна быть выстроена так, как мозг привык их читать: от частного к общему, нарастающим итогом слева направо.

• Система «противовесов». Одно и то же событие должно прослеживаться в разных метриках: взлет одного показателя должен подтверждаться или уравновешиваться другими данными в системе. Это страховка от ложных выводов.

Принципы работы с метриками:

• Привязка к цели. Метрика — это мера достижения цели, а не цель. Для примера возьмем врачебную практику: если цель пациента — снизить вес, врач будет измерять вес. Но если на фоне лечения у пациента начнет падать пульс и отказывать ноги,  врач не будет доказывать, что с весом все хорошо. Он обновит программу лечения и добавит метрик. Так и в процессах: если метрики перестали отражать реальное положение дел, их нужно пересмотреть. 

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

• Фокус на аномалиях. Точки роста лежат за границами нормы, а не внутри неё. Лечение нужно там, где болит. Чтобы построить программу лечения, врач выясняет характер боли: где, как, как сильно, как часто.

---

Структурная калибровка

QA производит гарантии через тесты. Каждый вид теста отвечает за свой аспект качества. Чтобы выдать гарантию, нужно строго соблюсти технологию и предусловия теста.

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

КОНТЕКСТ

Чтоб представить себе структуру производства, я смотрю на него в разрезах, как на слоеный пирог:

• слой предметной области — функции, фичи, модули;

• слой документации — требования, спецификации, инструкции;

• слой реализации — UI/API/CLI-интерфейсы, схема данных, ядро вычислений;

• архитектурный слой — веб-сервер, сервер приложений, сервер баз данных, middleware;

• инфраструктурный слой — виртуализация, сети, оркестратор, балансировщик, физическое хранилище, мониторинг.

Каждый слой этого «пирога» выделяется по технологиям, инструментам разработки и типам тестирования.

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

В IT «пирог» и «конвейер» — это абстракция, поскольку и то, и это выглядит как одна и та же сущность — тикет в системе задач. Невозможно увидеть глазами поломку сборочной линии, выпуск битых деталей вместо целых. Для QA это фундаментальные риски:

• Гарантийные риски. Порождаются подменами «деталей», пришедших в тестирование. Положим, в плане тестировать фичу, а в тест пришло только UI. Тестировщик может проверить «морду», но поручиться за фичу после этого не может. Проектному офису такая подмена не заметна, но она чревата сюрпризами на бою и поиском виноватых.

• Риски прозрачности. Порождаются запутанностью «конвейеров» в QA. Тестировщик работает с 3 видами задач: про элементы продукта, собственные работы, дефекты. Как их связывать, куда линковать риски и тесты, зависит от управления проектом и ожиданий акторов. Перечисленное бывает не согласовано даже между ними. Из-за этого они будут видеть тестирование по-разному и выдвигать взаимоисключающие требования.

МЕТРИКИ

Представление структуры и поставок по слоям помогает:

• настроить пирамиду тестирования под реальные возможности производства и не обманывать бизнес, а также поддерживать ее актуальной;

• опираться на факты при объяснении проектному офису зависимостей.

ИСТОЧНИК ДАННЫХ

Для разработки метрик этой модели понадобится:

• EPMS — система управления задачами (Task Tracker). Позволяет организовать элементы продукта, работы QA и дефекты в едином пространстве. 

К началу

---

Пирамида тестирования

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

Системное несоответствие объекта тестирования необходимой гарантии оборачивается фикцией или конфликтами. Это признак того, что типы тестирования, скорее всего, учитывают запрос бизнеса о гарантиях, но не учитывают структуру производства. 

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

Виды гарантий утверждаются стратегией через уровни тестирования (слои): слой юнит-тестов, модульных тестов, интеграционных тестов и т. д. Каждый слой проверяет работоспособность на уровне метода, модуля или всего продукта, с технической, конъюнктурной или бизнесовой стороны. Вместе утвержденные слои образуют пирамиду тестирования. 

Сопоставление слоев в пирамиде и в производстве покажет:

• какие виды тестов возможно добавить и что это даст;

• какие виды тестов невозможно выполнить, чем это грозит и чего для этого не хватает. 

К началу

---

Элементы

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

Во всех случаях смена статуса фиксирует передачу ответственности. Это сигнал к началу своей работы или отгрузка результатов коллегам. Системная необходимость работать над задачей в «чужом» статусе, отгружать результат посредством чатов и устно может говорить о проблеме декомпозиции на задачи.

Элемент продукта (единица продукта) 

Задача о продукте фиксирует объект тестирования: задача с требованиями, с фиче-веткой, с билдом или глобальная со всеми артефактами сразу — все это элементы продукта.  

Глобальные задачи обычно очень плохо декомпозируются. С точки зрения реализации их удобнее делить горизонтально — на разработку логики, кэширования, интерфейсов. С точки зрения использования и QA — вертикально: сценарий пользователя А, пользователя В, злоумышленника. Что из этого лучше — тема холиварная: в зависимости от продукта может быть и то, и это. Бывает также, что один сервис продукта разумнее делить горизонтально, а другой — вертикально.  

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

Если разбивка горизонтальная, любые попытки проверить промежуточный результат с точки зрения использования дадут обратный эффект — затрат много, гарантий качества никаких. Здесь эффективней поставлять в разработку тесты, а не тестирование: в виде нотаций для юнит-тестов, автотестов, чтобы девелопер учитывал различные вариации поведения пользователя в ходе разработки. Это выполняется до начала разработки и проводится в рамках всей глобальной задачи. Оно не гарантирует качество использования, но повышает работоспособность продукта by design, ликвидирует затраты на бессмысленные работы QA. Потребность работать в «чужом» статусе отпадает сама собой.

Работа QA

Задача на работы фиксирует информацию об испытании: содержание работ, плановые сроки и трудозатраты. Разбивает крупную разнородную деятельность в пользу продукта на измеримые операции. 

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

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

На практике хорошо работает разбивка по роду деятельности внутри неразрывной сессии с продуктом. Род деятельности — это доступный набор работ, чтобы приблизить продукт к финишу (обе части важны: работы должны быть доступны, они должны быть полезны для общего результата). 

Для примера рассмотрим возможные поставки:

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

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

• Билды — по роду деятельности возможны испытания. Цель в данном случае — вернуть обратную связь о фактическом состоянии продукта. 

Формат и цель задач в подобной разбивке одинаковы для всех однотипных поставок. Сложность и трудоемкость работ зависят от величины и сложности каждой конкретной поставки. 

Дефект 

Задача на дефект — это отчет о браке. Плохая декомпозиция брака на дефекты не подрывает архитектуру QA, но также имеет ряд особенностей: 

• QA являются владельцами дефектов, а создают и работают с ними все. См. раздел «Управление потоком — Процесс — Поток дефектов».

• От того, как описан дефект, зависит, как его поправят и поправят ли вообще. См. Раздел «Управление тестированием — Процесс — Стандарты».

К началу

---

Связи

Структурно задачи в зоне действия QA делятся на: 

• задачи — объекты тестирования;

• задачи — работы;

• задачи — дефекты. 

Они движутся по своим потокам и сливаются в результат. Результат, как правило, рассматривается в контексте, т. е. в связке двух или всех трех потоков. Например, оценка трудозатрат в контексте объекта проверки, оценка забракованности в контексте расположения скоплений в продукте. 

Связывание через линки

Самое предсказуемое решение — связывать задачи на работу с элементами продукта и дефектами: берешь задачу на изменение, к которой уже привязана задача на работы, и линкуешь найденные дефекты к объекту тестирования. Это работает, увы, лишь в одном известном мне процессе — Agile, где: 

• объект тестирования одновременно выступает требованием. Имеет четкие границы реализации, описанные в самой задаче;

• команда локализованная, все в контексте всех фичей;

• релиз небольшой — от двух до четырех недель максимум. 

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

Связывание через атрибуты

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

• настроить поисковые фильтры на задачи своей команды, своего компонента, своего функционального блока — для планирования, для обработки, для контроля;

• уведомить соседнюю роль, группу, команду о готовности своей части. 

Когда мотива нет, помогает автоматизация.

К началу

---

Примеры метрик Organization Dashboard

Ритм производства (Cadence)

# Процесс: Пирамида тестирования👈, Структурная калибровка 👈, Управление потоком 👈.

Ритм производства — это динамика закрытия задач внутри каждого слоя разработки (слоя требований, фронта, бэка, инфры, фичей, бизнес-модулей). Он, как «пульс», задает темп поступления поставок в тестирование.

Поставка — единица ценности, оформленная в задачу («элемент продукта»). Она включает: 

• изменения в коде: ссылка на бранч, билд;

• комментарии: значения параметров, конфиги, контракты. Тесты должны проверять вариации и граничные значения переменных, заданных реализацией;

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

В поставке требований, понятно, кода быть не может, но статус степени готовности — вполне.

Если ритм поставок совпадает с плановым в QA, пирамида тестирования рабочая. Если нет, этот ритм становится отправной точкой для исследования в связке и по отдельности: 

• Ритм в таск-трекере вообще не прощупывается, также его не видно в CVS&CI и документации. В данном случае тестирование, встроенное в производство, будет сжигать бюджеты и не давать эффекта. Оптимально утвердить тестирование 3 уровня независимости, установить четкие входные критерии, предложить консультативную помощь в построении общего роадмапа и процессов.  

• Ритм в таск-трекере отличается от ритмов разработки — по каким-то причинам они не синхронизированы. Оптимально автоматизировать синхронизацию. 

• Ритм в таск-трекере показывает тишину половину релиза, а в конце — резкий взлет до самого последнего дня. Здесь результаты тестирования не будут использованы в полной мере, тесты будут непредсказуемо скипаться и отключаться командой. Тестирование бизнес-логики и функциональной пригодности фичей не сможет выполняться. С большой вероятностью есть критические muda в управлении потоком. Оптимально вводить тестирование на уровне ревью требований и поставки тестов в разработку. Предложить консультативную помощь во внедрении контрактной основы разработки и поиске потерь в производственном процессе.

DEVELOPMENT: Производство.

Контекст. Процесс создания ценности — замер частотности поставок.

Выборка. Фильтр данных по задачам разработки (“элементам продукта”) в составе релиза. Группировка по слою разработки (типу “элемента продукта”).  

Аналитические срезы:

• Element analyze link  срез со стороны “элементов продукта”: какие конкретно задачи на разработку заканчиваются первыми, в каком квартиле закрываются задачи на требования, какие задачи начинают закрываться в 4/4?

Dev Level

Scope count, шт.

1/4 Scope, % (шт.)

2/4  Scope, % (шт.)

3/4 Scope, % (шт.)

4/4 Scope, % (шт.)

Element analyze link

• GQM Scope Count. Цель: фиксация  общего количества элементов в слое. Вопрос: сколько элементов в скоупе релиза подлежало тестированию? Метрика: количество всех элементов в релизе.

• GQM X/4 Scope. Цель: оценка распределения “элементов продукта” в релизе по статусу готовности. Вопрос: какова динамика передачи в тестирование? Метрика: доля Scope Count, завершенных в каждом квартиле. 

К началу

---

Погрешность процесса (Process)

# Процесс: Связи 👈, Метрика:  Здоровье релиза 👈,  Метрика: Здоровье продукта 👈.

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

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

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

ELEMENT & BUG: Мапинг дефектов

Контекст: Процесс тестирования — замер погрешности трассировки фичей и дефектов. 

Выборка: Фильтр данных по дефектам, найденным в релизе + фильтр по задачам в составе релиза, с типом, подлежащим линковке (“элементы продукта”).

Аналитические срезы:

• Element analyze link срез со стороны “элементов продукта”:  к каким именно элементам не привязаны дефекты, они были проверены? Что их объединяет, в чем их особенность?

• Bug analyze link срез со стороны дефектов: какие именно дефекты не связаны с “элементами продукта”, что их объединяет, в чем их особенность?

Scope count, шт.

Unlink Scope, % шт.

Bug Count, шт.

Unlink Bug, % шт.

Element analyze link

Bug analyze link

• GQM Scope Count. Цель: фиксация  общего количества элементов. Вопрос: сколько элементов было разработано? Метрика: количество элементов в релизе.

• GQM Unlink Scope. Цель: оценка доли элементов без связей с дефектами. Вопрос: в какой доле элементов отсутствуют дефекты? Метрика: доля Scope Count без связей с дефектами.

• GQM Bug Count. Цель: фиксация общего количества дефектов. Вопрос: сколько дефектов было найдено в релизе? Метрика: количество дефектов в релизе.

• GQM Unlink Bug. Цель: Цель: оценка доли дефектов без связей с элементами.  Вопрос: какая доля дефектов не привязана к элементам? Метрика: доля Bug Count без связей с элементами. 

К началу

---

Управление потоком

QA — всегда финальное звено в производстве. Даже автотесты, написанные параллельно с кодом, запускаются по готовности разработки, ответственность за них лежит на QA.

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

В этой зоне мы смотрим на дефекты процессов. Они, наравне с продуктовыми, способны приносить миллионные убытки и убивать продукт.

КОНТЕКСТ

Поток в QA сравним с конвейером. Детали (задачи на продукт) едут по лентам с дефектоскопами (задачи на работы QA), которые фиксируют брак (задачи на дефекты). Эффективность потока считается так же, как на заводе:

• объем: что нужно проверить;

• мощность: плановый ритм проверок (шт./время);

• производительность: фактический ритм проверок (шт./время).

МЕТРИКИ

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

ПРОЦЕССЫ

В статье использована методология LEAN. В её основе лежит философия Kaizen — непрерывное улучшение через устранение потерь.

• В 1950-х Э. Деминг доказал важность оценки качества через метрики. Позже его труды легли в основу «японского чуда» на заводах Toyota (книга Out of the Crisis, 1982).

• В 1980-х Д. Вумек изучил успех Toyota и оформил эти принципы в методологию бережливого производства (книга The Machine That Changed the World, 1990).

• В 2000-х Мэри и Том Поппендик адаптировали LEAN для IT, что дало толчок масштабированию Agile (книга Lean Software Development: An Agile Toolkit, 2003).

• В 2010-х Дж. Андерсон добавил к Agile метод Kanban, представив разработку как поток. Он перенес фокус с контроля общих сроков на пропускную способность, а также внедрил в IT статистическое управление процессами по заветам Деминга (книга Kanban: Successful Evolutionary Change for Your Technology Business, 2010).

В LEAN выделяют 3 вида потерь:

• MUDA (потери) — результат деструктивных действий или бездействия.

• MURA (вариабельность) — проявление неуправляемости.

• MURI (напряжение) — очаги перегруза, создающие потери для всей системы.

ИСТОЧНИКИ МЕТРИК

Для расчета метрик понадобятся:

• EPMS — система управления задачами и дефектами (Task Tracker). Хранит данные для анализа потока.

• Система управления ресурсами — данные о доступных человеко-часах (интеграция с EPMS).

• RMS, CI/CD, TMS, IMS — системы требований, сборок, тестов и инцидентов. Нужны для уточнения причин потерь.

К началу

---

Характеристики потока

Дизайн потоков начинается с установки «правил игры». Это происходит за пределами системы задач и означает: 

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

• унификацию трактовки результатов.  

Владельцы очередей

Процессы в потоке организует тот, кто им управляет. В небольших проектах это руководитель продукта или проекта. На больших масштабах происходит разделение на тех, кто управляет продуктом, и тех, кто управляет работами. Глобально в IT есть три методологии-ориентира. Они задают вектор разделения (по функциональному колодцу, бизнес-модулям, архитектурным блокам), тем самым декларируя владельцев продукта и работ. 
 

Единицы измерения работ

Задачи в потоке измеряются в трудозатратах (Effort) и продолжительности (Duration). 

• Effort — количество часов активной работы. Используется при планировании бюджетов проекта. Контроль — на уровне таймшитов. 

• Duration — календарный срок выполнения. Используется при планировании дедлайнов проекта. Контроль — на уровне сроков до закрытия задач. 

Управление работами базируется на одном из 2 обязательств:  

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

2. Нормативы ритма — за сколько часов выполняется каждая задача. Владелец очереди организовывает работу так, чтобы каждая задача проходила в срок, установленный стандартом. Он ранжирует задачи по весу (S, M, L) или приоритету (Critical, Normal, Low) и устанавливает каждому рангу типовой срок выполнения.

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

Классификация затрат

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

• LT (Lead Time) — время жизни задачи со дня, когда ее решили сделать, до дня сдачи конечного результата. 

• CT (Cycle Time) — время жизни задачи в рабочем цикле. Со дня, когда ее взяли в рабочий план, до дня ее решения. 

• PT (Process Time) — время активной работы, когда задача находилась в рабочих статусах.

• WT (Wait Time) — время простоя, когда задача висела в очередях или в заблокированном статусе. 

Иногда выделяется время непосредственной работы — Touch Time. Это часы активной деятельности человека в период Process Time. К примеру, ожидание сборки или прогона автотестов относится к Process Time, но не относится к Touch Time. Профили затрат вычисляются автоматически, опираясь на статусы задач. 

Process Time может служить заменой ручному логированию таймшитов, но при соблюдении жестких условий: 

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

2. Более одной задачи в работе иметь невозможно. Чтобы взять дополнительную задачу, нужно официально отложить первую.

К началу

---

Поток изделий и работ

Дизайн потока изделий и работ — это визуализация составного конвейера в едином пространстве. Он поддерживает общий контекст, чтобы каждый член команды понимал, чего ожидать в ближайшее время и что значит «готово» конкретно для него и всей команды. Это освобождает от рутинных коммуникаций («уже готово?», «где взять?», «что сделать?») в пользу контекстных («как сделать?», «какое решение лучше?», «почему так?»). 

Структура потока

Для оцифровки потоков широко используются 2 концепта: Scrum и Kanban.

• Scrum. Очередь элементов продукта и очередь QA-работ раздельные. Продукту отдаются особые типы задач — Epic, Story. Они, как прообраз деталей на конвейере, движутся по собственному флоу и по мере движения накапливают ценность в виде артефактов от всех участников команды. Задачи на работы создаются на этапе оценки фичей: команда оценивает фичу, нарезает в нее задачи на работы и линкует их к «детали». Идея концепта — «подружить» разные роли. Чтобы фича перешла на следующую стадию, требуется участие более одной роли. У QA в данном случае есть своя собственная задача.

• Kanban. Очередь элементов продукта и очередь работ объединены. Каждая карточка на доске — это одновременно и единица ценности, и единица работы. Флоу подразумевает передачу задачи «из рук в руки» по этапам. Продукт движется по конвейеру статусов и обогащается ценностью на каждом шаге. У QA в данном случае нет отдельных задач, но есть выделенные этапы (колонки) в общем флоу каждой задачи.

В зависимости от типа тестирования элементом продукта может выступать как задача на продукт, так и задача на разработку продукта (т. е. задача девелопера). Например, в функциональное тестирование идут задачи на продукт по Scrum, а на автоматизацию — задачи девелоперов по Kanban. При выборе концепта важно помнить про особенности каждого:

1. QA-работа в виде задачи не тормозит релиз. Процесс позволяет продолжать работу над продуктом, пока задача ждет своей очереди или если она затянулась. 

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

Таким образом, Kanban закладывает Quality Gate на уровне процесса, но несет риск узких горлышек. Scrum предельно гибкий, так что Quality Gate лучше закладывать на другом уровне. 

Статусная модель

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

• Элементы продукта движутся по стадиям степени готовности. Например: «в плане», «утвержден», «в разработке», «на демо», «в прод». В Waterfall стадии могут именоваться по ролям в команде, отражая фактический процесс совместной работы. Контрольный вопрос для добавления стадий: есть ли там специфический риск? 

• QA-работы движутся по стадиям (профилям затрат). Например: «в плане», «в работе», «отложено», «готово». Контрольный вопрос для добавления стадий: есть ли там очередь? 

• QA-работы, «вшитые» в элементы продукта, должны четко показывать смену роли.  

Каждый статус наполнен смыслом:

• Содержание. Что должно быть сделано в рамках стадии: разработано, согласовано, проверено. Это ориентир для команды на человеческом языке. 

• Критерии окончания работ (Exit Criteria). По каким формальным признакам понятно, что содержание сделано: прилинкованы артефакты, закрыты связанные задачи, заполнены атрибуты. Это входная информация для участников процесса, чтобы не засорять эфир типовыми вопросами. Критерии достаточно формализованы, если их можно заскриптовать и автоматизировать их проверку. 

Невыполнение Exit Criteria в реальном производстве — обычное дело, поэтому важно разделить, какие из них просто удлиняют коммуникации, а какие блокируют работы. 

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

• В тест пришло API без фронта (или другая неполная комплектация) — функциональное тестирование заблокировано. Возможно модульное, интеграционное, но функциональное — нет. Старт одного тестирования под видом другого создает неоправданные ожидания.

• В тест пришел модуль без версии — тестирование заблокировано. В обратном случае QA будет гарантировать работу «коня в вакууме». Тесты и баги отражают состояние билда на момент его проверки. На все, что будет сделано с модулем после тестирования, гарантии не распространяются. 

• В тест пришел бранч, не соответствующий этапу тестирования, — тестирование заблокировано. К примеру, провести регресс только до большого мержа — все равно что не проводить его вовсе.

Отсутствие требований, нерабочие билды, критические сбои систем на входе, рассогласованность подсистем между собой и с требованиями, не готовые стенды — всё это НЕ блокирует работу QA как таковую, но блокирует тестирование. То есть вместо тестирования инженер будет заниматься наполнением контекста и согласованием рассогласованного. Эту работу оптимально проводить на более ранних этапах и по возможности автоматизировать.

Регуляторы

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

• WIP-limit — максимальное количество задач, которое может находиться в рабочих статусах у одного человека.

• Utilization — % рабочего времени, заложенного на активную работу по задачам.

• Classes of Service — лимит на переключения. По умолчанию переключения запрещены: новая задача не может быть взята до тех пор, пока не завершится предыдущая. Исключением являются задачи Expedit (ускоренные) — лимит ограничивает количество таких задач в работе.

К началу

---

Поток дефектов

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

Особенности потока: 

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

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

• Дефекты привязаны к сборке. В 9 из 10 случаев, когда у QA дефект воспроизводится, а у девелопера нет, причина кроется в разных версиях билда. 

• Дефект, описанный тестировщиком, может быть не понят и отменен. Чтобы не путаться, какие из багов отменены окончательно, а какие по ошибке, полезно предусмотреть шаг возврата в QA и учитывать его в затратах на дефект. 

• Дефект, исправленный разработчиком, не обязательно исправлен по факту. Каждый возврат дефекта в DEV должен быть учтен в затратах на дефект. 

• Дефект, заведенный QA, может быть отменен по различным причинам. Причина отмены должна фиксироваться в момент отмены.

• Дефект — это источник рефлексии для последующих улучшений. RCA дефекта выполняется по причине возникновения и причине пропуска (отличная статья на тему RCA, встроенного в процесс, от SM Lab: Работа над ошибками: как мы анализируем дефекты).

• Скопления дефектов говорят о хрупкости компонента. Отметка в дефекте места его расположения (компонента, функционального блока) дает информацию для выводов о хрупкости продукта.

К началу

---

Примеры метрик Effort Dashboard: 

Обязательства (Commitments)

# Управление потоком 👈, Процесс: Характеристики потока 👈, Процесс: Поток изделий и работ 👈.

Ключевые обязательства операционного менеджмента связаны с объемами и сроками. В рамках релиза — это степень соответствия плана факту, в рамках производства — Time To Market.  

В соответствии с идеями LEAN основной причиной отклонений является триада 3M — muda, mura, muri. Это «тормоза» в потоке работ, накопленные в ходе масштабирования продукта или просто с течением жизни. Систематические простои, реворки, неэффективные коммуникации никогда не включаются в оценки, но съедают время. 

Рассматривая эти метрики, я предполагаю, что структурная калибровка проведена, пирамида тестирования синхронизирована с ритмом разработки, а гарантии QA исполнимы.

SCOPE: Область тестирования

Контекст. Процесс тестирования — замер границ.

Выборка: Фильтр данных по задачам в составе релиза (“элементы продукта”). Группировка по слою тестирования. 

Аналитические срезы:

• Element analyze link срез со стороны “элементов продукта”: приняты ли риски за элементы, которые не попали в тест-план? какие именно элементы из плана не были проверены, как именно митигировали риски в связи с недопроверкой?

Test Level

Fact Scope Count, шт.

Test Plan Scope Count, % (шт.)

Tested Scope Count, % (шт.)

Element analyze link

• GQM Fact Scope Count: Цель: Фиксация общего количества элементов. Вопрос: Сколько элементов разработала команда? Метрика: Количество задач, определенных как «элемент» продукта.

• GQM Test Plan Scope Count: Цель: Оценка границ тестирования. Вопрос: Сколько элементов стояло в плане на тестирование? Метрика: Доля Fact Scope, запланированных в тест. 

• GQM Tested Scope Count: Цель: Оценка фактической области тестирования. Вопрос: Сколько элементов было протестировано? Метрика: Доля Fact Scope, прошедших тестирование.

WORK: Сроки работ

Контекст. Процесс тестирования — замер временных рамок.

Выборка: Фильтр данных по задачам на QA работы в составе релиза. Группировка по слою тестирования.

Аналитические срезы:

• QA Work analyze link срез со стороны задач на тестирование: какие QA работы создали наибольшее расхождение плана с фактом, что именно в них было? 

Test Level

QA Work Count, шт.

Time Spent, ч.

Team Estimate, % (ч.)

Lead Estimate, % (ч.)

QA Work analyze link

• GQM QA Work Count: Цель: Фиксация общего количества QA работ. Вопрос: Сколько всего работ было проведено? Метрика: Количество QA работ в релизе.

• GQM Time Spent: Цель: Фиксация общего количества трудозатрат QA. Вопрос: Сколько времени заняли все работы QA? Метрика: Сумма списанных часов (Worklogs).

• GQM Team Estimate: Цель: Оценка погрешности планов команды. Вопрос: За сколько времени QA команда планировала выполнить работы? Метрика: Отношение командных оценок к Time Spent.

• GQM Lead Estimate: Цель: Оценка погрешности планов лида. Вопрос: Сколько времени закладывал лид на все работы? Метрика: Отношение экспертных оценок к Time Spent.

К началу

---

Потери (MUDA)

# Управление потоком 👈, Процесс: Характеристики потока 👈, Метрика: Первоисточники 👈.

MUDA — это потери в процессе. Ее присутствие в производстве со стороны выглядит как ситуация: «каждый в команде молодец, но результат неудачный».

LEAN выделяет 8 видов потерь, которые возникают на стыках работ и замедляют производство вне зависимости от стараний отдельных сотрудников:

• Partially Done Work (Частично сделанная работа). Аналог «Запасов»: код, который написан, но не задеплоен; ТЗ, которое готово, но не пошло в разработку; работа сделана, но ценности пользователю еще не несет.

• Extra Features (Лишний функционал). Аналог «Перепроизводства»: разработка фич, которые «возможно пригодятся» или которые никто не просил (gold plating). 

• Extra Processing (Лишние этапы). Аналог «Избыточной обработки»: лишние бюрократические согласования, ручные отчеты, двойной ввод данных, совещания без четкой повестки и результата.

• Relearning (Повторное обучение). Аналог «Потери знаний»: затраты времени на погружение в контекст из-за отсутствия документации, плохой структуры кода или большой давности задачи.

• Handoffs (Передачи ответственности). Аналог «Транспортировки»: передача задач между отделами. При каждой передаче (через документы или чаты) теряется часть контекста, требуя времени на его восстановление принимающей стороной.

• Task Switching (Переключение контекста). Аналог «Лишних движений»: одновременная работа над несколькими задачами. Блокирует состояние потока и увеличивает срок сдачи каждой задачи из-за времени на «перезагрузку» мозга.

• Delays (Ожидание). Аналог «Простоев»: ожидание ответа заказчика, завершения сборки, доступности тестового стенда или аппрува от смежной команды.

• Defects (Дефекты). Аналог «Брака»: время и ресурсы, затраченные на поиск, документирование и исправление ошибок, а также на повторное тестирование.

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

MUDA в запущенном виде подтверждается MURA и MURI.

SCOPEFLOW: Продуктовый поток

Контекст. Процесс создания ценности — замер завершенности поставок.

Выборка: Фильтр данных по задачам на разработку в составе релиза, проходящим через тестирование (“элементы продукта”) + фильтр по входным критериям завершенности + фильтр по выходным критериям завершенности задачи. Группировка по слою тестирования. 

Аналитические срезы:

• Element analyze link срез со стороны “элементов продукта”: какие единицы самые «загрязненные» на входе и выходе из QA, в них есть что-то общее?

• DOR analyze link срез со стороны входных критериев завершенности: какие из критериев DoR чаще всего нарушаются, в чем причина, как именно QA это преодолевает ?

• DOD analyze link срез со стороны выходных критериев завершенности: какие из критериев DoD чаще всего нарушаются, где причина — в процессе или содержании работ?

Test Level

Test Scope Count, шт.

∑ DOR Count, шт.

Failed DOR Count, % (шт.)

∑ DOD Count, шт.

Failed DOD Count, % (шт.)

Element analyze link

DOR analyze link

DOD analyze link

• GQM Test Scope Count: Цель: Фиксация состава элементов, прошедших тестирование. Вопрос: Сколько элементов было проверено в релизе? Метрика: Количество элементов в релизе. 

• GQM DOR Count: Цель: Фиксация суммы входных критериев в задачах релиза. Вопрос: Сколько всего критериев должно быть выполнено, чтобы считать все задачи законченными? Метрика: Количество всех входных критериев для задач, пришедших в тестирование. 

• GQM Failed DOR Count: Цель: Оценка доли не выполненных входных критериев. Вопрос: Насколько незаконченным приходил продукт в QA? Метрика: Доля невыполненных DOR Count.

• GQM DOD Count: Цель: Фиксация суммы выходных критериев в задачах релиза. Вопрос: Сколько всего критериев должно быть выполнено, чтобы считать все задачи готовыми к сборке (следующему этапу)? Метрика: Количество всех выходных критериев для задач, проверенных QA. 

• GQM Failed DOD Count: Цель: Оценка доли не выполненных выходных критериев. Вопрос: Насколько незаконченными были гарантии, произведенные QA? Метрика: Доля невыполненных DOD Count.

WORKFLOW: Поток работ

Контекст. Процесс тестирования — замер профилей затрат.

Выборка. Фильтр данных по задачам на QA работы в составе релиза. Группировка по слою тестирования. 

Аналитические срезы: 

• QA Work analyze link срез со стороны “QA работ”: какие задачи на холде и почему? у каких задач Lead Time, Cycle Time, Process Time выше 85 перцентиля, почему зависли?

Test Level

QA Work Count, шт.

P85 Lead Time, ч.

P85 Cycle Time, ч.

P85 Process Time, ч.

∑ Cycle Time, ч.

Wait Time, % (ч.)

Hold Time, % (ч.)

QA Work  analyze link

• GQM QA Work Count: Цель: Фиксация количества QA работ. Вопрос: Сколько задач выполнено QA командой? Метрика: Количество задач на работы QA, привязанные к релизу.

• GQM P85 Lead Time: Цель: Фиксация времени жизни одной задачи от ее создания до закрытия. Вопрос: Сколько времени проходит от идеи до реализации? Метрика:  85 перцентиль срока Lead Time. 

• GQM P85 Cycle Time: Цель: Фиксация времени фокуса на задаче.  Вопрос: Сколько времени проходит от включения задачи в план до ее закрытия? Метрика:  85 перцентиль срока Cycle Time. 

• GQM P85 Process Time: Цель: Фиксация времени выполнения задачи.  Вопрос: Сколько времени проходит от начала работы над задачей до ее закрытия? Метрика:  85 перцентиль срока Process Time. 

• GQM ∑Cycle Time: Цель: Фиксация суммы всех периодов, когда задачи находились в фокусе. Вопрос: Каково абсолютное значение времени фокуса на задачах? Метрика: Сумма всех периодов Cycle Time.

• GQM Wait Time: Цель: Оценка времени ожидания задачи в очереди. Вопрос: Сколько времени задачи ждали взятия в работу? Метрика: Доля от ∑Cycle Time.

• GQM Hold Time: Цель: Оценка времени простоев. Вопрос: Сколько времени задачи должны были обрабатываться, но не могли из-за стопперов? Метрика: Доля от ∑Cycle Time

BUGFLOW: Поток дефектов

Контекст. Процесс отбраковки — замер профилей затрат.

Выборка: Фильтр данных по дефектам, закрытым в релизе. Группировка по компоненту, к которому относится дефект. 

Аналитические срезы:

• Bug analyze link срез со стороны дефектов: какие дефекты решены быстрее обычного, как это получилось? Какие дефекты зависали, почему? Какие дефекты попадали в повторную обработку DEV и QA, их что-то объединяет? Что можно сделать, чтобы уменьшить очереди ожиданий, какая дистанция между сборками, где дефект найден и где исправлен?  

Component

Bug Count, шт.

P15 Lead Time, ч

P85 Lead Time, ч

∑ Lead Time, ч.

DEV Process Time, % (ч.)

QA Process time, % (ч.)

Wait Dev, % (ч.)

Wait QA, % (ч.)

Bug analyze link

• GQM Bug Count: Цель: Фиксация количества дефектов, закрытых в релизе. Вопрос: Сколько дефектов было закрыто в релизе? Метрика: Количество всех исправленных дефектов за релиз.

• GQM P15 Lead Time: Цель: Фиксация минимального срока решения дефекта. Вопрос: Не быстрее какого срока обычно решаются дефекты? Метрика: 15 перцентиль срока Lead Time.

• GQM P85 Lead Time: Цель: Фиксация максимального срока решения дефекта. Вопрос: Не дольше какого срока обычно решаются дефекты? Метрика: 85 перцентиль срока Lead Time.

• GQM ∑Lead Time: Цель: Цель: Фиксация суммы всех периодов, когда дефекты были в открытом статусе. Вопрос: Каково абсолютное значение времени жизни  дефектов, решенных в релизе? Метрика: Сумма всех периодов Lead Time.

• GQM DEV Process Time: Цель: Оценка времени исправления дефекта. Вопрос: Сколько времени баг находился в разработке? Метрика: Доля ∑Lead Time.

• GQM QA Process Time: Цель: Оценка времени ретеста дефекта. Вопрос: Сколько времени баг находился в тестировании? Метрика: Доля ∑Lead Time.

• GQM Wait Dev: Цель: Оценка времени ожидания разработчика. Вопрос: Сколько времени баг ожидал в очереди на исправление? Метрика: Доля ∑Lead Time.

• GQM Wait QA: Цель: Оценка времени ожидания тестировщика. Вопрос: Сколько времени баг ожидал в очереди на ретест? Метрика: Доля ∑Lead Time.

К началу

---

Вариабельность (MURA)

# Управление потоком 👈, Процесс: Поток изделий и работ 👈, Метрика: Здоровье релиза 👈.

MURA — это вариабельность: волнообразная нагрузка, динамические сроки, сменяющиеся исполнители — всё это влияет на конечный результат и сигнализирует о потере управляемости. Дж. Андерсон исследовал вариабельность Lead Time и Cycle Time по мотивам карт Шухарта из трудов Деминга. С помощью гистограмм распределения времени выполнения он выяснил, что самые дорогостоящие проблемы находятся в «хвосте». Далее Андерсон формализовал, как отличить нормальную вариабельность времени от ненормальной и о чем могут говорить различные отклонения от нормы.

Thin-Tailed (Акулий плавник) — здоровый процесс. Много коротких задач и медленный переход в длинные: увеличение срока задачи и уменьшение количества таких задач соразмерно. Процесс управляемый. Если пообещали сделать задачу за 8 дней, наверняка так и будет. Исключения редкие и не катастрофические.

PREDICTABILITY: Контрольные пределы

Контекст. Процесс тестирования — нормирование сроков.

Выборка. Фильтр данных по задачам на работы QA в составе релиза. Группировка по типу работы. 

Аналитические срезы:

• QA Work analyze link срез со стороны QA работ: являются ли задачи в заданном слое однородными, уместна ли их группировка? 

Work type

QA Work Count

P20 Cycle Time (LCL), ч

P50 Cycle Time (CL), ч.

P85 Cycle Time (UCL), ч.

QA Work analyze link

• GQM LCL Cycle Time (P20): Цель: Фиксация нижнего предела Lower Control Limit (LCL). Вопрос: Какое время выполнения является пограничным для 20% самых быстрых задач?. Метрика: 20 перцентиль Cycle Time.

• GQM CL Cycle Time (P50): Цель: Цель: Фиксация центральной линии Control Limit (CL). Вопрос: Каков медианный срок выполнения задач?. Метрика: 50 перцентиль Cycle Time.

• GQM UCL Cycle Time (P85): Цель: Фиксация верхнего предела Upper Control Limit (UCL). Вопрос: Где проходит граница «стандартного шума» процесса, выше которой начинаются аномальные задержки (хвост)? 85 перцентиль Cycle Time.

DISTRIBUTION: Распределение времени

Контекст. Процесс тестирования — замер отклонений от сроков.

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

• LCL — нижняя граница, быстрые задачи,

• CL — центральная линия, средний срок,

• UCL — верхняя граница, медленные задачи,

• MP — медиана между границами

Выборка. Фильтр данных по задачам на работы QA в составе релиза. Группировка по типу работы. 

Аналитические срезы:

• QA Work analyze link срез со стороны задач на QA работы: какие задачи выполнены быстрее нижней границы, сделаны ли они качественно? Какие задачи выполнялись дольше предельного срока, что им мешало? 

Work Type

QA Work Count

< LCL,   % (шт.)

LCL —  MP CL, % (шт.)

MP CL — CL, % (шт.)

CL- PM UCL, % (шт.)

MP UCL —  UCL, % (шт.)

> UCL, % (шт.)

QA Work Analyze link

• GQM < LCL: Цель: Обнаружение «подозрительно быстрых» задач. Вопрос: Какая доля задач выполнена быстрее нижней контрольной границы ? Метрика: Доля задач со сроком ниже LCL.

• GQM LCL-MP CL: Цель: Оценка плотности в зоне «нижнего стандарта». Вопрос: Насколько плотно заполнен интервал между LCL и серединой MP CL? Метрика: Доля задач в интервале LCL — MP CL.

• GQM MP CL-CL: Цель: Оценка плотности перед медианой. Вопрос: Какая концентрация задач приходится на зону непосредственно перед центральной линией  CL? Метрика: Доля задач в интервале MP CL — CL.

• GQM CL-MP UCL: Цель: Оценка плотности после медианы. Вопрос: какая концентрация задач приходится на зону сразу после центральной линии  CL? Метрика: Доля задач в интервале CL -MP UCL.

• GQM MP UCL-UCL: Цель: Оценка плотности в зоне «верхнего риска». Вопрос: Какая часть задач попадает в диапазон между серединой и верхней контрольной границей UCL? Метрика: Доля задач в интервале MP UCL — UCL.

• GQM > UCL: Цель: Оценка объема «тяжелого хвоста» . Вопрос: Какая доля задач выбилась за верхнюю границу предсказуемости? Это зона особых причин вариации (блокировки, инциденты), требующая разбора каждого случая. Метрика: Процент и количество задач со сроком выше UCL.

Каково распределение времени в целом, говорит ли оно о здоровом управляемом процессе? 

К началу

---

Напряжение (MURI)

# Управление потоком 👈, Процесс: Поток изделий и работ 👈, Метрика: Здоровье релиза 👈.

MURI — это перегруз: персонала, оборудования или системы в целом, превышение их естественных пределов. Выделяют два вида перегруза:

• внешний — скопление очередей задач на входе, когда задач приходит больше, чем обрабатывается;

• внутренний — переключения между задачами и оверворки. 

Не все потери являются следствием напряжения, но вследствие напряжения потери бывают всегда: 

• увеличивается вариабельность сроков, и тем самым снижается предсказуемость (MURA);

• растут простои других участников процесса в ожидании ответов от команды под напряжением (MUDA); 

• растет количество брака (MUDA). 

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

LOAD: Загрузка

Контекст. Процесс тестирования — замер загрузки команды.

Выборка: Фильтр данных по задачам на работы QA, попавшие в рабочий статус или закрытые за период. Группировка по недельным периодам. 

№ weekly period

Fact Scope, шт.

Estimated Scope, % (шт.)

Completed Scope, % (шт.).

Resolution Resolved, % (шт.)

Estimates Volume, ч.

Hours Available, ч.

Hours Estimated, % (ч.)

Lead Performer

• GQM Fact Scope: Цель: Фиксация всех задач, побывавших в работе за неделю. Вопрос: Сколько задач было взято в активную работу? Метрика: Количество уникальных задач в рабочем статусе.

• GQM Estimated Scope: Цель: Оценка предсказуемости работ. Вопрос: Какая доля задач имеет оценку? Метрика: Доля Fact Scope с непустой оценкой. 

• GQM Completed Scope: Цель: Оценка пропускной способности. Вопрос: Сколько задач было завершено? Метрика: Доля Fact Scope получивших статус закрытия задачи. 

• GQM Resolution Resolved: Цель: Оценка “чистой” пропускной способности. Вопрос: Сколько задач было завершено решением задачи? Метрика: Доля Fact Scope, закрытых с резолюцией Resolved. 

• GQM Estimates Volume: Цель: Фиксация суммы оценок в задачах, попавших в работу. Вопрос: Сколько ч/ч было запланировано в работу? Метрика: Сумма оценок в задачах периода. 

• GQM Hours Available: Цель: Фиксация доступного времени ч/ч из системы управления ресурсами. Вопрос: Сколько чистого времени с учетом отпусков, отгулов и больничных доступно команде? Метрика: Сумма доступных ч/часов * коэффициент рабочего времени, заложенное на активную работу (Utilization).

• GQM Hours Estimated: Цель: Оценка реалистичности планов. Вопрос: Какое количество времени из доступного было запланировано? Метрика: отношение Estimates Volume к Hours Available.

• GQM Lead Performer: Цель: Фиксация кандидата на выгорание или бутылочного горлышка. Вопрос: Кто закрыл больше всего задач? Метрика: Фамилия сотрудника с максимальным показателем Completed Scope, если на неделе один лидер. (является маркером, когда лидер повторяется на протяжении длинного периода) 

FOCUS: Концентрация

Контекст. Процесс тестирования — замер концентрации команды. 

Выборка: Фильтр данных по задачам на работы QA, попавшие в рабочий статус. Группировка по недельным периодам. 

№ weekly period

Days Available, д.

Respected WIP, % (д.)

Fact Scope, шт.

Assignment Events, шт.

Context Switches Index

• GQM Days Available: Цель: Фиксация доступного количества рабочих дней за период. Вопрос: Сколько рабочих дней было в периоде? Метрика: Рабочие дни в соответствии с производственным календарем.

• GQM Respected WIP: Цель: Оценка концентрации внимания. Вопрос: Сколько дней из доступных соблюдался лимит незавершенной работы? Метрика: Доля дней, когда количество активных задач на начало дня <= WIP Limit * количество человек в команде.

• GQM Fact Scope: Цель: Фиксация всех задач, побывавших в работе за неделю. Вопрос: Сколько задач было взято в активную работу? Метрика: Количество уникальных задач в рабочем статусе.

• GQM Assignment Events: Цель: Фиксация количества переключений.  Вопрос: Сколько раз задачи меняли исполнителя? Метрика: Сумма транзакций смены поля Assignee с назначенного исполнителя.

• GQM Context Switches Index: Цель: Оценка смены фокуса. Вопрос: сколько задач меняли исполнителя, будучи в рабочем статусе? Отношение Assignment Events к Fact Scope.

К началу

---

Первоисточники (Fact-Checking)

# Управление потоком 👈, Процесс: Характеристики потока 👈, Процесс: Элементы 👈.

Данные из первоисточников — это показатели из исходных систем управления связанных процессов. Приходится учитывать, что система управления задачами (таск-трекер) будет скруглять углы, поскольку является лишь агрегатором всех процессов. 

Подобное явление оправдано: выполнение процесса не должно превращаться в отдельную работу, чтобы не стать еще одной MUDA.

Для QA мастер-данные могут объяснять растянутый Process Time: когда задача готова по формальным признакам, но в ходе работы создает массу реворка — неполные требования, многократные деплои, тормоза на тестовых стендах, критическая масса дефектов. Эти проблемы не блокируют работу полностью и поэтому часто незаметны на уровне управления проектом.

REQUIREMENTS: Требования

Контекст. Процесс разработки требований — замер забракованности.

Выборка. Фильтр данных по единицам требований из RMS-системы, привязанных к релизным задачам. Группировка: по типу требований.

Аналитические срезы:

• Requirement analyze link срез со стороны требований: за счет чего можно сократить время ревью? Какие требования обрабатывались аномально долго? 

Requirement Type

Req. Count, шт.

Issue Count, шт.

P85 Req Review Time, ч

P85 Issue Wait Time, ч.

P85 Issue, шт.

Requirement analyze link

• GQM Req. Count: Цель: Фиксация количества требований. Вопрос: Сколько единиц требований поступило в работу в этом релизе? Метрика: Количество единиц требований.

• GQM Issue Count: Цель: Фиксация количества замечаний. Вопрос: Сколько всего уникальных новых вопросов сгенерировали QA к требованиям? Метрика: Суммарное количество комментариев ко всем требованиям выборки.

• GQM P85 Req. Review Time: Цель: Оценка срока обработки одного требования. Вопрос: В рамках какого срока выполняется ревью одного требования? Метрика: 85 перцентиль продолжительности ревью требования.

• GQM P85 Issue Wait Time. Цель: Оценка скорости решения вопросов. Вопрос: В рамках какого срока решаются замечания с ревью? Метрика: 85 перцентиль срока жизни замечания. 

• GQM P85 Issue: Цель: Оценка среднего количества замечаний на одно требование. Вопрос: Какое количество замечаний генерирует одно требование? Метрика: 85 перцентиль количества замечаний на одно требование.

BUILD: Сборочная линия

Контекст. Процесс поставки изменений — замер забракованности.

Выборка: Фильтр данных по джобам (jobs) из CI-системы, выполненным за релизный период внутри пайплайнов (pipeline) деплоя на тестовые стенды. Группировка по репозиторию.  

Аналитические срезы:

• Job analyze link срез со стороны джоб: какие джобы чаще всего падали, какими были основные причины сбоев, что являлось источником сбоя (pipeline или продукт)? какие обработчики и пречеки в пайплане могли бы ускорить обратную связь о статусе деплоя? 

Repository

Pipeline Count, шт.

Failed Pipeline, % (шт.)

Runtime Pipeline, мин.

Runtime  Failed Pipeline, % (мин.)

Job analyze link

• GQM Pipeline Count. Цель: Фиксация количества деплоев. Вопрос: Сколько сборок (Pipelines) было запущено в ходе тестирования? Метрика: Общее количество запусков Pipelines за период.

• GQM Failed Pipeline. Цель: Оценка стабильности поставок. Вопрос: Какая доля сборок завершилась неудачей? Метрика: Доля Pipeline Count со статусом Failed.

• GQM Runtime Pipeline. Цель: Фиксация времени деплоя. Вопрос: Сколько суммарно времени занял деплой промежуточных версий? Метрика: Сумма длительностей выполнения всех Pipelines (успешных и неуспешных).

• GQM Runtime Failed Pipeline. Цель: Оценка потерь сборочной линии. Вопрос: Сколько времени заняли падучие сборки? Метрика: Доля Runtime Pipeline завершившихся ошибкой. 

ENVIRONMENT: Стенды

Контекст. Процесс поддержки окружения — замер забракованности.

Выборка. Фильтр данных по маркерам доступности (Health Check) стенда в рабочие часы за релизный период. Группировка по хостам. 

Аналитические срезы:

• Testbed analyze link срез со стороны хостов: какие именно хосты были недоступны, какова длительность и частота инцидентов, на что это повлияло в QA, с чем была связана конкретная недоступность стендов? Что будет улучшено и в какие сроки? 

Test Level

Support Time, ч.

Downtime, % (ч.)

Testbed analyze link

• GQM Support Time: Цель: Фиксация окна обслуживания. Вопрос: Сколько рабочих часов QA должны были иметь доступ к стенду? Метрика: Количество рабочих часов в периоде.

• GQM Downtime: Цель: Оценка доступности инфраструктуры. Вопрос: Какую долю рабочего времени стенд был недоступен? Метрика: Доля Support Time времени простоя.

К началу

---

Управление качеством

Управление качеством — глубокая инженерная дисциплина, возникшая из промышленности (СМК, стандарты, тотальный контроль).

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

В этой зоне рассмотрим основу управления качеством — нормирование качественных характеристик.

КОНТЕКСТ

Самые достоверные и объемные показатели о фактическом качестве даёт сам продукт, а также успех и цена выполнения пре- и постпродакшн-этапов (внедрение, приёмка, UAT и др.). Дополняет и уточняет эту картину бэклог с багами — при условии, что он актуальный, а ответственность за его распухание несёт вся команда наравне с релизом. Информация о:

• качестве продукта поставляется мониторингом продукта. Это отслеживание различных показателей его жизнедеятельности, сохранение истории отклонений и пиков, оценка истории;

• качестве производства поставляется мониторингом дефектов, привязанным к аспектам производства. Это отслеживание динамики появления дефектов, динамики устранения, скопления дефектов. Сверка профиля выпущенных дефектов с мониторингом продукта;

• качестве релиза поставляется мониторингом околопродакшн-этапов. Это отслеживание производных артефактов с боевых этапов, их подтверждение показателями мониторинга и производства;

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

Я знаю, что операционная метрика Defect Rate Escape часто используется в роли SLA. Она показывает отношение дефектов, найденных в тесте, к дефектам в продуктивной среде. Подчеркну отдельно, к чему приводит оценка качества продукта и QA с помощью этой метрики:

1. Снижение уровня сервиса. Метрика формирует ложную иерархию: баги от пользователей якобы важнее дефектов, найденных внутри. Отношение к их исправлению соответствует иерархии. Это создаёт опасную ловушку. Если внутренний дефект попадает в прод, он фактически становится «боевым». Когда его же находит пользователь, команда, стремясь снизить процент пропусков, отказывается переквалифицировать его из внутреннего во внешний. Результат — формальное благополучие в отчетах при реальном оттоке пользователей, страдающих от нерешенных проблем.

2. Лечение переломов подорожником. Пользователи не владеют теорией тестирования — их жалобы хаотичны. Пока фидбек проходит через фильтры IT и попадает в QA, картина произошедшего на бою может полностью исказиться. В итоге десяток формально «приоритетных» багов в системе могут оказаться шумом, а критические системные сбои в виде хотфиксов вообще не попадут в отчёты из-за аврала. Последующий RCA по такой неполной выборке лишь имитирует работу, оставляя системные риски за бортом.

3. Сокрытие проблемных зон (слепые пятна). KPI на основе боевых дефектов деструктивен, так как тестировщик не контролирует чистоту входящего потока и процессы после релиза. На практике до половины внешних багов — следствие кривых процессов. Такой KPI заставляет QA не анализировать проблемы, а «отфутболивать» их ради сохранения премий. Это создает слепое пятно в управлении: реальные причины дефектов не исследуются, хотя именно QA должны влиять на оздоровление процесса в целом.

МЕТРИКИ

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

ПРОЦЕССЫ

Организация ISO составила целую линейку стандартов на тему показателей продукта:

• ISO/IEC 25010:2023 (Модель качества продукта) — словарь характеристик качества продукта;

• ISO/IEC 25019:2023 (Модель качества в использовании) — словарь характеристик качества с точки зрения пользователя;

• ISO/IEC 25021 / 25022 / 25023 / 25024 (Библиотеки метрик) — единицы измерения, метрики качества в использовании, метрики продукта, метрики данных;

• ISO/IEC 25040, ISO/IEC/IEEE 15939 (Руководства по разработке метрик) — ориентированные на бизнес, ориентированные на реализацию.

Я буду использовать эти стандарты в основе, но в своей интерпретации практика.

ИСТОЧНИКИ ДАННЫХ

Для расчета метрик понадобятся:

• EPMS — система управления дефектами (Task Tracker). Хранит данные о дефектах.

• ITSM, HD, APM, IMS — системы мониторинга продукта, инфраструктуры, поддержки пользователей, инцидентов. Необходимы для настройки всестороннего мониторинга продукта и его жизни на бою.

• Официальные протоколы о выполнении постпродакшн-этапов в почте, опросники. Накапливают данные об успешности постпродакшн-этапов.

К началу

---

Производство

Управление качеством работает, когда критерии качества:

• формализованы;

• соответствуют ожиданиям заказчиков качества;

• заложены в процессы принятия решений.

Нормы качества 

Нормы качества — это ориентиры для понимания разницы между «хорошо» и «плохо». Пороговые значения определяются из устоявшихся стандартов (оракулы тестирования) и уточняются потребителями качества. 

Основные группы потребителей: 

• Бизнес (C-level, Sales, Marketing): формирует стратегические цели, рыночные обещания и требования к доходности. Он может ответить, когда срывались сделки, происходил отток клиентов, случались денежные потери или недополучение прибылей из-за качества, и привести примеры на своем языке.

• Производство (PO/PM, DM, SA/Analyst): отвечает за реализацию фичей и приоритеты. Помогает подтвердить сегментацию продукта на функциональные блоки и критерии качества.

• Разработка (Dev, Architect, TechLead, Delivery): отвечает за архитектурную целостность, чистоту кода и минимизацию технического долга. Помогает определиться с внутренними стандартами.

• Контекст и эксплуатация (Legal, Support, Users, Auditors): задает рамки закона, безопасности, стабильности и реального пользовательского опыта. Это главные ориентиры в определении критериев успешности околопродакшн-этапов.

Внутренние контракты о качестве 

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

Критерии готовности релиза (Release Exit criteria): 

• Охват тестами и состав дефектов (результаты тестирования): какие типы тестирования необходимо выполнить, максимальный порог проваленных тестов, максимальное количество дефектов каждого приоритета. 

• Функциональная готовность (границы тестирования): что должно быть проверено, формальные признаки завершенности каждой фичи. 

• Готовность поставки (что входит в состав продукта): билды, конфигурации, план отката, релиз-ноты, подлежащие публикации, формальные признаки публикации. 

• Готовность документации (что входит в состав документации): инструкции, реестр известных дефектов для саппорта, реестр вероятных рисков для мониторинга, формальные признаки передачи. 

Целевые показатели уровня услуг (Service Level Targets):

• Классификация сбоев (как ранжировать неполадки): определение, что является инцидентом, а что — проблемой, матрица приоритетов. 

• Сроки устранения (временные нормативы): время реакции на сообщение о неполадке и срок на ее устранение.

К началу

---

Релиз

Жизненный цикл релиза не заканчивается в день релиза. Разработка и тестирование — это половина пути, она про вложения в продукт. Полноценная жизнь начинается во второй половине: на этапах внедрения, сдачи заказчику, проверки гипотез. В этой части находятся профит от релиза и фактические показатели использования (качества). 

Область измерений

Качество релиза измеряется в стоимости постпродакшн-этапов. Цена выражается в количестве попыток внедрения/сдачи, сроках и трудоемкости выполнения этапов, количестве замечаний (в т. ч. преобразованных в баги), а также в показателях стабильности продукта, зафиксированных в системах управления процессами, официальных протоколах и SLA-договорах с заказчиком. 

• Delivery (внедрение) — непосредственный деплой релиза в продуктивную среду, конфигурирование при необходимости. Он успешен, если выполнен с первого раза, за ожидаемый срок, без аврального привлечения команды. Примеры провального деплоя: хотфиксы в процессе деплоя или сразу после него, неожиданное обновление базы данных на 6 часов, «неправильное» конфигурирование продукта из-за недостатка документации.

• Acceptance & Sign-off (приемка и утверждение) — официальная демонстрация продукта заказчику, выполнение оговоренной программы испытаний, ответы на вопросы. Фиксация замечаний с возможным последующим оспариванием критичности и типа. Она успешна, если выполнена с первой сессии, не встретила критических замечаний и концептуальных споров о том, «что просили» и «что сделали». Примеры провальной приемки: не удалось показать программу испытаний из-за ошибок, произошел технический сбой, заказчик имеет претензии к исполнению функциональности в целом, приемка заканчивается договором о повторном показе той же самой функциональности. 

• UAT & Validation (валидация пользователями) — выполнение программы испытаний будущими пользователями, фиксация замечаний с последующим разбором командой разработки. Она успешна, если программа испытаний выполнена за ожидаемый срок и не встретила технических сбоев. Все замечания пользователей зафиксированы, в том числе замечания, порожденные непониманием того, «как это работает».

• Hypercare (период повышенной поддержки) — работа в продуктивной среде в режиме повышенной поддержки. Он успешен, если бизнес-гипотеза, ради которой выпущен релиз, проверяется, SLA выдерживается, а сама работа не зашумлена ошибками и сбоями. 

В зависимости от бизнес-модели компании набор этих этапов может быть разным, но два из представленных есть в любой.  

Метрики релиза целесообразно снимать после выполнения этих этапов.

К началу

---

Продукт

Качество продукта — не про продукт, а про его пользователя (злоумышленник тоже пользователь). В продукте меняется всё: окружение, среда, контекст, интенсивность, цели использования, да и он сам тоже непрерывно меняется. Наиболее устойчивы в этой конструкции когнитивные способности человека. Измерение качества продукта — это мониторинг показателей его использования через призму когнитивных норм. 

Область измерений

Современный стандарт ISO выделяет 9 универсальных характеристик. Они применимы к любому ПО в разной степени значимости. 

• Функциональная пригодность. Ключевая характеристика, с помощью которой продукт зарабатывает. Актуальна для всех, измеряется в:

  • показателях использования продукта — количестве переходов, кликов, данных в БД; 

  • продуктовых метриках по категориям (показатели с ожидаемых площадок, ОС, моделей устройств, территорий).

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

  • степени доступности внешних сервисов — количестве таймаутов и сетевых ошибок; 

  • качестве связности — количестве ошибок 5xx. 

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

  • доступности систем в целом — на уровне приложения и инфраструктуры; 

  • валидности лицензий и сертификатов (срок действия должен иметь запас на период эксплуатации);

  • отсутствии инцидентов (нет хотфиксов и инцидентов, зарегистрированных в системах); 

  • показателях «шума» — ошибках в логах, обращениях в техподдержку (не должно быть всплесков и тренда на увеличение). 

• Производительность. Отвечает за то, как продукт справляется с интенсивностью использования. Измеряется в: 

  • производительности на уровне приложений — RPS, время отклика, вес ответа, доля ошибок; 

  • производительности на уровне инфраструктуры — доступное физическое место, загрузка RAM, CPU, IOPS, пропускная способность сети.

Режим использования продукта совпадает с режимом его пользователей (временем суток, часовым поясом в регионе) и влияет на трактовку измерений. 

Иерархия метрик 

Структура задает метрикам смысл: консолидирует данные до ответов на конкретные вопросы, выстраивает причинно-следственные связи от симптомов к очагам проблем. 

Метрики первого уровня закрывают вопросы на естественном языке: 

• На базе потребностей пользователя. Абстрагируясь от кнопок и сервисов, продукт — это инструмент закрытия потребностей. Он организует или упрощает жизнь, сокращает коммуникации, развлекает. Уровень того, насколько хорошо он это делает, сродни измерениям качества в его предметной области. Например, приложение по вызову такси. Оно заменяет оператора. Качество сервиса оператором вычисляется в количестве обработанных звонков, скорости подбора нужного автомобиля, отсутствии срывов заказов, точности информирования клиента. Они же актуальны и для приложения. 

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

Метрики второго и следующих уровней конкретизируют показатели предыдущих.

К началу

---

Примеры метрик Quality Dashboard 

Здоровье релиза (Release Health)

# Процесс: Релиз 👈, Управление потоком 👈, Метрика: Эффективность тестов 👈.

Успешный релиз — тот, что успешно прошел продакшн-этапы, а совокупный объем дефектов (включая найденные пользователями) не превысил допусков Exit-критериев. 

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

Полезно заранее оценить зону анализа, соизмеримую с собственными силами и приоритетом фокуса:

• Анализ сбоев на продакшн-этапах будет находить сбои коммуникаций на входе в производство и выходе из него + критические сбои в производстве с точки зрения бизнеса.

• Анализ дефектов — тонкая настройка, которая собирает сбои любого характера внутри производства. При большом потоке дефектов может врать из-за сильной дисперсности (это как анализировать слона через лупу: неясно, что перед глазами — хвост или нога). Отличный способ поиска улучшений, когда критические системные проблемы уже решены. 

• Анализ фильтрации дефектов будет отлавливать процессные сбои внутри производства. Ниже приведен пример закономерностей по личным наблюдениям. 

RISK: Релизные риски

Контекст. Процесс создания ценности — замер итоговых рисков непосредственно перед релизом. 

Выборка. Фильтр данных по дефектам, найденным в релизе + фильтр по задачам на разработку продукта (“элементы продукта”) + фильтр по результатам тестов, привязанным к “элементам продукта”. Группировка по компоненту.

Аналитические срезы:

• Task analyze link срез со стороны “элементов продукта”: какие изменения входят в компоненты с наибольшим скоплением дефектов, изменения приоритетные? Для них нужен план митигации рисков? 

• Bug analyze link срез со стороны дефектов: какие дефекты пойдут в релиз? какие конкретно риски сбоев наиболее вероятны судя по скоплению дефектов в компоненте? Что можно сделать, чтобы снизить риск при внедрении? какой план, если риск сработает?  

Component

Scope Weight, шт./ SP

Test Waight, шт.

Pass Rate, % (шт.)

Bug Coun, шт.

Open Blocker Bug, % (шт.)

Open Critical Bug,  % (шт.)

Open Normal Bug,  % (шт.)

Open Low Bug,  % (шт.)

Known Bug,  % (шт.)

Task analyze link

Bug analyze link

• GQM Scope Weight: Цель: Фиксация масштаба изменений в компоненте. Вопрос: Сколько изменений было сделано в компоненте за релиз? Метрика: Количество задач “элементов продукта” ИЛИ Сумма оценок всех задач в релизе.

• GQM Test Weight: Цель: Фиксация масштаба тестирования в компоненте. Вопрос: Сколько тестов было включено в пул проверок? Метрика: Количество тестов, привязанных к “элементам продукта”..

• GQM Pass Rate: Цель: Оценка уровня стабилизации компонента. Вопрос: Какая доля тестов закончилась успехом? Метрика: Доля Last Execution = PASS от Test Weight.

• GQM Bug Count: Цель: Фиксация количества дефектов, найденных в релизе. Вопрос: Сколько всего дефектов было создано? Метрика: Количество дефектов, найденный в релизе. 

• GQM Blocker/Critical/Normal/Low Bug: Цель: Оценка уязвимости компонента. Вопрос: Какое распределение дефектов в компоненте по приоритетам? Метрика: Доля от Bug Count

• GQM Known Bug: Цель: Оценка забракованности компонента. Вопрос: Сколько известных дефектов выпускаем в релизе? Метрика: Доля от Bug Count.

IMPACT: Качество релиза

Контекст. Процесс создания ценности — замер итогового результата по факту выполнения -продакшн этапов. 

Stage

Iterations

Cycle Time

Noise

Goal

Source

• Stage: наименование пре- /пост- продакшн этапа. 

• GQM Iterations: Цель: Фиксация количества попыток выполнения этапа. Вопрос: Сколько раз пытались выполнить этап, прежде, чем достигли его цели?  Метрика: показатели количества деплоев из CI, количества календарных событий на показы и UAT.

• GQM Cycle Time: Цель: Фиксация срока выполнения этапа. Вопрос: Сколько времени занял весь этап? Метрика: Календарный срок от начала этапа до официального его завершения. 

• GQM Noise: Цель: Фиксация сбоев, ошибок, замечаний, возникших в ходе выполнения этапа, принятых и непринятых командой. Вопрос: Что затрудняло выполнение этапа, из каких артефактов это видно? 

• GQM Goal: Цель: Фиксация итогового результата этапа. Вопрос: По итогу выпуска релиза, он внедрен, акты подписаны, гипотезы проверены? Метрика: официальное решение.

• Source: ссылки на источники из которых собраны данные — в системы управления, почтовые резолюции, опросники. 

FILTERS: Фильтрация дефектов

Контекст. Процесс отбраковки — замер результативности по факту выполнения -продакшн этапов. 

Выборка. Фильтр данных по дефектам, найденным в релизе. Группировка по приоритету. 

Аналитические срезы:

• Bug analyze link срез со стороны дефектов: какие конкретно криты были остановлены, выпущены и найдены пользователем, как каждый из них отлавливать на шаг раньше?  Какие дефекты сформировали фокус QA на компоненте, какие фокус пользователя, в чем различия условий, сценариев и окружения? 

Priority

Bug Count, шт.

Found  Bug, % (шт.)

Known Bug,% (шт.)

Escaped Bug, % (шт.)

Test: Dirty leader Component

Prod: Dirty leader Component

Bug analyze link

• GQM Bug Count: Цель: Фиксация общего количества дефектов. Вопрос: Сколько дефектов найдено на всех этапах ЖЦ релиза? Метрика: Количество найденных дефектов.

• GQM Found Bug: Цель: Оценка уровня отлова дефектов. Вопрос: Сколько дефектов было найдено до релиза? Доля от Bug Count.

• GQM Known Bug: Цель: Оценка уровня устранения дефектов. Вопрос: Сколько из найденных дефектов НЕ было исправлено и отправляется в релиз? Вопрос: Какую долю дефектов мы осознанно не стали чинить в этом релизе? Метрика: Доля от Bug Count.

• GQM Escaped Bug: Цель: Оценка уровня пропуска дефектов. Вопрос: Сколько новых дефектов было найдено в продуктивной среде после релиза? Метрика: Доля от Bug Count. 

• GQM Test Dirty Leader: Цель: Оценка фокуса внимания до релиза. Вопрос: Какой компонент системы сгенерировал наибольшее количество дефектов в процессе разработки? Метрика: Наименование компонента с максимальным значением Found Bug.

• GQM Prod Dirty Leader: Цель: Оценка фокуса внимания после релиза. Вопрос: Какой компонент системы сгенерировал наибольшее количество дефектов в ходе боевого использования? Метрика: Наименование компонента с максимальным значением Escaped Bug.

К началу

---

Здоровье продукта (Product Health) 

# Процесс: Продукт 👈, Процесс: Производство 👈, Управление тестированием 👈.

Здоровый продукт — это предсказуемый продукт: предсказуемые сроки доработки, предсказуемая эксплуатационная пригодность.

• Предсказуемая пригодность означает, что команда и компания осознают границы своего продукта: перечень функциональностей, поддерживаемые устройства, ОС, зоны присутствия, интенсивность использования и фактическую утилизацию ресурсов. Всё это обеспечивает мониторинг.

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

Требования к мониторингу

Задача мониторинга — поставлять актуальную информацию о продукте. Хорошо, когда в числе его пользователей больше одной роли. Идеально — когда им пользуются все заказчики качества. 

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

QA-инженерам мониторинг служит инструментом диагностики продукта и актуальности тестирования. Диагностика состояния продукта необходима после каждого релиза для:

• проверки работоспособности новых функций;

• отслеживания нестабильных объектов;

• сверки показателей мониторинга с данными бэклога дефектов.

Расхождение данных в мониторинге и бэклоге сигнализирует о системной ошибке в тестировании. Выявленные аномалии должны быть локализованы и устранены.

Требования к бэклогу с дефектами

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

• технический долг по отношению к «мощности» команды (чтобы прогнозировать, за сколько времени и насколько он может быть уменьшен); 

• накопленную и доказанную «хрупкость» отдельных компонентов;

• точность фокуса QA-команды (насколько он совпадает с целями самого продукта).  

Если время жизни дефектов в бэклоге превышает полгода, это хороший повод поставить вопрос об управляемости бэклога и провести «ревизию антресолей».

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

Переработка устаревших багов — это «потери в кубе»: эти дефекты уже съели часы на локализацию и оформление, а актуализировать их — значит повторить всю работу заново. Негласно сроком полного устаревания считается 6 месяцев — это время, через которое команда будет рассматривать старый баг как новый. Есть два пути устранения таких багов: радикальный «исправь немедленно или удали» (как в Microsoft) или мягкий — перенести в архив, чтобы читать как историю. Поскольку QA уже потратили время на эти дефекты, хорошим завершением работы будет проанализировать природу кандидатов на удаление. 

Если размер бэклога существенно превышает мощность команды и растет с каждым релизом, это повод поставить вопрос о близости «точки невозврата», когда команда больше никогда не сможет его вычистить.

Негласно считается, что бизнес может позволить себе тратить на техдолг не более 20% ресурсов (или каждый 5-й релиз). Цифры условны, но порог есть у любого бизнеса и продукта. Превышение этого порога косвенно бьет по всем показателям затрат: сначала растет время на груминг бэклога, потом — вариабельность затрат на однотипные задачи, а затем стоимость любой доработки взлетает вертикально. Перечисленные симптомы означают, что точка невозврата уже пройдена: разработчик стал заложником брака. Чтобы сделать новую фичу, ему приходится перебирать три простыни легаси-кода и еще четыре держать в уме. Необходимо планировать роадмап по рефакторингу и, возможно, расширять команду.

RYG RADAR: Качество продукта

Контекст. Процесс управления качеством — замер качества продукта.

Аналитические срезы:

• Monitoring link: точка входа в мониторинг выбранного измерения. 

Module

Characteristic

Measure (type)

RYG Status

Monitoring link

• Module. Название измеряемого модуля.

• Characteristic. Название характеристики качества. 

• Measure (type). Название измерителя и его тип. Отражает каким конкретно способом замеряется характеристика (клики, время ответа, утилизация ресурсов, всплеск входящего трафика и т.д.) и тип данных метрики (замер по данным реального времени или истории алертов)

• GQM RYG Status. Цель: Оценить результаты измерения наглядно. Вопрос: В норме ли показатели качества? Метрика: Расцветка поля Red-Yellow-Green по заранее определенным пороговым значениям возможного результата. 

STRUCTURE: Деградация продукта

Контекст. Процесс управления качеством — замер вязкости продукта.

Выборка. Фильтр данных по дефектам, побывавшим в открытом статусе в течение отчетного периода. Группировка по компонентам. 

Аналитические срезы:

• Bug analyze link срез со стороны дефектов: какой состав открытых дефектов в компонентах, где требуется чистка? 

Component

Last  Count, шт.

Current Count, шт.

Delta Count, % (шт.)

N/C Blocker Dynamic, шт.

N/C Critical Dynamic, шт.

N/C Normal Dynamic, шт.

Degradation Index

Cycles To Clear

Bug analyze link

• GQM Last Count. Цель: Фиксация объема беклога на начало отчетного периода. Вопрос: Какое количество дефектов было в беклоге на момент предыдущего релиза? Метрика: Количество открытых дефектов на начало периода.​

• GQM Current Count. Цель: Фиксация объема беклога на конец отчетного периода. Вопрос: Какое количество дефектов в беклога на текущий момент? Метрика: Количество открытых дефектов на конец периода.​

• GQM Delta Count.Цель: Оценка разницы между беклогами предыдущего и текущего периодов. Вопрос: Насколько изменился бэклог в большую или меньшую сторону? Метрика: Current Count — Last Count.

• GQM N/C Dynamic (Blocker/Critical/Normal). Цель: Фиксация созданных и закрытых дефектов. Вопрос: Насколько активно разрастался бэклог за период VS как активно гасили тех долг? Метрика: Количество дефектов созданных за период и Количество дефектов, закрытых за период.

• GQM Degradation Index. Цель: Оценка темпа устранения дефектов. Вопрос: Каково соотношение возникающего брака по отношению к мощности его устранения? Метрика: New Dynamic / Close Dynamic.​

• GQM Cycles To Clear. Цель: Прогнозный срок полного устранения брака при  текущей мощностью команды. Вопрос: За сколько релизов можно устранить текущий бэклог при текущей мощности исправления. Метрика: Current Count / Close Dynamic

AGING: Деградация беклога

Контекст. Процесс управления качеством — замер актуальности беклога.

Выборка. Фильтр данных по всем открытым дефектам. Группировка по сроку жизни дефекта — “живые” до 2 мес, “зависшие” до полугода, “умершие” старше полугода. (цифры являются примерами) 

Аналитические срезы:
Технические ссылки для перехода от статистики к конкретным спискам:

• Bug analyze link срез со стороны дефектов: Какие конкретно дефекты в «зависших» — критические, в чем риск? Что конкретно может произойти, если убрать из беклога «умершие» дефекты?

Age Range

Open Bug, шт.

Open Bug in Range, % (шт.)

Yearly Fixed  Count, шт.

Fixed Bug in Range, % (шт.)

Bug analyze link

• GQM Open Bug Count: Цель: Фиксация количества дефектов в каждой возрастной категории. Вопрос: Сколько открытых дефектов находится в каждой временной когорте? Метрика: Количество открытых дефектов.  

• GQM Open Bug in Range: Цель: Оценка доли открытых дефектов в каждой временной когорте. Вопрос: Какая доля дефектов относится к каждой категории? Метрика: Open Bug Count во временной категории / ∑Open Bug Count всего бэклога. 

• GQM Yearly Fixed Count: Цель: Фиксация количества  дефектов со сроком жизни когорты, закрытых за последний год. Вопрос: Сколько дефектов было решено за последний год за время, заданное возрастной категорией ? Метрика: Количество закрытых дефектов с резолюцией Resolved.

• GQM Fixed Bug in Range: Цель: Оценка доли исправленных дефектов в каждой временной когорте. Вопрос: В какой доле случаев были исправлены дефекты, дожив до сроков временной когорты? Метрика:  Yearly Fixed Coun во временной категории / ∑Yearly Fixed Coun всего бэклога.

К началу

---

Управление тестированием

Тестирование полиморфно по своей природе. Само по себе оно на качество не влияет: тесты не исправляют код, не изменяют потребительских свойств. Качество получается за счет воздействия результатами тестов на производство. Воздействие — это пассивный залог, соответственно, качество опосредовано тестированием.

По типу расходов в компании оно относится к операционным (OPEX). Эта статья сравнима с обеспечением производства серверами и оборудованием. А бизнес, как известно, больше всего целится на сокращение операционных расходов.

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

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

В этой зоне рассмотрим управление жизненным циклом теста: как он появляется, отрабатывает инвестиции и устаревает.

КОНТЕКСТ 

По жизненным стадиям тест проходит следующие этапы (наименования авторские): 

1. Генерация идей — подбор тестов на базе требований и бизнес-домена.

2. Приземление идеи — отсечка лишних идей в связи с нюансами реализации и ограничениями продукта/релиза. 

3. Разработка — пополнение репозитория с тестами. Заводится новый или обновляется старый.

4. Использование — включение теста в прогоны. Здесь тест выполняет свою прямую функцию.

5. Утилизация — исключение теста из репозитория, когда он морально устарел (не участвует в прогонах / не находит багов / не покрывает критические сценарии). 

По существу тесты проверяют продукт в двух векторах: 

• Функциональная пригодность: решает ли фича исходную задачу.

• Работоспособность: действует ли она в заданных условиях.

Примеры непригодной работоспособности:

• Отчет работает, но непригоден. Данных недостаточно или, наоборот, они избыточны и бессистемны. Отчет будет отвергнут.   

• Фича работает, но непригодна. Вместо обещанного ускорения заказчик получил замедление. Он откажется от фичи.

• Код исправен, но сценарии неактуальны. Фича работает на данных, которые неинтересны рынку. 

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

В последнее время происходит большой сдвиг фокуса QA с пригодности на работоспособность. Рассмотрим этот сдвиг парадигмы в 4 философиях (оценка пригодности авторская): 

• Блэк: выступает за универсальные нормы, применимые в любом продукте. Обеспечение пригодности лежит на аналитике. Пригодность — 3 из 10.

• Бах: рассматривает всё тестирование через призму пригодности. Подбирает содержание и границы тестирования, отталкиваясь от исходного мотива (что хочет получить пользователь). Пригодность — 8 из 10.

• Криспин и Грегори: явно разделяют валидацию пригодности (техника 3 Amigo) и верификацию работоспособности (много-много автотестов). Оценка пригодности уходит внутрь команды, ответственность за нее разделяется между участниками. Пригодность — 6 из 10.

• «Поздний» Уиттакер: выступает за автоматизированное удерживание универсальных норм. За обеспечение пригодности отвечают Product Owner и метрики, а фактическое тестирование уходит к боевому пользователю. Пригодность — 4 из 10. 

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

1. Начинается с продукта (в виде требований, задач, сторей, API-методов, кода — чего-либо, что представляет сам продукт). Это то самое, что будет покрываться и что делает законченным известный термин «Тестовое покрытие <чего?>». 

2. Включает представление тестов в промежуточном виде (тест-модели, CJM-карты, риск-карты). Это осязаемый результат тест-анализа, доступный для обсуждения с командой. 

3. Завершается созданием тестов, привязанных к объекту покрытия. 

МЕТРИКИ

Представление жизненного цикла (ЖЦ) теста показывает: основания для новых тестов, глубину тест-дизайна, выхлоп от тестов в использовании. Всё это делает тестовое покрытие управляемым. 

ПРОЦЕССЫ

В статье будет рассмотрено:

• Тестирование функциональной пригодности. У его тестов самый длинный и запутанный ЖЦ. Остальные виды тестирования переиспользуют фрагменты из него.

• Трассировка — от требований, через риски, в тесты и дефекты.

В качестве управленческого фреймворка для подбора тестов я рассмотрю Risk-Based Testing (TMap Next). Отмечу, сама я работаю в Context-Driven Testing, а в рамках статьи хочу провести теоретический эксперимент (буду рада комментариям и поправкам). Это означает, что:

• метрики трассировки в этой статье основаны на чистой теории;

• процессы описаны в сравнении и с опорой на контекстное тестирование.

ИСТОЧНИКИ МЕТРИК

Для расчета метрик понадобятся:

• RMS — система управления требованиями. Хранит данные о требованиях и рисках. 

• TMS — система управления тестированием. Хранит данные о тестах, их прогонах, связях с рисками и дефектами.  

• EPMS — система управления дефектами (Task Tracker). Хранит данные о дефектах.

К началу

---

Тестирование функциональной пригодности 

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

Типы активностей

По своей сути и предмету воздействия в процессе выделяются следующие активности: 

• Тест-анализ — вычитка и выяснение требований с целью построить карту функциональностей (аналог тест-модели). Результат: замечания к требованиям (Requirement Issues), отзеркаленные пробелами в карте.

• Риск-анализ — выписывание рисков в реестр на основе карты, оценка, обсуждение вопросов «что, если», выбор рисков, подлежащих покрытию тестами. Результат: реестр рисков продукта (Product Risk Register). 

• Тест-дизайн и реализация тестов — описание тестов на базе карты функциональностей и рисков. Результат: тест-кейсы (Test Cases).

• Подготовка к тестированию — настройка тестовых сред, подготовка тестовых прогонов. Результат: тестовые прогоны (Test Cycles), готовые к выполнению.

• Тестирование и ретест — динамическое тестирование новой версии продукта. Результат: результаты выполнения тестов (Test Execution) и баг-репорты (Defects).

Конфигурация и прослеживаемость

Процесс должен установить связь между результатами (в виде артефактов) и:

1. Тестовыми активностями. Нужно определить, какая активность какие конкретно артефакты порождает. 

2. Системами управления процессом. Нужно определить, каким образом артефакты заводятся, хранятся и преобразуются в системах. 

Ниже приведен пример визуализации процесса для данной модели. 

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

К началу

---

Артефакты

Артефакт — это овеществленный результат активности. Он может быть проверен, разобран, передан и переиспользован. Метрики снимаются именно с артефактов на основе заполненных в них атрибутов. 

Замечания к требованиям (Requirement Issues) создаются на этапе тест-анализа для устранения логических противоречий и пробелов в требованиях. Условия функционирования этого процесса: 

• Атомарность фиксации. Каждый вопрос регистрируется отдельно. Недопустимо объединять разные логические противоречия в одну запись.

• Авторская верификация. Право закрытия принадлежит инициатору (QA). Полученный ответ — это этап проработки, а не финал. Спорные моменты разрешаются живой коммуникацией.

Атрибуты: даты открытия, первого ответа и закрытия.

Реестр рисков продукта (Product Risk Register) создается в рамках риск-анализа. Он фиксирует:

• Анализ исключений («Что, если?»). Граничные условия, параллельные процессы, аномалии в данных и угрозы безопасности.

• Анализ ограничений (блокаторы). Дефицит инфраструктуры («ручек», песочниц, доступов). Всё, что не проверено технически, имеет 50% риск отказа.

Атрибуты: уровень риска (Risk Level), источник, даты и статусы создания и утверждения рисков.  

Артефакты тестирования:

• Тест-кейсы (Test Cases). Атрибуты: приоритеты, статусы готовности теста к использованию. 

• Тестовые прогоны (Test Cycles, Test Runs). Атрибуты: сборка, цель прогона, исполнитель, даты и статусы выполнения прогонов. 

• Результаты выполнения тестов (Test Execution). Атрибуты: статусы исходов (фактические результаты).

К началу

---

Стандарты

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

Стандарты тест-дизайна 
Глубина и актуальность тестирования определяются качеством тест-дизайна. Стандарт тест-дизайна задает вектор размышлений QA-инженера.

Известные стандарты в тест-дизайне: 

• Эвристическая модель HTSM (SFDPO) Дж. Баха — задает 5 векторов дизайна тестов: «Структура», «Функционал», «Данные», «Платформа», «Операции». Автор предлагает отыскивать границы функциональности с каждого ракурса системы. Модель адаптирована под сложные системы с высокой ценой ошибки.  

• Туры Уиттакера — задают 20–25 целей тестирования, по одной на каждый тур. Автор формализовал и геймифицировал правила исследовательского тестирования, представив их в виде туров вроде «всё сломать», «всё ввести неверно», «всё сделать по инструкции» и т. д. Позже он применил эти же паттерны для дизайна наборов автотестов. Методология легкая, подходит для тест-дизайна простых продуктов с разнородной ЦА. 

• Business Driven Test Management (TMap Next) — наделяет QA ролью владельцев рисков. Задает 4 линзы для поиска рисков в продукте: «Процессы», «Данные», «Интерфейсы», «Инфраструктура». В модели предлагается найти как можно больше рисков и отсечь лишние. Модель адаптирована под диалог с бизнесом и вовлечение команды в тест-дизайн.

Линзы Tmap NEXT

1. PROCESS (Процессы / Functionality)

«Поведение системы во времени».

• Фокус: Поток действий (Workflow).

• Ключевой вопрос: «Может ли пользователь пройти свой путь от А до Я?»

• Что ищем (Риски):

  • Блокировки процесса (Dead ends).

  • Нелогичные переходы между статусами.

  • Потеря контекста при переходе между шагами.

  • Соответствие бизнес-процессу (Business Fit).

2. DATA (Данные / Information)

«Состояние системы».

• Фокус: Сущности, их жизненный цикл и хранение.

• Ключевой вопрос: «Сохранится ли информация корректно и навсегда?»

• Что ищем (Риски):

  • CRUD-операции (Create, Read, Update, Delete).

  • Миграция (данные из старой системы).

  • Целостность данных (ссылочная целостность).

  • Конвертация (валюты, форматы дат).

  • Конфиденциальность (GDPR, маскирование).

3. INTERFACE (Интерфейсы / Connectivity)

«Связи системы».

• Фокус: Точки соприкосновения с внешним миром и людьми.

• Ключевой вопрос: «Понимаем ли мы друг друга?»

• Что ищем (Риски):

  • GUI: Юзабилити, валидация полей, верстка.

  • System-to-System (API): Протоколы, форматы сообщений, обработка ошибок связи.

  • Import/Export: Форматы файлов, кодировки.

4. STRUCTURE (Структура / Technical Suitability)

«Внутренности системы».

• Фокус: Как это сделано и где это живет.

• Ключевой вопрос: «Выдержит ли конструкция?»

• Что ищем (Риски):

  • Сложность кода (Complexity) -> риск скрытых багов.

  • Инфраструктура (Servers, Cloud).

  • Производительность (Performance).

  • Безопасность (Security) на уровне архитектуры.

  • Настройки и параметры конфигурации.

Стандартизация тест-кейсов (тестовый репозиторий)

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

Однако статус «актива» не формируется автоматически. Он возможен, только если репозиторий тестов пополняется и обновляется синхронно с продуктом. Добавилась фича — добавился тест, обновилась фича — изменился тест. Чтобы обновить тест, его сначала нужно найти. Если структура поиска запутана, глубина описания внутри теста теряет смысл. Поэтому стандарт хранения тестов (навигация) стоит выше стандарта их описания.

Иерархия и группировка тестов в репозитории:

• По физическому слою: разделение по типу (UI, Logic, API). Это принципиально разные тесты с разным форматом и разным жизненным циклом.

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

В большинстве TMS структура тестов задается вручную, что вынуждает выбирать между логической и физической иерархией. Современные инструменты (например, TestOps) решают эту проблему, позволяя менять иерархию на лету.

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

Стандартизация баг — репортинга

Баг-репорты — наиболее массовый артефакт тестирования с широким кругом потребителей (Dev, QA, PM, Support). В условиях больших массивов данных стандарт необходим для быстрой идентификации, поиска дублей и эффективного управления бэклогом исправлений.

Подход к декомпозиции дефекта определяется природой компонента. Границы баг-репорта должны соответствовать логике его исправления. Например, в логических ошибках критична изоляция: один отчет — одна ошибка, так как подмешивание лишних данных препятствует точной локализации. А в визуальных ошибках (UI) целесообразна группировка по контексту (форма, экран, фрейм), что избавляет от избыточности однотипных отчетов и ускоряет работу с версткой.

Фактура дефекта — это совокупность доказательств, подтверждающих фактический результат. Она должна полностью зеркалировать описание проблемы и исключать необходимость дополнительного обследования. Объективность контекста обеспечивается сбором данных со всех слоев системы: визуальными подтверждениями (скриншоты, видео, URL), системными артефактами (логи, редиректы, Request/Response), выборками из БД, выводами CLI-команд, фрагментами конфигураций. 

Атрибуты дефекта описаны в разделе Поток дефектов.

К началу

---

Примеры метрик Control Dashboard

Тестовое покрытие (Coverage)

# Управление тестированием 👈, Процесс: Тестирование функциональной пригодности 👈, Процесс: Артефакты  👈.

Тестовое покрытие — это количественный показатель «проверенности» объекта тестирования: требований, рисков, сторей, эндпоинтов, форм, фичей, кода. Оно отражает охват тестами, но не гарантирует их полноту.

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

TEST ANALYSIS: Тест-анализ

Контекст. Процесс тест-анализа — замер результативности.

Выборка: Фильтр данных по требованиям из RMS привязанным к задачам в составе релиза. Группировка по типу требований. 

Аналитические срезы:

• Issues analyze link срез со стороны замечаний: Какие конкретно критические замечания не были отвечены, они заведены в виде рисков? Как решаются неотвеченные комментарии? 

• Req analyze link срез со стороны требований: Какие требования совсем не покрыты рисками, какая доля ЦА будет пользоваться описанной в требованиях функциональностью? Какие требования с аномально маленьким количеством замечаний, с аномальном большим? С чем связана аномалия?  

Req Group

Req Count шт.

Issue Count шт.

Unresolved Debt, %  (шт.)

Critical Debt, шт.

Risk Count, шт.

Risk Coverage by Req, % (шт.)

P20  Risk Density

P85  Risk Density

Issue analyze link

Req analyze link

• GQM Req Count. Цель: Фиксация количества требований в релизе. Вопрос: Сколько требований было создано в пользу релиза? Метрика: Количество единиц требований.

• GQM Issue Count. Цель: Фиксация количества уникальных замечаний к требованиям. Вопрос: Сколько всего вопросов/замечаний было заведено для уточнения требований? Метрика: Количество суммы замечаний к требованиям.

• GQM Unresolved Debt. Цель: Оценка степени неопределенности тест-дизайна. Вопрос: Какая доля замечаний осталась нерешенной? Метрика: Доля от  Issues Count.

• GQM Critical Debt. Цель: Фиксация принятой угрозы. Вопрос: Сколько критических замечаний осталось нерешенными? Метрика: Количество открытых замечаний с высоким приоритетом. 

• GQM Risk Count. Цель: Фиксация количества рисков, заведенных в ходе тест-анализа. Вопрос: Какое количество рисков сформировано для последующего тест-дизайна? Метрика: Количество рисков, привязанных к требованиям.

• GQM Risk Coverage. Цель: Оценка покрытия требований рисками. Вопрос: К какой доле требований привязаны риски? Метрика: Доля от Req Count.

• GQM P20/85 Risk Density: Цель: Оценка минимальной/максимальной плотности рисков на каждое требование. Вопрос: Какое количество рисков на одно требование является стандартным? Метрика: 20/85 перцентиль количества рисков на одно требование.

RISK-BASED TEST DESIGN: Тест-дизайн

Контекст. Процесс тест-дизайна — замер результативности.

Выборка: Фильтр данных по рискам из RMS, привязанным к требованиям релиза. Группировка по типу требований. 

Аналитические срезы:

• Risk analyze link срез со стороны рисков: Какие риски остались не взвешенными, какие из них наиболее критичны? Какие взвешенные риски не попали в тестовое покрытие, какие из них наиболее критичны?

Req Group

Input Risks Count, шт.

Brainstorm Risk Count, шт.

Assessment Done, % (шт.)

Coverage Risk, % (шт.)

Func.Risk, шт.

Env Risk, шт.

NonFunc Risk, шт.

Risk analyze link

• GQM Input Risk Count. Цель: Фиксация общего количества рисков после работы с требованиями. Вопрос: Сколько всего рисков идентифицировано в ходе анализа требований? Метрика: Количество рисков (равное количеству из метрик тест-анализа).

• GQM Brainstorm Risk Count. Цель: Фиксация общего количества рисков после мозгового штурма с командой. Вопрос: Сколько всего рисков идентифицировано после обсуждения с командой? Количество всех рисков. Метрика: Количество рисков в релизе. 

• GQM Assessment Done. Цель: Оценка взвешенности рисков. Какая доля рисков получила оценку P*I? Метрика: Доля от Brainstorm Risk Count.

• GQM Coverage Risk. Цель: Оценка объема критических угроз. Какая доля выявленных угроз подлежит тестированию? Метрика: Доля от Brainstorm Risk Count.

• GQM Target (Func, Env, NonFunc). Цель: Фиксация итогового количества рисков для каждого вида тестирования. Вопрос: Сколько рисков каждого типа должно быть покрыто тестами? Метрика: Количество функциональных рисков, рисков окружения, нефункциональных рисков. 

RTM: SMOKE TEST: Трассировка дымового тестирования

Контекст. Процесс дымового тестирования — замер результативности 

Выборка: Фильтр данных по тестам из TMS, привязанным к требованиям релиза. Группировка по модулю тестирования. 

Аналитические срезы:

• Req analyze link срез со стороны требований: Какие требования вообще не покрыты тестами, что нужно, чтобы были покрыты?

• Test analyze link срез со стороны тестов: Какие тесты не были проведены, какой план устранения последствий? 

• Bug analyze link срез со стороны дефектов: Какие дефекты из критических сценариев наиболее существенны для релиза? 

Test Module

Req Count шт.

Smoke Test Count, шт.

Smoke Coverage, % (шт.)

Smoke Execute Rate, % (шт.)

Smoke Pass Rate, % (шт. )

Open Bug, шт.

Req analyze link

Test analyze link

Bug analyze link

• GQM Req Count. Цель: Фиксация объема требований, подлежащих тестированию. Вопрос: Сколько требований нужно покрыть Smoke тестами? Метрика: Количество единиц требований (равное количеству из блока тест-анализа).​

• GQM Smoke Test Count. Цель: Фиксация объема Smoke тестов на базе требований. Вопрос: Какое количество Happy Path тестов запланировано? Метрика: Количество тестов, привязанных к требованиям.​

• GQM Smoke Coverage. Цель: Оценка покрытия требований Smoke тестами. Вопрос: Какая доля требований модуля покрыта Smoke-тестами? Метрика: Доля от Req Count.​

• GQM Smoke Execute Rate. Цель: Оценка проверенности Happy Path. Вопрос: Какая доля Smoke-тестов была выполнена? Метрика: Доля Smoke Test Count с непустым Execution.​

• GQM Smoke Pass Rate. Цель: Оценка работоспособности Happy Path. Вопрос: Какая доля Smoke-тестов прошла успешно? Метрика: Доля Smoke Test Count, где Last Execution = PASS.​

• GQM Open Bug. Цель: Фиксация текущей забракованности. Вопрос: Сколько дефектов открыто? Метрика: Количество дефектов в открытом статусе.

RTM: FUNCTIONAL TEST: Трассировка функционального тестирования

Контекст. Процесс функционального тестирования — замер результативности 

Выборка: Фильтр данных по тестам из TMS, привязанным к функциональным рискам релиза. Группировка по модулю тестирования. 

Аналитические срезы:

• Risk analyze link срез со стороны рисков: Какие риски остались непокрытыми, из-за чего, риски приняты заказчиком? Какие риски покрыты меньше обычного, с чем это связано? Какие риски были недопроверны, они приняты заказчиком? 

• Test analyze link срез со стороны  тестовых прогонов: Из каких тестов состоит аномально высокое покрытие рисков? Это связано с риском или подходом к покрытию тестами? 

• Bug analyze link срез со стороны дефектов: какие из открытых дефектов наиболее существенны для релиза?

Test Module

Risk Count шт.

Risk Test Count, шт.

Risk Coverage, % (шт.)

P20 Risk Density

P85 Risk Density

Risk Execute Rate, % (шт.)

Risk Pass Rate, % (шт.)

Open Bug, шт.

Risk analyze links

Test analyze links

Bug analyze links

• GQM Risk Count. Цель: Фиксация объема рисков, подлежащих тестированию. Вопрос: Сколько угроз нужно покрыть риск-ориентированными тестами? Метрика: Количество рисков (равное количеству Func Risk из блока тест-дизайна).​

• GQM Risk Test Count. Цель: Фиксация объема риск-ориентированных тестов. Вопрос: Сколько тестов направлено на снижение выявленных рисков? Метрика: Количество тестов, привязанных к рискам.​

• GQM Risk Coverage. Цель: Оценка покрытия рисков тестами. Вопрос: Какая доля выявленных рисков покрыта тестами? Метрика: Доля от Risk Count.​

• GQM P20/85 Risk Density. Цель: Оценка средней плотности тестов на один риск. Вопрос: Какое количество тестов является пределом для половины рисков в модуле? Метрика: 50-й перцентиль количества тестов на один риск.​

• GQM Risk Execute Rate. Цель: Оценка митигации рисков. Вопрос: Какая доля риск-ориентированных тестов была выполнена? Метрика: Доля Risc Test Count, где Last Execution = PASS.​

• GQM Risk Pass Rate. Цель: Оценка закрытия рисков. Вопрос: Какая доля риск-ориентированных тестов прошла успешно? Метрика: Доля Risc Test Count, где Last Execution = PASS.​

• GQM Open Bug. Цель: Фиксация текущей забракованности. Вопрос: Сколько дефектов открыто? Метрика: Количество дефектов в открытом статусе.

RTM: CONFIGURATION TEST: Трассировка конфигурационного тестирования

Контекст. Процесс конфигурационного тестирования — замер результативности.

Выборка: фильтр данных по тестовым прогонам из TMS, привязанным к рискам окружения. Группировка по модулю тестирования.

Аналитические срезы:

• Risk analyze link срез со стороны рисков: Какие риски остались непокрытыми, из-за чего, риски приняты заказчиком? Какие прогоны содержат тестов меньше обычного, с чем это связано? Какие риски были недопроверны, они приняты заказчиком? 

• Run analyze link срез со стороны тестов: Из каких тестов состоят аномально большие прогоны? Это связано с риском или подходом к покрытию тестами? 

• Bug analyze link срез со стороны дефектов: какие из открытых дефектов наиболее существенны для релиза?

Test Module

Risk Count  шт.

Run Count, шт.

Test Count, шт.

Run Coverage, % (шт.)

P20 Run Volume

P85 Run Volume

Env Execute Rate, % (шт.)

Env Pass Rate, % (шт.)

Open Bug, шт.

Risk analyze Link

Run analyze link

Bug analyze link

• GQM Risk Count. Цель: Фиксация объема рисков окружения, подлежащих тестированию. Вопрос: Сколько рисков, связанных с инфраструктурой и средой подлежит тестированию? Метрика: Количество рисков (равное количеству рисков Env Risk из блока тест-дизайна).​

• GQM Run Count. Цель: Фиксация количества созданных тестовых прогонов на проверку окружения. Вопрос: Какое количество риск-ориентированных прогонов запланировано? Метрика: Количество тестовых прогонов с Environment из списка рисков.​

• GQM Test Count. Цель: Фиксация количества тестов в прогонах. Вопрос: Сколько всего тестов включено в тестовые прогоны? Метрика: Количество тестов в составе прогонов.​

• GQM Run Coverage. Цель: Оценка покрытия рисков тестированием. Вопрос: Какая доля рисков окружения была запланирована в тест? Метрика: Доля от Risk Count.​

• GQM P 20/85 Run Volume. Цель: Оценка фактического объема прогонов. Вопрос: От скольки до скольки тестов включено в прогоны? Метрика: 20 и 85-й перцентиль количества тестов на один прогон.​

• GQM Env Execute Rate. Цель: Оценка митигации рисков среды. Вопрос: Какая доля проверок окружения была выполнена? Метрика: Доля Test Count, где не пустой Execution . ​

• GQM Env Pass Rate. Цель: Оценка митигации рисков среды. Вопрос: Какая доля проверок окружения завершилась успешно? Метрика: Доля Test Count, где Last Execution = PASS. ​

• GQM Open Bug. Цель: Фиксация текущей забракованности. Вопрос: Сколько дефектов открыто? Метрика: Количество дефектов в открытом статусе.

К началу

---

Эффективность тестов (Test Efficiency)

# Управление тестированием 👈, Процесс: Артефакты 👈, Процесс: Стандарты 👈.

Эффективность тестов проявляется в деле — по результатам тестовых сессий. Тестовая сессия — это неразрывная работа тестировщика с продуктом без простоев и переключений. 

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

Тесты в тестовых прогонах (сессиях)
Эффективны, когда повышают продуктивность прогона:

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

• Находят какие-либо дефекты в каждой тестовой сессии. По «парадоксу пестицида» старые тесты со временем перестают находить баги. Неизменные наборы тестов приводят к пропуску дефектов в старых сценариях (где код не менялся) из-за изменений окружения, контекста использования или правок в связанных модулях. Для «лечения» полезно временами менять очередность тестов и входные данные. 

Баг-репорт проведенного теста
Эффективен тот баг-репорт, что понятен разработчику с первого раза. Непонятные уходят в отмененные дефекты. Однако не все отмены говорят об ошибках в тестировании. Это могут быть полезные, но «недокрученные» эксперименты или сбой коммуникаций в цепочке SA → QA → DEV. В реальности туда могут попадать даже классные предложения, усиливающие киллер-фичу, но не прописанные в требованиях явно. Поэтому полезно просматривать все отмененные дефекты, группируя их по категориям.

TEST LIBRARY HEALTH: Здоровье тестового репозитория

Контекст. Процесс тестирования — замер эффективности тестов.

Выборка.Фильтр данных по тестам в активном тестовом репозитории. Группировка по приоритету теста. 

Аналитические срезы:

• Test analyze link срез со стороны тестов:  Какие конкретно тесты не используются, что они проверяют, почему не включаются в прогоны, зачем лежат в репозитории? Какие конкретно тесты давно не находят дефектов, автоматизированны ли они, что именно они проверяют?

Priority

Inventory count, шт.

Inventory delta, шт.

Usage count, шт.

Not Used, % (шт.)

Zero Bugs, %

Test analyze link

• GQM Inventory Count. Цель: Фиксация общего количества тестов в репозитории. Вопрос: Сколько всего уникальных тест-кейсов находится в базе знаний? Метрика: Количество тест-кейсов в активном статусе.​

• GQM Inventory Delta. Цель: Оценка количественного изменения репозитория за период. Вопрос: На сколько тестов стало больше или меньше в репозитории?  Метрика: Разница между текущим и предыдущим значением Inventory Count.​

• GQM Usage Count. Цель: Фиксация востребованности тестов. Вопрос: Какое количество тестов участвовало в тестовых прогонах? Метрика: Количество тестов с непустым Execution в течение отчетного периода.​

• GQM Not Used. Цель: Оценка размера неиспользуемого актива. Вопрос: Какая доля тестов не выполнялась в отчетном периоде? Метрика: (Inventory Count — Usage Count)/Inventory Count.

• GQM Zero Bugs. Цель: Оценка отдачи тестов. Вопрос: Какая доля тестов не находила дефектов за отчетный период? Метрика: Zero Bugs/Inventory Count.

TESTING DYNAMICS: Динамика отлова дефектов

Контекст. Процесс тестирования — замер эффективности прогонов.

Выборка. Фильтр данных по запускам тестов + фильтр по связанным дефектам. Группировка по временному периоду создания дефектов и выполнения тестов. 

Аналитические срезы:

• Bug analyze link срез со стороны дефектов: Какие именно криты были найдены под конец тестирования?

• Test analyze link срез со стороны тестов: Какие именно тесты выполнялись в первый и последний день прогона?

Daily period

All Ex., шт.

New Bug, шт.

All Bug, шт.

New Crit Bug, % (шт.)

All Crit Bug, % (шт.)

Bug analyze link

Test analyze link

• GQM All Ex. Цель: Фиксация количества всех запусков всех тестов, в том числе повторных. Вопрос: Сколько все раз были выполнены проверки за период? Метрика: Количество All Execution.

• GQM New Bug. Цель: Фиксация количества созданных дефектов за период. Вопрос: Сколько новых дефектов было заведено в ходе тестирования? Метрика: Количество созданных дефектов. 

• GQM All Bug. Цель: Фиксация количества заведенных дефектов накопленным итогом. Вопрос: Сколько дефекто было заведено с начала сессии? Метрика: Суммарное количество новых дефектов за текущий и предыдущий периоды. 

• GQM New Crit Bug. Цель: Оценка результативности прогона по приоритетности дефектов. Вопрос: Какую долю от новых дефектов составляют критические и блокирующие ошибки? Метрика: Доля от New Bug.

• GQM All Crit Bug. Цель: Оценка результативности прогона во времени.  Вопрос: Какую долю от общего числа найденных дефектов составляют критические ошибки? Метрика: Доля от All Bug.

REJECT ANALYSIS: Причины отмененных дефектов

Контекст. Процесс отбраковки — замер издержек.

Выборка. Фильтр данных по отмененным дефектам. Группировка по компоненту. 

Аналитические срезы:

• Bug analyze link срез со стороны дефектов: какие именно дефекты составляют наибольшую статью отмен, у них есть что-то общее?

Component

Bug Count, шт.

Not a Bug, % (шт.)

Duplicate,  % (шт.)

Works as Designed, % (шт.)

…

Cannot Reproduce,  % (шт.)

Bug analyze link

• GQM Bug Count. Цель: Фиксация общего количества заведенных дефектов. Вопрос: Сколько всего дефектов было создано? Метрика: Количество дефектов.

• GQM Not a Bug/…/Cannot Reproduce. Цель: Оценка объема издержки каждого типа. Вопрос: Какая доля дефектов была отклонена с некоторой резолюцией? Метрика: Доля от Bug Count.

К началу