Качество выполнения таска и количество возвратов на доработку в JIRA. Часть I

23 июля, 2016 Alexey Pogan changes, quality, SQL для JIRA, task

984

Если в качестве системы управления задачами вы используете JIRA, то наверняка в ваших workflow для задач предусмотрен статус Reopened. В большинстве случаев перевод в этот статус в нашем случае читается как «перевод задачи на доработку при тестировании на тестовой площадке». Полагаю, не стоит переводить задачу в Reopened в случае обнаружения любой баги по задаче. Бага — это отдельный объект учета для планирования. Критичные баги исправляются в текущей версии, менее критичные — переносятся на следующие версии. Reopened — это другой случай. Это когда задача в принципе не выполняется в тестовой конфигурации или не выполняется основной сценарий по ней. Т.е. она настолько «сырая», что нет смысла продолжать ее тестировать. Значит разработчик не потрудился проверить даже самые очевидные вещи и поторопился перенести свой коммит на тест.

Один из способов оценить качество выполнения таска в IT-проекте — это оценить количество возвратов на доработку.

Формулируем аналитику так — «Найти запросы в проекте DEMO которые переводились в статус Reopened с количеством таких переходов». Как оказалось, это очень популярный вопрос, который волнует людей, интересующихся аналитикой в управлении IT-проектами.

Когда я впервые сам поставил перед собой данную задачу, то предполагал, что запрос получится громоздким. Результат удивил меня — запрос получился очень компактным и даже без вложенных подзапросов.

В запросе необходимо соединить 4 таблицы:

project — для фильтрации конкретного проекта (или проектов);

jiraissue — для получения интересующих нас кодов запросов;

changegroup — это специальная развязочная таблица, которая хранит метаинформацию про групповое изменение атрибутов запроса. Даже изменение одного атрибута будет отражено в этой таблице с фиксацией точного даты и времени такого изменения;

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

Итого, интересующий нас запрос выглядит так:

SELECT ji.pkey, 
       ji. summary,
       count(*)
FROM   changeitem ci
       join changegroup cg on (cg.id = ci.groupid)
       join jiraissue ji on (cg.issueid = ji.id)
       join project p on (p.id = ji.project)
where  ci.field = 'status'
       and cast(ci.newstring as nvarchar) = 'Reopened'
       and p.pkey = 'DEMO'
group by ji.pkey, ji. summary

В секции FROM ничего нестандартного — четыре внутренних соединения через JOIN.

В секции WHERE три фильтра:

1. выбор запросов только в проекте DEMO

p.pkey = 'DEMO'

2. отбираем только изменения, касающиеся изменения статуса

ci.field = 'status'

3. отбираем только изменения, изменивших статус запроса на Reopened

cast(ci.newstring as nvarchar) = 'Reopened'

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

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

Рассмотрим в следующей статье, как учесть возвраты только от тестировщиков.

3 комментария