# ПРОЦЕССЫ Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление АРХИТЕКТУРА Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Проектное решение ESB Микросервисы и service mesh HTTP/REST RPC DDD АНАЛИЗ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Vision (Концепция) Сервисы 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: 17-04-2023, 20:55 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 в разбивке по методам:

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