# Процессы Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Архитектура Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Vision (Концепция) Проектное решение ESB Микросервисы и service mesh HTTP/REST RPC DDD Анализ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Сервисы DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux Тестирование Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Тестирование требований Тест-анализ и тест дизайн Интеграционное, API, E2E Тест план Метрики качества Автотесты Selenium XPATH Нагрузочное Данные Ресурсы MDM Big data Об информации SQL intro MongoDB intro Библиотека Системная инженерия Станислав Лем Экстраполяция в будущее Политэкономия Сознание, интеллект

/ АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps Gaming Библиотека ПРОЦЕССЫ ТЕСТИРОВАНИЕ: + ТЕСТИРОВАНИЕ + Тестирование требований + Тест-анализ и тест дизайн + Импакт-анализ в тестировании + API, интеграционное и E2E + Тест план - Метрики качества | Суть | Метрики качества продукта | Метрики качества тестирования | Другое + Android + Автоматизация + Selenium WebDriver + XPATH + Различные расчёты + Безопасность + Нагрузочное
Метрики качества
latest update of the page: 05-03-2024, 20:51 UTC
Суть

Метрика качества (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 в разбивке по методам:

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