В этой статье рассказываю о применении дашборда функциональной составляющей качества продукта, наборе показателей качества, на нём отражаемых, способах их измерения, основанных на рекомендациях стандарта ISO 25023 и показываю положительные изменения в работе продукта.

TLDR или Executive Summary

На изображении представлена компиляция из дашбордов качества с зафиксированными результатами измерений для 4-х версий продукта - с v0.0.3 по v0.0.6:

Тем, кому интересны детали и где там качество, предназначена остальная часть статьи. Будут использоваться термины “характеристика”, “суб-характеристика”, “показатель” качества. Всё это описано в стандарте ISO/IEC 25023 и в связанных с ним стандартах серии 250n:

Состав дашборда

2 плашки с показателями качества - 1 по суб-характеристике “функциональная завершенность” (Completeness) и 1 по суб-характеристике “функциональная корректность” (Correctness). Они оба относятся к характеристике качества “Функциональная пригодность” (характеристика принадлежит модели “качество продукта” - ISO/IEC 25010) и занимают место в нижнем ряду:

Расчет completeness: (Blocked - Total) / Total
Расчет correctness: ( (Blocked - Total) - Failed ) / (Blocked - Total)

Из-за такого расчета легко с первого взгляда недооценить значение показателя Correctness: по цифрам она снизилась, но важно понимать, что в расчет берутся только реализованные требования - увеличив завершенность до 100%, получаем не ухудшившуюся корректность - 84% vs 83% на бОльшем количестве требований:

5 donut-чартов, где цветом обозначен приоритет функционального требования (Low, Medium, High, Critical), а цифрами на чарте отражено их количество. Под каждым чартом - плашки (5 штук в ряд) из двух элементов - “статус” и “количество”.

• Статус - Total (все требования без привязки к результату выполнения соответствующего теста); Failed (требования, проверка которых выявила баги); Blocked (нереализованные требования); Not Run (требования, которые нельзя проверить в конкретный момент из-за ограничений тестирования); Passed (требования, тестирование которых не выявило ошибок)

• Количество - количество требований всех приоритетов с каждым статусом

Для большего понимания, прочтем 2 чарта с одного дашборда:

Total 212 - всего 212 функциональных требований: 110 - Critical / 53 High / 24 Medium / 25 Low

Failed 33 - всего по 33м требованиям были найдены баги: сюда входят 14 Critical / 13 High / 6 Medium требований

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

Анализ измерений

Здесь есть 2 подхода: если смотреть какой-либо один результат, например первый - версия продукта v0.0.3 - то стоит обращать внимание на показатель качества “завершенность”, который в случае неравенства 100% будет стимулировать команду либо к более активным действиям в разработке либо к согласованию уменьшения объема работ. В совокупности с завершенностью также важно субъективное восприятие количества красноты (требования с приоритетом Critical) в статусе Failed и Blocked. Специально подчеркиваю субъективность для проведения параллели - качество, воспринимаемое каждым пользователем (модель качества при использовании, ISO/IEC 25010), тоже субъективно. Однако это не значит, что мы не должны измерять качество: проведя сравнительный анализ показателей для нескольких версий, уже можем оперировать фактами. Более того, на основе измерений можно принимать обоснованные решения (data-driven decision making - DDDM) - в данном случае решение улучшить работу критически важной функциональности.

Матрица трассировки требований?

Опытные менеджеры и инженеры в тестировании могут заметить схожесть с многоликой RTM - матрицей трассировки требований.

Действительно, некая схожесть c дашбордом есть, но важны принципиальные различия:

• Цель RTM - установить связь между элементами документации и элементами ПО (смотрим тут) в то врем как цель дашборда дать (а) емкий обзор (б) состояния качества

• Удобство анализа - просто попробуйте положить рядом 2 RTM и выявить там какие-либо тренды.

С чем работал

• Продукт - для видеонаблюдения и видеоаналитики с использованием ИИ

• Google Data Studio (сейчас это LookerStudio) - для компоновки и отображения дашборда

• ALM Inflectra Spira - система управления требованиями, разработкой и тестированием в одном продукте

• Gitlab - scheduled пайплайн для сбор данных по требованиям и тестированию и выгрузке в Google DS

Вместо заключения

В дополнение к тому, что был единственным участником команды с ролью QA, добавила сложности задача убедить CEO в необходимости приоритизировать требования и внедрить ALM систему, но мне понравился этот опыт и его результат. Также хочу добавить, что только благодаря наличию дашборда нельзя ничего улучшить - важен не факт его наличия, а открывающиеся за счет наличия этого возможности - DDDM, прозрачность для руководства.

Если вам интересно поделиться опытом на тему качества IT-продукта, QACoE (QA Center of Excellence), TCoE (Testing CoE) - пишите в мой линкедин.