# ПРОЦЕССЫ Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Теория ограничений АНАЛИЗ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Vision (Концепция) Сервисы АРХИТЕКТУРА Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Solution Design (Проектное решение) DDD Микросервисы и service mesh ESB HTTP/REST RPC DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux ТЕСТИРОВАНИЕ Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Шаблоны Тестирование требований Тест-анализ Тест план Тест дизайн Метрики качества Автотесты Selenium XPATH Генератор данных Безопасность Нагрузочное ДАННЫЕ Ресурсы MDM Big data Об информации SQL intro MongoDB intro БИБЛИОТЕКА Курсы Системная инженерия Сознание, интеллект Политэкономия Сумма технологии Экстраполяция в будущее Красивые диаграммы Арт
Эта страница:
Черпнуть мудрости Метрики качества продукта Метрики по обеспечению качества Другое QG (Quality Gates)
Другие страницы:
ТЕСТИРОВАНИЕ Тестирование требований Тест-анализ Тест план Тест дизайн Метрики качества Android Автоматизация Selenium WebDriver XPATH Генератор случайных данных Различные расчёты Безопасность Нагрузочное
Другие разделы:
# АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps БИБЛИОТЕКА ПРОЦЕССЫ ТЕСТИРОВАНИЕ
Метрики качества
last update: 03-10-2020, 07:54
Черпнуть мудрости
Метрики качества продукта

Моё личное видение метрик качества продукта:

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

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

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

Метрики по обеспечению качества

Метрика (QA metric) - это количественный масштаб и метод, который может использоваться для измерения.

Введение и использование метрик необходимо для улучшения контроля над процессом разработки, в частности над процессом тестирования.

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

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

  • Метрики по тестовым случаям
  • Метрики по багам / дефектам
  • Метрики по задачам

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

Название Описание
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 в разбивке по методам:

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

QG (Quality Gates)
Из статьи Кто ответит в agile за качество разработки сложных проектов, или методология Quality Gates: