Как с помощью SQL отследить все изменения, влияющие на scope версии в JIRA. Часть I

В данной статье затронем вопрос, связанный с version scope management Представим, что очередная версия в JIRA запланирована, все естимейты указаны, определена дата релиза и команда приступает к выполнению задач в текущей версии. Пока все идет своим чередом, постепенно объем работ осваивается, ничто не угрожает срыву озвученных сроков. Но стоит только на пару дней отвлечься от контроля скоупа версии (например, переключившись

» Read more

Качество выполнения таска. Количество Reopen от тестировщиков за период в JIRA. Часть II

В прошлой статье был рассмотрен SQL-запрос, получающий список задач в системе JIRA, которые возвращались на доработку с указанием количества возвратов (фактически — количество переходов в статус Reopen). 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

» Read more

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

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

» Read more