Как я поднимал качество продукта в IT-стартапе

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

TLDR или Executive Summary

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

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

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

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

Расчет 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) — пишите в мой линкедин.