Поговорим о метриках тестирования: какие из них будут наиболее эффективны для внедрения в ваш процесс тестирования, как они снимаются и подсчитываются. На примерах покажу, как этот процесс организован в «Иннотех».
Для чего нужно снимать метрики
Метрики тестирования используются для отслеживания усилий по обеспечению качества выпускаемого программного кода. С их помощью удаётся в численном выражении получить представлении о достижении заданного уровня качества или поставленных целей. Визуальное представление результатов формирует наглядную картину процесса тестирования, которая может показать узкие места.
В процессе тестирования метрики используются:
для отслеживания прогресса команды по срокам проекта, дедлайнам и другим временным отрезкам;
качественной оценки текущего состояния системы;
контроля качества процесса тестирования;
постановки целей и эффективного планирования исходя из понимания существующих проблем.
Останавливаться на текущем качестве функционирования системы и, что более важно, процессов не следует. Именно эти характеристики являются базой для роста эффективности команды и результатных показателей. Рациональность использования человеческого ресурса напрямую завязана на общей производительности. Обидно иметь в команде специалиста, потенциал которого не реализован и на 50%. За такую невнимательность вполне можно заработать не самые приятные бонусы, вплоть до потери репутации и денег.
Какие метрики чаще всего упоминаются в статьях по тестированию
При тестировании на проектах можно выделить ряд метрик, которые чаще всего упоминаются в большинстве обучающих курсов и статей.
Passed/Failed Test Cases. Используется для оценки отношения удачно пройденных тестов к завершившимся с ошибками. Метрика помогает оценить успешность прохождения тестов.
Not Run Test Cases. Демонстрирует количество тестов, которые нужно выполнить для данного проекта. Метрика помогает определить причины невыполнения тестов и способы их устранения.
Open/Closed Bugs. Формируется из отношения открытых багов к закрытым. Метрика оценивает скорость устранения багов, а также позволяет выявить причины, по которым ошибки остались незакрытыми.
Reopened/Closed Bugs. Рассчитывает соотношение переоткрытых багов к закрытым. Метрика демонстрирует эффективность закрытия бага разработчиками и поможет выявить причины, по которым исправление ошибок находится на низком уровне.
Bugs by Severity/Priority. Общее количество багов по серьёзности/приоритету. Метрика показывает качество предоставляемого кода на тестирование.
Какие метрики необходимо снимать дополнительно?
Кроме стандартных метрик, в «Иннотех» используется ещё и ряд дополнительных. Они позволяют получить объективную картину процесса.
Покрытие тестовыми сценариями и чек-листами
Применяется к требованиям, пользовательским историям, критериям приёмки, рисков или кода. Тестировщики на основе метрики могут заняться выявлением не покрытых тестовой документацией фичей. Непокрытая функциональность несёт определённый риск, который будет недопустим на многих проектах.
Для оценки покрытия можно использовать матрицу трассировки требований.
Процент написанных тестовых сценариев и чек-листов
За основу можно взять общее количество фичей, матрицу трассировки, user story. Следует также оценивать плотность покрытия требований. Для этого стоит применять атомарность — каждая функциональность должна быть разбита на максимально атомарные фичи, которые также следует покрывать тестовой документацией.
Процент выполненных работ по подготовке тестовой среды, тестовых данных
Тестирование производится на тестовых данных, поэтому важно понимать, насколько они полные и корректные. Проверки должны сопровождаться необходимыми тестовыми данными, охватывающими все аспекты проверяемого кода. Для их подготовки мы используем таблицы доменного анализа и попарного тестирования, а также таблицы и диаграммы переходов и состояний.
Метрика необходима для оценки критерия готовности начала тестирования. Необходимо отталкиваться от количества необходимых тестовых данных и отслеживать прогресс путём отношения готовности к необходимой норме.
Метрики выполнения тестов
Отражают количество пройденных тест-кейсов и проваленных кейсов, отношение выполненных кейсов к общему числу кейсов и проваленных кейсов к общему числу кейсов, среднее время прохождения кейса. Эту метрику мы отслеживаем, чтобы правильно распределять ресурсы тестировщиков, приоритизировать кейсы, подключать дополнительные силы в прохождение регресса, определять текущую динамику для корректировки сроков.
Как правило, это реализуется RMS-системами, также можно отслеживать количество пройденных кейсов в excel-таблицах.
Метрики дефектов
Сюда входят показатели плотности, количества обнаруженных и исправленных дефектов, частоты отказов и результатов подтверждающих тестов. Это позволяет максимально объективно получить информацию о качестве продукта в конкретном отрезке времени. Конечно, удобство пользования сложно оценить, опираясь на плотность дефектов. Однако статус продукта относительно требований — вполне себе. Также опираясь на информацию о блокирующих и высокоприоритетных дефектах можно скорректировать ориентацию разработки.
Необходимо собирать эту метрику в разрезах регрессов и текущего состояния проекта. Можно отслеживать по упавшим тест кейсам, либо вести дополнительную статистику в excel-таблицах.
Информация о статусе задач, специалистов, загруженности и трудозатратах
Метрика отслеживает загруженность команды тестирования, распределение трудозатрат по задачам и так далее. Труднее всего будет внедрить метрику, если на проекте не поддерживается ежедневное ведение журнала работ. Однако позитивные влияния метрики позволят правильно распределять время по задачам, отслеживать реальную и ожидаемую оценку задач, корректировать оценку в будущем.
Можно отслеживать метрики с помощью ежедневного ведения журнала работ в Jira либо вести учёт в других системах, которые используются на проекте.
Финансовая информация
К метрике относятся стоимость тестирования, проекта и другие затраты команды.
Метрика необходима для планирования финансовых ресурсов, а также чтобы отслеживать «утечки» этих ресурсов. Эта метрика необходима, так как позволяет избежать дыр в бюджете и более эффективно показывать расходы команды стейкхолдерам.
Реализуется путём учёта финансовых расходов команды, а также планирования будущих трат.
Заключение
Мониторинг процессов необходимо проводить регулярно, сопоставляя результаты на разных этапах разработки. Актуальность метрик контролируется внедряющими их специалистами, а их результаты для корректировки правильности пути должны анализироваться стейкхолдерами.
О том, как снимать метрики, можно написать целую статью. Экономя время, вкратце резюмирую:
для того чтобы получить возможность крупного выигрыша в перспективе, необходимо внедрять снятие метрик в процессы уже сейчас, пожертвовав лишь небольшим количеством времени;
неотъемлемой составляющей качества этих метрик будет служить контроль специалистов.
