Раздел: Обеспечение Качества > Метрики - создание, использование и анализ
Метрики по обеспечению качества
Согласно международному стандарту ISO 14598:
Метрика - это количественный масштаб и метод, который может использоваться для измерения.
От себя добавим, что введение и использование метрик необходимо для улучшения контроля над процессом разработки, а в частности над процессом тестирования, который мы и будем рассматривать далее.
Цель контроля тестирования состоит в получении обратной связи и визуализации процесса тестирования. Необходимую для контроля информацию собирают (как в ручную, так и автоматически) и используют для оценки состояния и принятия решений, таких как покрытие (например, покрытие требований или кода тестами) или критерии выхода (например, критерии окончания тестирования). Метрики, также могут быть использованы для оценки прогресса выполнения запланированных работ и освоения бюджета
Создание, использование и анализ метрик
На наш взгляд, для большей наглядности имеет смысл сгруппировать метрики по типам сущностей, участвующих в обеспечении качества и тестировании программного обеспечения, а именно:
- Метрики по тестовым случаям (Test Cases)
- Метрики по багам / дефектам
- Метрики по задачам
Давайте более детально разберем каждую из них:
Метрики по тест кейсам
| Название | Описание |
| 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" направлены на отслеживание работы отдельных участников групп разработки и тестирования.
Пример первый:
Допустим, мы имеем ситуацию, когда количество переоткрываемых после починки багов не уменьшается или даже растет. Это является сигналом к тому, что необходимо провести анализ причин, т.к. подобная ситуация может показать, что:
- Требования к функции можно трактовать по разному
- Тестировщик не точно описал проблему
- Некачественное поверхностное решение проблемы (фикс бага)
Второй пример покажет для чего необходима метрика "Rejected/Opened Bugs":
Мы наблюдаем, что процент отклоненных (Rejected) багов очень большой. Это может значить:
- Требования к функции можно трактовать по разному
- Тестировщик не точно описал проблему
- Разработчик не желает исправлять допущенную им ошибку или не считает, что это на самом деле ошибка. (Эта проблема является прямым следствием 2-ой, возникшей из-за не точного описания)
Все эти проблемы заметно дестабилизируют обстановку на проекте. Поэтому, при их возникновении, рекомендуется провести короткую беседу с руководителями проектных групп, чтобы в последствии уменьшить количество переоткрытых и отклоненных дефектов.
Метрики по задачам
| Название | Описание |
| Deployment tasks | Метрика показывает количество и результаты установок приложения. Процедура установки приложения была описана в статье Процедура проведения установки новой версии ПО (Deployment WorkFlow). В случае, если количество отклоненных командой тестирования версий будет критически высоким, рекомендуется срочно проанализировать и выявить причины, а также в кротчайшие сроки решить имеющуюся проблему. |
| Still Opened Tasks | Метрика показывает количество все еще открытых задач. К окончанию проекта все задачи должны быть закрыты. Под задачами понимаем следующие виды работ: написание документации (архитектура, требования, планы), имплементация новых модули или изменение существующих по запросам на изменения, работы по настройке стендов, различные исследования и многое другое |
Метрики по задачам могут быть разные, мы привели лишь две из них. Также интересна может быть метрика по времени выполнения задач и многие другие.
* * *
В заключении хотим отметить, что наличие необходимых метрик и графиков, отражающих изменение состояния проекта в течении времени, позволит вам улучшить не только процесс тестирования, но и разработки в целом, а также облегчит процедуру проведения анализа выполненного проекта, что позволит в дальнейшем не допускать прошлых ошибок.
Автор: Алексей Булат
