Что такое метрики качества
Наука о данных. Модуль 6
Как проверить качество модели с помощью метрик
В предыдущих модулях мы прошли все основные шаги от постановки цели до создания обучающей выборки и тренировки алгоритмов.
В этом модуле вы узнаете:
• как с помощью метрик понять, насколько хорошо работает модель;
• какие метрики подходят для задач регрессии и классификации и в чем основные плюсы и минусы каждой;
• как выбрать метрику для проекта.
Оглавление
Модуль 6. Как проверить качество модели с помощью метрик
Почему мы выбираем метрику на самом старте проекта
Ваше сотрудничество с дата-сайентистом — это вариант отношений «заказчик — подрядчик», а о ключевых вещах и показателях в этом случае принято договариваться «на берегу». Метрика — один из таких ключевых показателей: с ее помощью вы будете оценивать результат работы алгоритма. Поэтому в процессе первоначального обсуждения проекта вопрос о метрике всплывет обязательно.
Давайте вспомним общую схему, по которой можно вести диалог и формулировать запрос к специалисту, и уточним ее, добавив в конец еще один шаг — выбор метрики. Чтобы вам было проще, разберем все на примере:
1. Определите бизнес-задачу
Вы: Компании нужно поднять выручку на 5% до конца года и…
2. Расскажите о конкретных шагах по ее достижению
Вы: … и для достижения этой цели мы хотим допродавать существующим клиентам цифровые продукты, которые будут удачно сочетаться с теми, что они уже у нас покупают. Но чтобы вероятность дополнительной покупки была высокой, рекомендации продуктов должны быть по-настоящему релевантными и качественными (по прикидкам отдела маркетинга, чтобы достичь показателей, мы должны убедить каждого десятого клиента).
3. Определите, можно ли решить задачу с помощью машинного обучения
Дата-сайентист: Можно проанализировать текущую базу клиентов, выявить их поведенческие паттерны и объединить клиентов со схожими паттернами в отдельные сегменты. Затем для каждого сегмента подобрать наиболее релевантные услуги или товары.
4. Определите, что у вас с данными, целевой переменной, объектами и прочим
Вы: У нас есть CRM (англ. Customer Relationship Management, система управления взаимоотношений с клиентами) и другие источники данных о клиентах — мы знаем, что и с какой частотой они покупали ранее, откуда они, какими еще услугами и продуктами компании пользовались или пользуются в их домохозяйстве.
Дата-сайентист: По идее, мы можем набрать достаточно признаков, а модель сама определит их веса и сгруппирует клиентов. Здесь угадывается задача кластеризации.
5. Определите метрику качества
Дата-сайентист: Итак, решено: мы строим рекомендательную систему. Остается понять, как мы определим, что алгоритм подсказывает именно то, что нужно людям? По какой метрике будем оценивать качество?
Чтобы вы могли ответить на этот вопрос, в модуле мы изучим основные метрики машинного обучения.
Метрики для задач регрессии: какие бывают, плюсы и минусы
Любой прогноз может быть не на 100% точен, а вот какое отклонение допустимо, решаете вы, исходя из задач и целей бизнеса. В этом видео Элен расскажет о пяти популярных метриках для работы с числовыми прогнозами и о том, как они помогают выявлять расхождения между оценкой модели и реальностью и «штрафовать» алгоритм за слишком неточные предсказания. Как всегда — с примерами.
А не фигню ли я опять делаю? Как и зачем внедрять метрики качества
Привет, Хабр! Когда-то мы использовали метрику «Вроде бы стало лучше» для оценки качества наших релизов. Но потом мы решили довериться чему-то более надёжному. В этой статье я расскажу о том, как искал гайд по метрикам, не нашёл и создал свой.
Бывает ли у вас такое, что вы делаете вроде бы полезную работу для проекта, но не понимаете, приносит ли это пользу? Вот и мы когда-то писали автотесты, но не могли объективно сказать, стали ли лучше релизы монолита и других сервисов, в которых ведётся активная разработка.
В поисках метрик
Я посмотрел в интернете и почему-то не нашёл статей или готовых гайдов о том, как выбирать правильные метрики, как их собирать и что с ними дальше делать. Но пока искал информацию, нашёл полезные видео и статьи, которые помогли мне справиться с этой непростой задачей. Ссылки на них будут появляться в статье.
Надеюсь, что эта статья будет полезной для тех, кто задумался об измерении чего угодно на своем проекте, но не знает, с чего начать. В статье содержится личный опыт, информация из статей, видео и платных курсов.
До того, как мы решили создать систему метрик качества, мы уже на постоянной основе измеряли:
Внедряем систему измерения качества за 11 шагов
Перед вами чек-лист из 11 шагов, который поможет внедрить всё и не упустить ничего.
Шаг 1. Определите цель своих измерений
Поймите, для чего вы хотите начать измерять что-либо. Измерять просто так, ради измерений, не имеет смысла.
Мы, например, хотели знать, как движемся к целям по качеству, которые поставили себе ранее. Ещё мы хотели видеть динамику показателей после приложенных усилий. Сами по себе цифры текущего состояния ничего не значат. Это просто цифры. Но, наблюдая цифры в динамике, мы можем видеть влияние наших действий.
Шаг 2. Определите целевые показатели
Вам нужно понять, к чему вы стремитесь. Сократить время тестирования? Сократить количество критичных багов в проде? Повысить тестовое покрытие?
В моём случае с определением целевых показателей проблем не возникло, так как в нашей компании есть цели по качеству. Эти цели и стали основой будущих метрик. Наши цели:
Шаг 3. Определитесь с метриками
Подумайте, как вы поймёте, что движетесь к целевым показателям.
На этом этапе работы мне помогла статья «Самые важные метрики QA».
Это время мы разбили на 4 этапа: подготовка стенда, озеленение стейдж пайплайна, ручное регрессионное тестирование, деплой на прод.
Мы разбили это время на этапы, чтобы детально видеть последствия наших действий и иметь возможность точно определить бутылочное горлышко в нашем процессе.
Важно! Не берите сразу много метрик. Три-четыре для начала достаточно. Когда процесс наладится, сможете добавить ещё, если это потребуется.
Много метрик сложно менеджерить. Растёт вероятность, что система не взлетит. А если процесс не взлетит с первого раза, то в следующий раз начинать будет сложнее, так как у вас и сотрудников за плечами будет негативный опыт.
Шаг 4. Определитесь с единицами измерения
Разные показатели можно считать в разных единицах измерения. Сразу нужно выбрать, чтобы у всех метрик была одна единица измерения, иначе можно столкнуться с непониманием и неправильным толкованием.
С этим пунктом у нас возникли проблемы. Время релиза мы считали в часах, включая ночные часы, но за исключением выходных дней. При этом целевое значение было – релиз за 4 часа. Довольно часто случались ситуации, когда мы создавали ветку release-xxx в 16:00 сегодняшнего дня, а заканчивали в 10:00 следующего дня. В нашей метрике считалось 18 часов, но по факту, активные действия проводились всего 3 часа, если не меньше.
Если бы мы продолжали считать таким образом, то никогда не достигли бы показателя «4 часа» по нашей метрике. Встав перед выбором, увеличить цель до 12 часов или брать в учёт только рабочие часы, мы выбрали второе.
Шаг 5. Анализ выбранных метрик на пригодность
В видео «Простые метрики тестирования на практике» спикер предложил крутой способ анализа метрик на пригодность. Нужно ответить на 9 вопросов по каждой метрике и принять решение.
После такого нехитрого анализа сразу становится ясно, нужна ли вам эта метрика или нет. Появляется более глубокое понимание самой метрики и её ценности для компании и вас.
Шаг 6. Согласуйте метрики с заинтересованными лицами
Покажите выбранные метрики тем, кого они будут затрагивать. Обсудите ограничения, которые вы выяснили на этапе анализа, а также способы их устранения или хотя бы снижения. Особенно важно получить согласие и одобрение тех, кто эти метрики будет собирать и заполнять.
Свои метрики я обсуждал в 3 этапа: с тестировщиками, разработчиками и продакт оунерами. Только после того, как все дали явное согласие, что эти метрики показывают качество системы, я смог перейти к следующему шагу.
Шаг 7. Визаулизируйте результаты
Люди не будут вчитываться в таблицы и смотреть динамику самостоятельно. Поэтому вам нужно позаботиться о наглядности.
Я сделал таблицу в Google Sheets, написал формулы и довольный хотел презентовать таблицу коллегам. Наш CTO предложил визуализировать эти метрики. Точнее сделать так, чтобы за 15 секунд было понятно текущее состояние системы: стало ли лучше по сравнению с прошлым спринтом или качество снизилось.
Совместными усилиями мы визуализировали показатели. Потом я попросил людей рассказать, что они увидели на этом графике. Судя по ответам, цели мы добились.
Вот как выглядит визуализация метрики «Качество релизов». Всё наглядно, сразу видно, как сейчас и как было, превышает ли количество проблем количество релизов, стало лучше или хуже по сравнению с предыдущими релизами. В идеальном графике, синяя линия должна стремиться к бесконечности, а красная должна стремиться к 0.
Визуализация отношения «проблемных релизов» к общему количеству релизов
Шаг 8. Соблюдайте периодичность сбора метрик
Важно наладить процесс сбора метрик, поработать над периодичностью. Если процесса не будет, то ваш дашборд потеряет актуальность и умрёт. Важно, чтобы были заинтересованные лица, которые будут этим заниматься. Но если вы озаботились этим, значит заинтересованное лицо уже есть.
Шаг 9. Снова и снова информируйте людей о полученных результатах
Какой бы ни был красивый ваш дашборд, люди не будут туда ходить и смотреть на метрики. Один раз все посмотрят, так как это что-то новенькое, но не на постоянной основе.
Шаг 10. Анализируйте и принимайте решения
Нужно смотреть на метрики, на их основании принимать решения. Можно использовать метрики, как дополнительный аргумент в пользу написания дополнительных тестов или фокусировке на техническом долге, а не на бизнес фичах и т.д.
Шаг 11. Автоматизируйте
Максимально автоматизируйте сбор метрик. Если вы используете популярные TaskMS и TestMS системы контроля версий, системы CI/CD, скорее всего, у них у всех есть открытое API, с помощью которого можно легко вытаскивать эту информацию. Если не умеете сами, просите помочь разработчиков. Возможно, для этого придется изменить некоторые процессы. Это нормально. И это малая цена за те преимущества, которое вы получите, начав собирать метрики.
Например, у нас есть бот, которой помогает релизменам катить релиз и сокращает их рутинные действия.
Итоги и выводы
Принимать решения, которые повлияют на качество продукта, основываясь на ваших внутренних чувствах – плохая затея. Чувства могут обмануть и подтолкнуть вас к неправильному решению. Поэтому просто заведите метрики и систему оценки качества.
Но помните, что заведение метрик – как заведение питомца. Кроме профита от общения с новым другом, вы получаете определённую ответственность и обязательства перед ним. Поэтому заводите метрики осознанно, с пониманием их необходимости и готовностью к преодолению сложностей, ожидающих вас на пути.
Модели качества и надежности в программной инженерии
10.1.2. Метрики качества программного обеспечения
В настоящее время в программной инженерии еще не сформировалась окончательно система метрик. Действуют разные подходы к определению их набора и методов измерения [10.11-10.13].
Система измерения включает метрики и модели измерений, которые используются для количественной оценки качества ПО.
При определении требований к ПО задаются соответствующие им внешние характеристики и их атрибуты (подхарактеристики), определяющие разные стороны управления продуктом в заданной среде. Для набора характеристик качества ПО, приведенных в требованиях, определяются соответствующие метрики, модели их оценки и диапазон значений мер для измерения отдельных атрибутов качества.
Согласно стандарту [1.16] метрики определяются по модели измерения атрибутов ПО на всех этапах ЖЦ (промежуточная, внутренняя метрика) и особенно на этапе тестирования или функционирования (внешние метрики) продукта.
Остановимся на классификации метрик ПО, правилах для проведения метрического анализа и процесса их измерения.
Существует три типа метрик:
Метрики программного продукта включают:
Внутренние метрики продукта включают:
Внутренние метрики позволяют определить производительность продукта и являются релевантными по отношению к внешним метрикам.
Внешние и внутренние метрики задаются на этапе формирования требований к ПО и являются предметом планирования и управления достижением качества конечного программного продукта.
Стандарт ISO/IEC 9126-2 определяет следующие типы мер:
Специальной мерой может служить уровень использования повторных компонентов и измеряется как отношение размера продукта, изготовленного из готовых компонентов, к размеру системы в целом. Данная мера используется также при определении стоимости и качества ПО. Примеры метрик:
При оценке общего количества некоторых величин часто используются среднестатистические метрики (среднее число операций в классе, наследников класса или операций класса и др.).
Как правило, меры в значительной степени являются субъективными и зависят от знаний экспертов, производящих количественные оценки атрибутов компонентов программного продукта.
На основе этих атрибутов можно вычислить время программирования, уровень программы (структурированность и качество) и языка программирования (абстракции средств языка и ориентация на проблему) и др.
В качестве метрик процесса могут быть время разработки, число ошибок, найденных на этапе тестирования и др. Практически используются следующие метрики процесса:
10.1.3. Стандартная оценка значений показателей качества
Оценка качества ПО согласно четырехуровневой модели качества начинается с нижнего уровня иерархии, т.е. с самого элементарного свойства оцениваемого атрибута показателя качества согласно установленных мер. На этапе проектирования устанавливают значения оценочных элементов для каждого атрибута показателя анализируемого ПО, включенного в требования.
По определению стандарта ISO/IES 9126-2 метрика качества ПО представляет собой «модель измерения атрибута, связываемого с показателем его качества». При измерении показателей качества данный стандарт позволяет определять следующие типы мер:
Метрики качества используются при оценке степени тестируемости с помощью данных ( безотказная работа, выполнимость функций, удобство применения интерфейсов пользователей, БД и т.п.) после проведения испытаний ПО на множестве тестов.
Наработка на отказ как атрибут надежности определяет среднее время между появлением угроз, нарушающих безопасность, и обеспечивает трудноизмеримую оценку ущерба, которая наносится соответствующими угрозами.Очень часто оценка программы проводится по числу строк. При сопоставлении двух программ, реализующих одну прикладную задачу, предпочтение отдается короткой программе, так как её создает более квалифицированный персонал и в ней меньше скрытых ошибок и легче модифицировать. По стоимости она дороже, хотя времени на отладку и модификацию уходит больше. Т.е. длину программы можно использовать в качестве вспомогательного свойства для сравнения программ с учетом одинаковой квалификации разработчиков, единого стиля разработки и общей среды.
Если в требованиях к ПО было указано получить несколько показателей, то просчитанный после сбора данных показатель умножается на соответствующий весовой коэффициент, а затем суммируются все показатели для получения комплексной оценки уровня качества ПО.
На основе измерения количественных характеристик и проведения экспертизы качественных показателей с применением весовых коэффициентов, нивелирующих разные показатели, вычисляется итоговая оценка качества продукта путем суммирования результатов по отдельным показателям и сравнения их с эталонными показателями ПО (стоимость, время, ресурсы и др.).
Все метрики 
-атрибута суммируются и образуют 
-показатель качества. Когда все атрибуты оценены по каждому из показателей качества, производится суммарная оценка отдельного показателя, а потом и интегральная оценка качества с учетом весовых коэффициентов всех показателей ПО.
В конечном итоге результат оценки качества является критерием эффективности и целесообразности применения методов проектирования, инструментальных средств и методик оценивания результатов создания программного продукта на стадиях ЖЦ.
Для изложения оценки значений показателей качества используется стандарт [10.4], в котором представлены следующие методы: измерительный, регистрационный, расчетный и экспертный (а также комбинации этих методов). Измерительный метод базируется на использовании измерительных и специальных программных средств для получения информации о характеристиках ПО, например, определение объема, числа строк кода, операторов, количества ветвей в программе, число точек входа (выхода), реактивность и др.
Регистрационный метод используется при подсчете времени, числа сбоев или отказов, начала и конца работы ПО в процессе его выполнения.
Для оценки значений показателей качества в зависимости от особенностей используемых ими свойств, назначения, способов их определения используются:
Атрибуты программной системы, характеризующие ее качество, измеряются с использованием метрик качества. Метрика определяет меру атрибута, т.е. переменную, которой присваивается значение в результате измерения.Для правильного использования результатов измерений каждая мера идентифицируется шкалой измерений.
Стандарт ISO/IES 9126-2 рекомендует применять 5 видов шкал измерения значений, которые упорядочены от менее строгой к более строгой:
Основные показатели процесса QA
В рамках Quality Assurance могут и должны быть использованы различные метрики и показатели качества продукта и процесса разработки. Метрики можно разделить на группы по параметрам, на основании которых они рассчитываются, по этапам жизненного цикла разработки, на которых они применяются, по целям и задачам, по стейкхолдерам, для которых они предназначены. Этот список можно продолжать и дальше.
В этой статье я решил собрать вместе и рассмотреть самые основные, на мой взгляд, группы критериев и измерителей для QA процесса. А в каждой группе я перечислю только самые важные и показательные, опять же на мой взгляд, метрики а также разберу, для чего они необходимы, в каких ситуациях полезны и как их использовать.
Какими должны быть метрики?
Сама по себе метрика в контексте ПО — это численное выражение какого-либо свойства, качества самого продукта или процесса его разработки. Иными словами, это то, с помощью чего мы можем измерить, сравнить и оценить ПО.
Теперь буквально пара комментариев по поводу значений и свойств метрик:
Основные группы метрик для QA
Теоретически возможно придумать свою характеристику, формулу или показатель практически для каждого, даже самого незначительного действия, этапа или статуса процесса QA. Можно учитывать каждый артефакт, все переходы дефектов по статусам, вычислять количество тестов в наборе. Однако, самый важный вопрос, который сразу следует задать себе, когда возникает желание что-то измерить: «Зачем нужна эта информация, как ее можно использовать?». При формирования набора метрик, следует отталкиваться от целей, планов по улучшению процессов и продукта.
Итак, в этой статье мы не будем рассматривать обычные количественные показатели прогресса тестирования, которые используются в большинстве отчетов и статусов. Вместо этого разберем, какие сферы, артефакты и области разработки с точки зрения Quality Assurance мы должны измерять и контролировать для оценки качества выполнения работы. Анализ и оптимизация этих точек крайне важнны для эффективного взаимодействия со стейкхолдерами (https://doitsmartly.ru/all-articles/sw-testing/120-stakeholders-for-qa.html) и разработки ПО в целом:
1. Требования к разрабатываемому ПО.
Совершенно точно мы должны понимать, что разрабатываем и тестируем, и степень этого понимания необходимо уметь оценить. Потенциальные риски или пропущенные проблемы на уровне спецификации могут привести к самым серьезным и дорогим ошибкам.
2. Качество разрабатываемого продукта.
Тут все очевидно: необходимо иметь возможность оценивать качество разработки и ПО, чтобы делать прогнозы и оценку рисков. Важно понимать, насколько продукт является качественным и надежным, опираясь не только на наличие или отсутствие найденных ошибок, но как раз прогнозируя, много ли потенциальных проблем.
3. Возможности команды QA.
Здесь тоже просто: для того, чтобы управлять процессом тестирования, планировать работы и прогнозировать сроки, требуется всегда иметь не только актуальный статус задач, но и знать возможности команды QA.
4. Качество работы команды тестирования.
Помимо качества самого продукта нужно измерять эффективность самого процесса QA и команды тестирования. Чтобы постоянно оптимизировать и улучшать качество работы, требуется знать, где мы находимся сейчас, что позволяет двигаться вперед, а что отбрасывает назад.
5. Обратная связь и удовлетворенность продуктом.
Последняя область, но, конечно же, не по значимости, а по отзывам стэйкхолдеров процесса, потребителей наших услуг, пользователей продукта. Очень важно иметь возможность измерять общую степень удовлетворенности продуктом, выделять тенденции и делать соответствующие выводы. Правильно подобранные для этой группы метрики позволят вовремя выявить возможные проблемы и оперативно применить обратную связь для улучшения процессов.
Далее рассмотрим, какие именно метрики входят в каждую группу, разберем, как именно их можно оценить. Для каждой группы я приведу несколько примеров возможных метрик и опишу их значение. Более подробно эти и некоторые другие индикаторы QA процесса разобраны в моей статье «Самые важные метрики QA» (https://doitsmartly.ru/all-articles/sw-testing/133-the-most-important-metrics-in-qa.html).
Группа 1 — Требования к разрабатываемому ПО
Эта группа метрик позволит оценить, насколько мы проработали требования (user story) к ПО, определить уязвимые места и наиболее сложные, потенциально проблемные фичи ПО, понять, где требуется особый контроль.
1. Тестовое покрытие требования
«Общее количество тестов» / «Общее количество требований»
Назначение метрики: выявить слабые места в тестовом покрытии, подсветить риски.
Метрика вычисляется как количество связей каждого требования с остальными требованиями. При этом используется среднее по всем требованиям значение.
Назначение метрики: дать основание для оценки сроков тестирования и учета возможных рисков. Зная степень взаимного влияния требований друг на друга, можно, например, запланировать дополнительное время и кейсы для сквозного тестирования, проработать регрессионные проверки, посмотреть в сторону интеграции и т.п.
Назначение метрики: показать, как много уже реализованных требований приходится переделывать от релиза к релизу при разработке новых фич. Также метрика дает представление о том, насколько легко масштабируется функционал системы, добавляются новые возможности.
Группа 2 — Качество разрабатываемого продукта
Данная группа метрик позволяет оценить и сравнить от релиза к релизу как качество ПО, так и качество самой разработки.
1. Плотность дефектов
«Количество дефектов в отдельном модуле» / «Общее количество дефектов в ПО»
Рассчитывается как доля дефектов от общего их числа, приходящихся на отдельный модуль в рамках итерации или релиза.
Назначение метрики: подсветить, какая часть ПО является наиболее проблемной. Эта информация поможет при оценке и планировании работ с данным модулем, а также при анализе рисков.
Назначение метрики: показать, на что уходят усилия команды — занимается ли она больше разработкой и отладкой новых фич или основную часть времени тратит на исправления в уже существующих частях ПО.
Назначение метрики: дать оценку качеству разработки и исправления дефектов, а также сложности продукта или отдельного модуля.
Группа 3 – Возможности и эффективность команды QA
Основная задача данной группы метрик заключается в том, чтобы выразить в цифрах, на что способна команда тестирования. Эти показатели можно и нужно рассчитывать и сравнивать на регулярной основе, анализировать тенденции, наблюдая, как на работу команды влияют те или иные изменения.
1. Скорость работы (velocity) команды QA
«Количество story points за N итераций)» / «N»
Рассчитывается как отношение реализованных story points \ требований \ user stories за несколько итераций \ sprints к количеству выбранных итераций.
Назначение метрики: численно выразить возможности, скорость работы команды для дальнейшего планирования объема работ и анализа трендов развития. Метрика позволяет следить за скоростью работы QA, наблюдать за тем, какие внутренние или внешние воздействия на команду влияют на эту скорость.
2. Среднее время жизни дефекта
«Суммарное время исправления найденных дефектов» / «Количество дефектов»
Общее время, в течение которого были открытыми дефекты, найденные в рамках итерации или релиза, к сумме дефектов.
Назначение метрики: показать, сколько в среднем времени уходит на работу с одним дефектом: на его регистрацию, исправление и воспроизведение. Данный показатель позволит оценить время, необходимое на тестирование, выделить области ПО, с которыми возникают наибольшие сложности.
Группа 4 — Качество работы команды тестирования
Задача этого набора метрик: оценить, насколько качественно тестировщики выполняют свои задачи, определить уровень компетенций и зрелости команды QA. Обладая таким набором показателей, можно сравнивать команду с ней же на разных отрезках времени или с другими, внешними группами тестирования.
1. Эффективность тестов и тестовых наборов
«Количество обнаруженных ошибок» / «Количество кейсов в тестовом наборе»
Назначение метрики: показать, как много ошибок в среднем позволяют обнаружить наши кейсы. Эта метрика отражает качество тест дизайна и помогает следить за тенденцией его изменения.
Назначение метрики: продемонстрировать качество тестирования и эффективность обнаружения ошибок — какая доля дефектов была отфильтрована, а какая прошла на продуктив.
Отношение времени, потраченного командой непосредственно на целевые QA активности, к общему количеству часов.
Назначение метрики: во-первых, увеличить точность планирования, а во-вторых, отслеживать и управлять эффективностью работы команды.
Назначение метрики: позволяет использовать поправочный коэффициент для последующих оценок.
Группа 5 — Обратная связь и удовлетворенность пользователей
И в заключение, группа метрик, показывающая, как продукт был принят конечными пользователями, насколько он соответствовал их ожиданиям. При этом в рамках оценки взаимодействия с пользователями нам важна не только обратная связь о самом ПО. Еще одна значимая задача этой группы метрик — показать, удовлетворены ли пользователи процессом взаимодействия с командой ИТ в целом и QA в частности.
1. Удовлетворенность пользователей ИТ сервисом
Проводится регулярный опрос удовлетворенности пользователей сервисом ИТ с выставлением баллов.
Назначение метрики: показать, доверяют ли пользователи команде ИТ, понимают ли, как и почему организована ее работа, насколько эта работа оправдывает ожидания.
Назначение метрики: определить степень участия внешних стейкхолдеров (бизнес, инфраструктура, пользователи, поддержка и т.д.) в работе над продуктом. Имея на руках такую метрику, можно сориентироваться, где требуется получить обратную связь, чтобы однажды не столкнуться с проблемами и непониманием.