Метрика качества (quality metric) = численное значение, выражающее степень качества продукта (системы) ИЛИ качества процессов его создания, доработки, поддержки.
Иными словами, метрики качества могут быть:

• продуктовыми — для измерения качества продукта (системы);
• процессными — для измерения качества процессов создания, доработки и поддержки продукта (системы). Например, измерения качества самого тестирования.

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

Качество = степень соответствия требованиям или (в широком смысле) ожиданиям.

Моё личное видение метрик качества продукта (product quality metrics), на истину в последней инстанции не претендую:

1. все заявленные бизнес-требования / функции / features должны быть представлены и должны работать. Такая уверенность достигается с помощью определения тестового покрытия.
   Важна ранжировка требований по приоритету и/или ценности, это позволяет приводить требования к общему знаменателю (числам), делая метрику количественной для отслеживания ея динамики. Например:
   • Если в релизе добавили одну feature, поломав две предыдущих, то метрика будет намекать, что вы стремительным домкратом движетесь в бездну.
   • Если добавили одну великую feature, а поломали две ничтожные, то не так уж всё и плохо.
2. использование продукта должно быть удобно:
   • красотища и удобнища (UI/UX) --> не количественная характеристика, а качественная. Тут непросто, но оценить всё-таки возможно. Не забываем про известный "закон Якоба Нильсена": "Пользователи проводят большую часть времени на других сайтах, а не на вашем. Поэтому они хотят, чтобы ваш сайт работал также, как и они";
   • время отклика страниц и функциональных элементов --> чем меньше тем лучше;
   • высокая скорость полного цикла какой-либо пользовательской операции / транзакции / функции. Речь о т.н. E2E сценариях типа регистрации аккаунта, перевод текста, публикация резюме, получение кредита/ипотеки и т.д.
   • низкая частота ошибок, видимых пользователю и мешающих завершить процесс по получению услуги/удовольствия от продукта --> сиречь частота падений клиентской части, серверной части, ошибок в них.
3. охват и обратная связь:
   • популярность продукта (охват аудитории в разрезе по каким-либо сегментам);
   • обратная связь от пользователей (их оценки) в динамике, насколько они вообще удовлетворены;
   • количество обращений пользователей в support (поддержку);
   • ??? количество запусков приложения продукта каждым конкретным пользователем. Но перезапуски могут быть из-за крэшэй, так себе метрика;
   • ??? количество времени, которое потребитель проводит в продукте. Если это продуктом является игра, то много = хорошо. В иных случаях — не факт, ибо длительные сессии могут означать, что в продукте слишком сложно и долго получать результат.
4. Все вышеперечисленные метрики в сравнении с метриками основных конкурентов (если есть):
   • функций больше;
   • у сравнимой функциональности отклик GUI / API / CLI меньше, а качество результата выше (качество картинки из функции фотографирования, например);
   • ошибок, тормозящих/прерывающих процесс использования функции, меньше;
   • скорость предоставления результатов функций выше;
   • охват аудитории и сегментов больше.

В миру встречается много специфических продуктовых метрик навроде:

• попадаемость получаемых/генерируемых данных в datasets;
• процент угадываемости и распознавания текста / голоса пользователя;
• количество crashes и процент затрагиваемых ими пользователей;
• скорость обновления клиентских приложений в разбивке по версиям и ОС;
• количество установок в разбивке по версиям и ОС;
• распределение оценок пользователей в разбивке по версиям и ОС;
• количество сбоев клиентских приложений.

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

• Метрики по требованиям
• Метрики по тест-кейсам
• Метрики по багам / дефектам
• Метрики по задачам

Метрики по требованиям

Название	Описание
Business Requirements coverage, %	Метрика показывает показывает какая часть бизнес-требований (фичей, функций, юзкейсов) вообще покрыта тестами.
Features, functions, use-cases coverage	Поскольку функции, фичи и юзкейсы бывают вариативными (имеют несколько вариантов входа, выполнения, выхода), то важно измерять сколько из возможных вариаций по каждому юзкейсу нас покрыто тест-кейсами.

Метрики по тест-кейсам

Название	Описание
Passed/Failed Test Cases	Метрика показывает результаты прохождения тест-кейсов, а именно отношение количества удачно пройденных к завершившимся с ошибками. В идеале, к концу проекта, количество провальных тестов стремиться к нулю
not runned yet Test Cases	Метрика показывает количество тест-кейсов, которые еще необходимо выполнить в данной фазе тестирования. Имея данную информацию, мы можем проанализировать и выявить причины, по которым тест не были проведены
Automated scenarios, %	процент автоматизации тестов, использованных при поставке релиза
Pass, %	доля успешно пройденных в релизе тестов
Retesting, qty	количество повторных прогонов (по сути количество возвратов на доработку)

Метрики по багам

Название	Описание
Opened/Closed Bugs	Метрика показывает отношение количества открытых багов к закрытым (исправленным и перепроверенным)
Reopened/Closed Bugs	Метрика показывает отношение количества переоткрытых багов к закрытым (исправленным и перепроверенным)
Rejected/Opened Bugs	Метрика показывает отношение количества отклоненных багов к открытым
Bugs by Severity	Количество багов по серьезности
Bugs by Priority	Количество багов по приоритету
Bugs in Prod	доля дефектов в Проме

Метрики "Open/Closed Bugs", "Bugs by Severity" и "Bugs by Priority" хорошо визуализируют степень приближения продукта к достижению критериев качества по багам.
Метрики "Reopened/Closed Bugs" и "Rejected/Opened Bugs" направлены на отслеживание работы отдельных участников групп разработки и тестирования.

Метрики по задачам

Название	Описание
Deployment tasks	Метрика показывает количество и результаты установок приложения. В случае, если количество отклоненных командой тестирования версий будет критически высоким, рекомендуется срочно проанализировать и выявить причины, а также в кротчайшие сроки решить имеющуюся проблему.
Still Opened Tasks	Метрика показывает количество все еще открытых задач. К окончанию проекта все задачи должны быть закрыты. Под задачами понимаем следующие виды работ: написание документации (архитектура, требования, планы), имплементация новых модули или изменение существующих по запросам на изменения, работы по настройке стендов, различные исследования и многое другое.

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

Можно измерять качество API в разбивке по методам:

• идемпотентность;
• среднее время ответа;
• процент/количество ошибок.

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