Про Тестинг: обеспечение качества, тестирование, автоматизация

Раздел: Обеспечение Качества > Метрики - создание, использование и анализ

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

Согласно международному стандарту ISO 14598:

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

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

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

Создание, использование и анализ метрик

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

  1. Метрики по тестовым случаям (Test Cases)
  2. Метрики по багам / дефектам
  3. Метрики по задачам

Давайте более детально разберем каждую из них:

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

НазваниеОписание
Passed/Failed Test Cases

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

Not Run Test Cases

Метрика показывает количество тест кейсов, которые еще необходимо выполнить в данной фазе тестирования. Имея данную информацию, мы можем проанализировать и выявить причины, по которым тесты не были проведены


Метрики по багам

НазваниеОписание
Open/Closed Bugs

Метрика показывает отношение количества открытых багов к закрытым (исправленным и перепроверенным)

Reopened/Closed Bugs

Метрика показывает отношение количества переоткрытых багов к закрытым (исправленным и перепроверенным)

Rejected/Opened Bugs

Метрика показывает отношение количества отклоненных багов к открытым

Bugs by Severity

Количество багов по серьезности

Bugs by Priority

Количество багов по приоритету


Хотим отметить, что метрики "Open/Closed Bugs", "Bugs by Severity" и "Bugs by Priority" хорошо визуализируют степень приближения продукта к достижению критериев качества по багам. Имея требования к количеству открытых багов, после каждой итерации тестирования мы сравниваем их с реальными данными, тем самым видя места, где нам нужно прибавить, для скорейшего достижения цели.

Метрики "Reopened/Closed Bugs" и "Rejected/Opened Bugs" направлены на отслеживание работы отдельных участников групп разработки и тестирования.

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

  1. Требования к функции можно трактовать по разному
  2. Тестировщик не точно описал проблему
  3. Некачественное поверхностное решение проблемы (фикс бага)

Второй пример покажет для чего необходима метрика "Rejected/Opened Bugs":
Мы наблюдаем, что процент отклоненных (Rejected) багов очень большой. Это может значить:

  1. Требования к функции можно трактовать по разному
  2. Тестировщик не точно описал проблему
  3. Разработчик не желает исправлять допущенную им ошибку или не считает, что это на самом деле ошибка. (Эта проблема является прямым следствием 2-ой, возникшей из-за не точного описания)

Все эти проблемы заметно дестабилизируют обстановку на проекте. Поэтому, при их возникновении, рекомендуется провести короткую беседу с руководителями проектных групп, чтобы в последствии уменьшить количество переоткрытых и отклоненных дефектов.

Метрики по задачам

НазваниеОписание
Deployment tasks

Метрика показывает количество и результаты установок приложения. Процедура установки приложения была описана в статье Процедура проведения установки новой версии ПО (Deployment WorkFlow). В случае, если количество отклоненных командой тестирования версий будет критически высоким, рекомендуется срочно проанализировать и выявить причины, а также в кротчайшие сроки решить имеющуюся проблему.

Still Opened Tasks

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


Метрики по задачам могут быть разные, мы привели лишь две из них. Также интересна может быть метрика по времени выполнения задач и многие другие.

* * *

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


Автор: Алексей Булат

Наверх