Правильное отслеживание багов с помощью Jira Software
Выявляйте, отслеживайте и исправляйте баги на всех этапах процесса разработки, а также составляйте отчеты по багам и задачам.
Что представляет собой инструмент отслеживания ошибок и задач?
Инструменты для отслеживания багов и задач помогают командам разработчиков выявлять, фиксировать и отслеживать баги в создаваемом ПО. Важно обеспечить каждому участнику команды возможность находить и фиксировать баги. Но еще важнее своевременно назначать задачи по их устранению подходящему сотруднику. Правильный инструмент для отслеживания багов и задач обеспечивает команде единое представление всех рабочих задач бэклога независимо от того, баг это или задание по разработке новой функции. Единый источник достоверной информации по всем типам задач помогает командам расставлять приоритеты с ориентиром на стратегические цели и непрерывно работать над поставкой ценности клиентам.
Jira Software для отслеживания ошибок
Быстро выявляйте баги, назначайте соответствующие задания и расставляйте приоритеты в Jira Software, отслеживая при этом все аспекты цикла разработки ПО. Мощное ядро рабочего процесса в Jira обеспечивает ясное представление о статусе бага, а с помощью автоматических уведомлений вы будете получать актуальную информацию по мере завершения задач из бэклога. Jira Software становится для команды разработчиков объединяющей средой, которая помогает просматривать весь цикл разработки продукта и обеспечивает контроль над ним.
Выявляйте и отслеживайте баги ПО
Выявляйте баги в любой части проекта разработки ПО с помощью Jira Software. Как только баг найден, создайте задачу и добавьте к ней все необходимые подробности, например описания, уровень важности, снимки экрана, версию и т. д. Задачи могут касаться чего угодно: багов ПО, заданий по проекту, оставленных запросов и т. д. Для каждого типа задач можно настроить специальный рабочий процесс.
Легко назначайте задачи и расставляйте приоритеты
После выявления багов можно установить для каждой из них соответствующий приоритет, оценив важность бага, срочность его устранения, а также ресурсы команды. Назначить ответственного за устранение бага можно парой нажатий, а для расстановки приоритетов достаточно перетащить баги в бэклог команды или в столбец To do (К выполнению). С единым источником достоверной информации вы можете передавать нужные сведения всем участникам процесса и следить за тем, чтобы команда работала над поставленными задачами в порядке приоритета.
Выбираем подходящий баг-трекинг
Я общался с десятками QA-инженеров из разных компаний и каждый из них рассказывал о том, что у них используют разные системы и инструменты для баг-трекинга. Мы тоже пробовали несколько из них и я решил поделиться решением, к которому мы пришли.
Интро
Буду банален. Ошибки появляются и обнаруживаются на различных этапах процесса разработки. Поэтому можно разделить баги на категории, в зависимости от времени их обнаружения:
С чего мы начинали, или Jira
Два года назад у нас была выделенная команда тестировщиков, которые вручную тестировали продукт после интеграции кода всех команд. До этого момента код проверялся разработчиками на девелоперских стендах. Ошибки которые находили тестировщики заносились в бэклог в Jira. Баги хранились в общем бэклоге и переезжали из спринта в спринт с другими задачами. Каждый спринт два-три бага доставались и чинились, но большинство оставалось на дне бэклога:
У меня есть подозрения, что за все время работы нашей сети, никто, кроме тестировщиков не воспроизводил эту ошибку. Такого рода ошибки и составляют большинство багов, которые не исправляются.
При таком подходе, когда заносятся все найденные баги, некоторые из них дублируются и большинство из этих багов не чинится возникают проблемы:
Прощай Jira, да здравствует Kaiten
Весной 2018 года мы отказались от Jira и перешли в Kaiten. Смена инструментов была вызвана причинами, о которых Андрей Арефьев написал в статье «Почему Додо Пицца стала использовать Kaiten вместо связки Trello и Jira». После перехода в Kaiten наш подход к работе с багами не изменился:
Время экспериментов, или нет
Мы решили поэкспериментировать с форматами и создали отдельную доску в Kaiten, на которой хранили баги и меняли статусы. Мы упростили заведение баг-репорта, чтобы тратить меньше времени. При добавлении карточки в Kaiten тестировщики помечали разработчиков. Об этом им на почту отправлялось уведомление. Мы вывели эту доску на монитор, который висел в проходе рядом с нашим рабочим местом, чтобы разработчики видели прогресс и процесс тестирования стал прозрачным. Эта практика тоже не прижилась, потому что основной канал общения – Slack. Наши разработчики не проверяют почту часто. Поэтому это решение быстро перестало работать и мы снова вернулись к Slack.
Верните муравьишек
После неудачного эксперимента с доской в Kaiten, некоторые разработчики всё ещё были против формата с сообщением в Slack. И мы стали думать как трекать баги в слаке и решить проблемы, которые мешали разработчикам. В результате поисков наткнулись на приложение для Slack, Workast, которое помогает организовать работу с тудушками прямо в мессенджере. Мы подумали, что это приложение позволит управлять процессом работы с багами более гибко. У этого приложения были свои плюсы: смена статусов и назначение на разработчиков по одному нажатию кнопки, завершенные задачи скрывались и сообщение не разрасталось до огромных размеров.
Так выглядели решенные задачи в приложении Todo и просьбы вернуть «муравьишек». После окончания пробного периода приложения Workast мы решили от него отказаться. Потому что пользуясь этим приложением, мы пришли к тому же, что было во время, когда мы пользовались Jira. Оставались некоторые баги, которые кочевали в этом списке из регресса в регресс. И с каждой итерацией их становилось больше. Возможно, стоило доработать процесс работы с этим расширением, купить его и пользоваться, но мы этого не сделали.
Наш идеальный способ по работе с багами сейчас
Во-первых, у нас не стало выделенной команды тестировщиков. Все тестировщики разошлись в команды разработчиков, для усиления компетенции тестирования команд. Благодаря этому мы стали находить ошибки раньше, до того как произойдет интеграция кода команд.
Во-вторых, мы отказались от ручного регрессионного тестирования в пользу автоматического.
В-третьих, мы приняли «zero bug policy». В статье «#zerobugpolicy или как мы баги чиним» bevzuk подробно рассказывает как мы выбираем баги, которые чиним.
Сегодня процесс работы с багами выглядит следующим образом:
Итоги
Коротко говоря, мы отказались в принципе от баг-трекинговой системы. С помощью такого подхода работы с багами мы решили несколько болей:
А как в вашей компании устроен процесс работы с багами?
Обзор популярных систем bug-трэкинга
Содержание статьи
Рано или поздно в растущих компаниях бесплатная система управления проектами (читай: Redmine) перестает справляться с потоком приходящих задач, а ее минусы перевешивают все существующие плюсы. И именно тогда нужно сделать правильный выбор и заплатить за ту систему, которая будет соответствовать всем необходимым требованиям.
Что такое Agile и Scrum?
Agile-методы — это методы разработки программного обеспечения, ориентированные на разработку по итерациям (планирование обновлений и контроль их выполнения).
Как гласит Википедия, основных идей гибкой методологии разработки четыре:
Суть методологии заключается в том, что разработчики от итерации к итерации выполняют требования заказчика, постоянно улучшая свой продукт. Есть несколько популярных методов работы по Agile. Одним из них является Scrum.
Scrum — это методология управления проектами, позволяющая планировать изменения, которые будут выполнены, и контролировать их выполнение.
Для контроля выполнения задач в Scrum используется доска (рис. 2), по которой можно отслеживать процесс выполнения задач. Доска может иметь много состояний, у каждой команды они называются по-своему, но основные из них три:
Также на доске есть диаграмма, по которой можно отслеживать ход выполнения задач во время итерации и корректировать список задач.
Зачем что-то менять?
Конечно, когда количество задач в системе около двух тысяч и все пользователи привыкли к ней, никто не хочет ничего менять. Для того чтобы решиться на переход, нужно быть уверенным, что текущая система не справляется, и четко знать, что нужно найти.
Что не устраивало в Redmine?
Безусловно, Redmine заслуживает внимания и имеет большое количество плюсов, и при этом еще и бесплатный. Можно как душе угодно настраивать права, статусы, трекеры и любые другие поля, достаточно удобно делать выборки, создавать задачи по почте и так далее. Очень удобна сквозная нумерация задач, хотя тут есть и плюсы, и минусы. Но приспособить его к Scrum не представляется возможным (кроме плагинов, которые являются платными и тормозят систему): доски нет, отслеживать время крайне неудобно, чтобы расположить задачи в произвольном порядке, нужно вводить дополнительные поля и сортировать по ним, нет нормальной интеграции c Git и SVN и так далее.
Что хочется увидеть в новой системе?
Перед тем как изучать системы, нужно четко определить критерии, по которым системы будут оценены:
Кандидаты
После изучения рынка и чтения большого количества статей и отзывов было отобрано пять вариантов для сравнения: популярная и раскрученная JIRA Agile, Trello, Targetprocess, Assembla и YouTrack от питерской компании JetBrains. Соответствие всем критериям оценено по 10-балльной шкале.
Assembla
Соответствие критериям
Язык: теоретически русский
Интеграция с Git: Есть и не требует дополнительных программ
Доска: 7 (из 10), не очень понятная, на 2/3 на английском
Настраиваемые поля: 8 (из 10) есть
Фильтрация: 9 (из 10)
Создание задач по email: есть
Права доступа: теоретически нормально настраиваемые
Локальная установка: нет
Цена: 30 пользователей — 49 долларов в месяц, 50 пользователей — 99 долларов в месяц
Впечатления
Плюсов у системы достаточно много. У них очень хорошая служба поддержки: в 19:30 по Москве задал вопрос по возможностям программы и ответ получил в течение пяти минут. Очень качественная статистика: можно прослеживать любые действия разработчика и видеть, что и когда он делал. Все изменения статусов, открытие/закрытие задач и коммиты отображаются в статистике. Можно прямо в системе заполнять ежедневные отчеты для Stand Up. Хорошо реализован поиск.
Один из главных минусов программы — перевод. Он сделан некачественно, и переведено далеко не все. В программе нужно долго разбираться. Вряд ли получится понять что-то, зайдя в нее первый раз. Задачи нельзя переносить между проектами, установить баг-трекер на свой сервер нельзя, что неудобно для больших компаний.
Trello
Язык: только английский
Интеграция с Git: нет
Доска: 6 (из 10) хорошая, но не переведена
Настраиваемые поля: 6 (из 10) есть
Фильтрация: 5 (из 10)
Создание задач по email: есть
Права доступа: теоретически нормально настраиваемые
Локальная установка: нет
Цена: 5 долларов в месяц
Впечатления
Система удобна тем, что она вся построена на основе доски и все, что в ней есть, находится на одном экране: и задачи, и история изменений, и любые комментарии. Но это же и главный минус программы. Она слишком простая и не предназначена для больших команд. Задачи банально не имеют номера, не говоря уже о переводе или установке на свой сервер. Конечно, такой подход удобен для заказчиков, которые могут увидеть все задачи в одном месте, не делая сложных поисков и не разбираясь в системе, но, как только количество открытых задач приблизится к пятистам, это, даже для заказчиков, из плюса превратится в минус.
Баг-трекер недорогой и подойти может только небольшим командам, у которых мало задач. В таком случае система будет справляться со своими обязанностями и помогать разработчикам следить за выполнением задач.
YouTrack
Интеграция с Git: есть, с помощью TeamCity
Доска: 8 (из 10) хорошая
Настраиваемые поля: 8 (из 10)
Фильтрация: 9 (из 10)
Создание задач по email: есть
Права доступа: хорошо настраиваемые
Локальная установка: да
Цена: 25 пользователей — 500 долларов в год, 50 пользователей — 750 долларов в год
Впечатления
Плюсов у YouTrack значительно больше, чем минусов. Не очень удобной кажется нумерация, так как номер задачи меняется при переносе ее в другой проект, поиск и подписка на обновления вообще требуют отдельной статьи — описать их в несколько строчек невозможно. Но с этими проблемами разобраться несложно, и сделать это должен только администратор баг-трекера, у пользователей этих проблем при правильной настройке не возникнет. Доска, как и диаграмма, очень удобные, статусы и приоритеты можно выделять так, чтобы сразу было видно то, что нужно ярко выделить, все удобно настраивается. Что также очень полезно — есть скрипт для импорта задач из большинства баг-трекеров, что сильно облегчает работу менеджера при переходе (хоть импорт и имеет свои минусы). Также минусом является отсутствие техподдержки. Если программа стоит 750 долларов, то можно как-то выделить человека, который будет отвечать на вопросы, а из помощи существует только англоязычный форум и собственно YouTrack, в котором можно создавать задачи по системе и писать о багах.
JIRA Agile
Интеграция с Git: есть
Доска: 7 (из 10) хорошая
Настраиваемые поля: 8 (из 10)
Фильтрация: 8 (из 10)
Создание задач по email: есть
Права доступа: хорошо настраиваемые
Локальная установка: да
Цена: 25 пользователей — 600 долларов в год, 50 пользователей — 1100 долларов
Впечатления
Для тестирования была выбрана не обычная версия JIRA, а JIRA Agile, имеющая доску и диаграмму для Scrum. Эта версия программы стоит дороже обычной. Баг-трекер не переведен на русский язык.
В системе очень много возможностей для настройки. Может быть, даже слишком много. По каждому проекту можно посмотреть подробную статистику, доска хорошая, но кажется менее удобной, чем в YouTrack. Что действительно удобно — сами задачи и список задач находятся в одном окне, то есть для переключения между задачами достаточно одного клика. В Assembla и YouTrack это реализовано хуже.
Можно сделать вывод: система сделана программистами для программистов, что имеет свои плюсы и минусы. К примеру, заказчик будет разбираться с системой долго, и вопросов возникнет очень много.
Targetprocess
Интеграция с Git: нет
Доска: 8 (из 10) хорошая
Настраиваемые поля: 6 (из 10)
Фильтрация: 4 (из 10)
Создание задач по email: есть
Права доступа: настраиваемые, но плохо
Локальная установка: да
Цена: 25 долларов в месяц за каждого пользователя, при локальной установке 249 долларов за каждого пользователя
Впечатления
Система очень дорогая, и тяжело понять, почему она так дорого стоит. Доска удобная, а размещение задач сделано по такому же типу, как в Trello, только более приспособлено к большим командам и большому количеству задач. Диаграмма тоже хорошая, ничего лишнего, и все понятно. Возможности по настройке полей хуже, чем у других систем. Видно, что баг-трекер хотели сделать как можно более простым и удобным, но вместо того, чтобы сделать всю функциональность как можно более простой, похоже, решили просто ее обрезать. Конечно, удобно заходить и видеть все задачи, легко переключаться между досками проектов и менять статусы, но, как только требуется сделать какие-то более сложные действия, возникают проблемы. На русский язык Targetprocess также не переведен.
Итоги
В ходе выбора нового баг-трекера было изучено пять программ. Система Trello оказалась непригодной для больших компаний и большого количества задач, система красиво выглядит и может подойти небольшим командам, но не более того. Четвертое место занял Targetprocess: система похожа на Trello, но более приспособлена для работы с большими объемами задач. Доска сделана качественно и просто, но, когда дело доходит до более тонкой настройки, появляется много сложностей и деталей, с которыми Targetprocess не справляется. Широких возможностей по настройке система не дает, а стоимость больше, чем остальных систем, что кажется необоснованным.
Популярная система JIRA с плагином Agile заняла третье место. В ней очень много возможностей для настройки, хорошая статистика по проектам, удобно смотреть задачи и неплохо реализована доска. Но разобраться в системе достаточно сложно, заказчикам изучение этого баг-трекера будет стоить немало труда, и администратору придется постоянно отвечать на возникающие вопросы. Если баг-трекером будут пользоваться только программисты, ее можно рассматривать как реальный вариант, но в компании, где половину пользователей составят заказчики, система должна быть такой, чтобы при первом входе было хотя бы приблизительно понятно, что нажимать, чтобы найти нужные задачи или создать новую.
Из всех вариантов больше всего понравились две системы: Assembla и YouTrack. Они очень отличаются друг от друга, что сильно усложнило выбор. Assembla ведет прекрасную статистику каждого пользователя, по ней можно изучать работу программистов и оценивать ее, видно все коммиты и к каким задачам они относятся. В YouTrack такого нет. Время, потраченное разработчиками на задачи, отслеживать можно, но для этого нужно заставить их писать это время в каждой задаче. Также Assembla не требует сторонних программ для интеграции с Git. YouTrack здесь отстает несильно, для него есть бесплатное приложение TeamCity, которое предоставляют разработчики, но с ним нужно будет дополнительно разбираться. Также в Assembla очень удобно следить за Stand Up отчетами разработчиков, чего вообще нет в YouTrack.
Если сравнивать качество перевода, то здесь, без сомнения, с большим отрывом выигрывает YouTrack. Баг-трекер переведен полностью и качественно (хоть перевод появился и достаточно недавно). Assembla переведена далеко не полностью, а там, где переведена, некоторые названия вызывают улыбку. Скорее всего, это временное явление и, если бы система выбиралась через полгода, возможно, этой проблемы уже бы не было. Что точно останется в ближайшем будущем, так это сложность самой системы для понимания и изучения. Если о YouTrack можно хоть что-то рассказать в нескольких словах и пользователь приблизительно поймет, как работать с системой, то с Assembla дела обстоят сложнее. Первые полчаса совершенно непонятно, что делать и что вообще происходит. Конечно, YouTrack тоже не сразу понятен, и для новых пользователей придется писать инструкцию, но он более нагляден и прост в использовании, хоть и дает меньше возможностей по администрированию. Выбирая между этими двумя системами, нужно решить, что важнее — возможность контролировать разработчиков и вести статистику их работы или, настроив систему самостоятельно и потратив на нее немало времени, получить простой в использовании и наглядный баг-трекер (где некоторые действия придется делать самостоятельно и не будет некоторых возможностей, но от постоянных вопросов по работе системы ты будешь избавлен).
После раздумий был выбран второй вариант, и первое место в обзоре систем управления проектами занял YouTrack.
4 лучших багтрекера или как QA эффективно отслеживает ошибки
Чем больше задач, проектов, клиентов, тем серьезнее встает этот вопрос: как систематизировать информацию о всех тасках и обнаруженных багах для учета рабочего времени, так называемых человеко-часов и возможности видеть картину в целом для расставления приоритетов.
В настоящее время без багтрекера невозможно представить работу как начинающего, так и опытного QA инженера. Для построения правильного процесса тестирования багтрекер просто необходим. Но как выбрать именно тот, единственный и неповторимый, который будет с тобой каждый день и с которым можно строить планы на будущее? Мы все еще о багтрекере. Так вот, чтобы помочь себе и сократить ваше время на поиски идеального багтрекера в столь изобилующем багтрекерами современном мире, мы подготовили небольшой обзор, основанный на нашем опыте и популярности систем. Мы выделим их ключевые особенности, а также в конце поделимся таблицей сравнения, которая помогла нам систематизировать багтрекеры и выбрать лучший для наших потребностей.
Redmine
Не можем умолчать тот факт, что мы сами пользуемся Redmine. Мало того что он бесплатный, но и нареканий не вызывал, и недостатков особых за 3 года использования нами обнаружено еще не было.
Bontq
YouTrack
Желаем вам выбрать вашего лучшего друга-багтрекера.
Анастасия Филатова, QA Engineer ROI4CIO
BYTEX BLOG
JIRA: ПОДРОБНОЕ РУКОВОДСТВО ДЛЯ НОВИЧКОВ
JIRA — приложение, разработанное австралийской компанией Atlassian. Его название произошло от японского слова «Gojira», что значит «Годзилла».
В основном используется для учета багов, обнаруженных в компьютерных и мобильных приложениях. Панель управления JIRA предоставляет множество полезных возможностей и функций, позволяющих легко собрать и упорядочить все найденные проблемы. Ряд из них мы рассмотрим ниже.
1. Система JIRA
JIRA состоит из ряда компонентов, каждый из которых можно настроить. Это:
2. Задачи JIRA и их типы
JIRA позволяет отслеживать баги и задачи, лежащие в основе проекта. Как только вы импортируете проект в JIRA, вы можете создавать задачи.
Во вкладке «Задачи» (Issues) можно обнаружить следующие функции:
9
Типы задач (Issue Types)
Во вкладке «Типы задач» отображены все типы задач, которые можно создавать и отслеживать в JIRA. Как можно увидеть на скриншоте, задачи классифицируются различными видами функций, подзадач, багов и т.д.
В JIRA есть две системы организации типов задач.
Стандартная система организации типов задач (Default Issue Type Scheme).
В стандартной системе организации типов задач все новые созданные задачи автоматически добавляются на схему.
Agile Scrum система организации типов задач (Agile Scrum Issue Type Scheme).
Задачи и проекты, которые ассоциируются с Agile Scrum, используют эту систему.
Помимо этих двух схем вы можете создавать собственные типы задач, настраивая функционал под себя. Например, мы можем создать схему IT и Поддержка (IT & Support), перетащив типы задач из вкладки «Доступные типы задач» (Available Issue type) на вкладку «Типы задач для текущей схемы» (Issue type for current scheme), как показано на скриншоте ниже.
3. Компоненты JIRA
Компоненты — это подразделы проекта. Они используются, чтобы комбинировать задачи текущего проекта в малых разделах. Компоненты добавляют проекту структурированность, разбивая его на функции, группы, модули, подпроекты и прочее. Используя компоненты, вы можете генерировать отчеты, собирать статистику, отображать ее на панелях управления.
Как показано на скриншоте, вы можете добавлять новые компоненты, такие как Название (Name), Описание (Description), Руководитель отдела/команды (Component lead) и Назначенный ответственным по умолчанию (Default assignee).
4. Окна JIRA (JIRA screen)
Если задача создана в JIRA, она будет организована и представлена на различных рабочих пространствах, которые называются экранами. Эти рабочие пространства могут переводиться и редактироваться в ходе рабочего процесса. Как можно увидеть на скриншоте, каждой задаче вы можете назначить тип экрана. Чтобы ассоциировать осуществление задачи с определенным экраном, нужно зайти в главное меню, кликнуть Задачи (Issues), кликнуть Схемы (Schemes), после этого кликнуть Ассоциировать осуществление задачи с экраном (Associate an issue operation with a screen) и добавить экран, соответствующий требованиям.
5. Свойства задач (Issue Attributes)
5. Свойства задач (Issue Attributes) В свойства задач входят:
Различные статусы используются, чтобы обозначить прогресс проекта: Ожидает выполнения (To do), Выполняется (InProgress), Открыт (Open), Закрыт (Closed), Переоткрыт (ReOpened), Решен (Resolved). Также имеются решения и приоритеты. Решения обозначают прогресс выполнения задачи: Исправлено (Fixed), Не будет исправлено (Won’t fix), Дубликат (Duplicate), Не завершено (Incomplete), Не воспроизводится (Cannot reproduce), Выполнено (Done). Также вы можете указать приоритеты задач: Критический (Critical), Высокий (Major), Малозначимый (Minor), Блокирующий (Blocker) и Тривиальный (Trivial).
6. Схемы защиты задач JIRA (Issue Security Schemes)
Эта функция JIRA позволяет вам контролировать доступ к задачам. Она включает в себя несколько уровней доступа, которые распределяются между пользователями и группами. Вы можете указать уровень доступа к задачи во время ее создания или редактирования.
Также имеется Стандартная схема защиты (Default Permission Scheme), которая будет назначена любому новому проекту. Схемы защиты позволяют вам создавать наборы уровней доступа и применять их к любому проекту.
Системная администрация (System Administration)
Вот несколько полезных функций, которые JIRA предоставляет администраторам:
Логи ревизий (Audit Log). В этой вкладке вы можете увидеть детали созданной задачи, а также изменения, внесенные в задачу.
Связывание задач (Issue Linking). Здесь указывается связана ли ваша задача с какой-то другой, существующей в данном проекте. Также в этой панели можно отменить данную связь.
Система почты JIRA (Mail in JIRA). Используя систему почты в качестве администратора, вы можете пересылать задачи на почтовые сервера POP и IMAP, а также отправлять их в виде сообщений на внешние почтовые ящики.
События (Events). В этой вкладке описан статус, стандартный шаблон, схемы оповещения и передача ответственности за событие. События разделены на два типа: Системные события (System event, те, что установлены в JIRA по умолчанию) и Пользовательские события (Custom event, соответственно, те, что были созданы пользователями).
Контрольный список (Watch list). Позволяет просматривать определенные задачи, видя уведомления, связанные с ними. Чтобы просмотреть задачу, кликните «просмотр» в окне задачи, а если вы хотите увидеть, кто еще просматривает эту задачу, вы можете нажать на число в скобках.
Счетчик задач (Issue Collectors). Позволяет собирать информацию с любого сайта. Будучи администратором, можно кликнуть по счетчику задач, после чего появится опция, позволяющая его добавить. Как только вы настроите внешний вид счетчика, автоматически сгенерированный JavaScript можно перенести на сайт для передачи информации.
Инструменты разработки (Development Tools). Вы можете также подключить ваши инструменты разработки ПО к JIRA, используя функции администратора. Вам необходимо ввести URL приложения для подключения его к JIRA.
7. Как создать задачу в JIRA (How to create an issue in JIRA)
Панель задач JIRA откроется, как только вы введете свой ID и пароль. Под панелью управления вы обнаружите вкладку Проекты (Project). Кликнув по ней, вы откроете окно со списком таких опций, как Простое отслеживание задач (Simple Issue Tracking), Управление проектами (Project Management), Agile Kanban, Классическая JIRA (Jira Classic), соответственно скриншоту.
Если вы кликните по опции Простое отслеживание задач (Simple Issue Tracking), откроется другое окно, в котором упоминаются детали задачи, а также назначение определенному ответственному лицу.
После нажатия кнопки Подтвердить (Submit) откроется окно, в котором можно выполнить ряд действий, вроде создания и назначения задач, проверок их статуса и т. д.
Как вы можете увидеть на скриншоте ниже, когда вы завершите создание задачи, на экране появится всплывающее окно с оповещением о том, что задача успешно создана.
Теперь, если вы захотите отредактировать задачу или экспортировать ее в виде XML/Word документа, вы можете навести курсор на главную панель и кликнуть Задачи (Issues). В появившемся списке выберите Поиск задач (Search for issues), после чего откроется окно, с помощью которого вы можете обнаружить ваши задачи и выполнить другие действия.
Когда вы выберете Поиск задач (search for Issues), откроется такое же окно, как на скриншоте ниже.
В этом же окне вы можете установить фильтр для задачи и сохранить его в Избранные фильтры (Favorite Filters), так что если вам потребуется найти данную задачу, вы легко сможете сделать это, воспользовавшись фильтром.
Воспользовавшись функцией Сводка (Summary), вы откроете окно с диаграммой, на которой можно увидеть все детали, связанные с вашим проектом, и прогресс работы над ним. В правой части окна сводки вы можете увидеть Журнал активности (Activity Stream), на котором отображаются детали, связанные с задачей, и комментарии, оставленные ответственным за задачу человеком.
Подзадача (Sub-Task)
Небольшие подзадачи полезны, когда нужно разбить основную задачу на ряд отдельных, которые точно так же могут быть отслежены. Это позволяет всесторонне подойти к основной задаче, распределяя нагрузку между несколькими работниками.
Как создать подзадачу
Подзадача может быть создана двумя способами:
Чтобы создать подзадачу в JIRA, вам нужно выбрать задачу, к которой вы хотите ее прикрепить. В окне задачи выберите опцию Назначения. Прочее (Assign more), после этого выберите Создать подзадачу (Create sub-task), как показано на скриншоте. Вы можете также конвертировать задачу в подзадачу (convert to sub-task), выбрав соответствующую опцию.
Выбрав опцию Создать подзадачу (Create sub-task), вы откроете соответствующее окно. Заполните поля с деталями, касающимися данной задачи, и нажмите кнопку Создать (Create), как показано на скриншоте ниже.
Таким образом вы создадите подзадачу, прикрепленную к основной задаче, а на странице подзадач вы сможете увидеть время, отведенное на ее выполнение.
Несколько важных вещей, которые нужно помнить, создавая подзадачи:
Рабочий процесс (WorkFlow)
Рабочий процесс в JIRA представляет из себя набор статусов и переходов, через которые проходит задача во время своего жизненного цикла. Он может включать в себя пять основных стадий:
Рабочий процесс JIRA состоит из статусов (statuses), переходов (transitions), назначений (assignee), решений (resolution), условий (conditions), проверок (validators), и свойств (properties).
Статусы определяют статусы задач во время рабочего процесса.
Переходы подразумевают под собой процесс смены статуса.
Назначения указывают ответственных за определенные задачи и определяют пути решения задачи.
Решения объясняют, по какой причине задача может считаться закрытой.
Условия контролируют доступ к переходам.
Проверки позволяют убедиться, что переход может быть произведен соответственно статусу задачи.
Свойства определяются JIRA при переходах.
Вы можете назначить статус задаче в соответствующем ей окне, кликнув на флажок статуса В работе (IN Progress), как показано на скриншоте ниже. Это отобразит статус задачи на ее рабочей панели, выделив его желтым цветом.
Для созданной нами задачи JIRA отобразит таблицу рабочего процесса, на которой указан путь, пройденный задачей во время работы над проектом. Все статусы, которые мы устанавливали для задачи, отображаются на таблице. Как показано на скриншоте, в нашей таблице появился ряд статусов, а статус «В работе» (IN Progress), который является текущим, выделен желтым цветом. Таблица рабочего процесса дает возможность быстро просмотреть, через какие стадии прошла задача.
Плагины JIRA (Plug-ins in JIRA)
Для JIRA существует множество плагинов, позволяющих вам эффективнее работать. Это такие плагины, как Zendesk, Salesforce, GitHub, Gitbucket и т. д. Часть из них позволяет команде поддержки отчитываться о работе напрямую в JIRA, создавать неограниченные приватные репозитории с полной поддержкой задач, инструментов управления тестированием и т. д.
JIRA Agile (JIRA Agile)
Agile метод в основном используется командами разработчиков, которые пользуются концепцией «дорожная карта» (roadmap), подразумевающей под собой последовательный переход между запланированными функциями в процессе разработки новых версий продукта. Agile следует той же «дорожной карте», что и другие проекты в JIRA «Ожидает выполнения — В работе — Завершено» (To do — In Progress — Done). Как вы можете увидеть на скриншоте ниже, у нас есть одна задача со статусом «Ожидает выполнения» и вторая со статусом «В работе». Как только задача «В работе» будет решена, ее статус изменится на «Завершено», и точно так же задача «Ожидает выполнения» получит статус «В работе».
Создание задачи в Agile
Чтобы создать agile-задачу, перейдите в главное меню на вкладке «Agile», нажмите «Начать работу» (Getting Started), после чего вас попросят выбрать, какой использовать метод управления: «Scrum» или «Kanban». Вы можете выбрать одну из опций в зависимости от ваших требований. В данном примере мы выбрали «Scrum».
Создания Эпика в Agile
Эпик (Epic) — способ описания требований к разрабатываемой системе, представляющий из себя большую user story («пользовательскую историю»), которая может состоять из нескольких меньших. В JIRA эпик представляет из себя еще один тип задач, охватывающий огромный объем работы. Для завершения эпика потребуется несколько спринтов (sprint — список работ на ближайший отчетный период, который команда определила и согласовала с владельцем продукта). Вы можете либо создать новый эпик в Agile, либо использовать задачу, которую вы создали на обычной рабочей панели JIRA. Точно так же вы можете создать пользовательскую историю для agile scrum.
Режим планирования (Plan Mode) в Agile:
Режим планирования отображает все пользовательские истории, созданные для проекта. Вы можете воспользоваться меню, расположенным с левой стороны, чтобы определить условия, согласно которым будут отображаться задачи. С правой стороны расположено меню, с помощью которого вы можете создавать задачи, логи и т.д.
Режим работы (Work Mode) в Agile:
Отображает информацию о текущем спринте. Все задачи и истории пользователя разделены на те же три категории «Ожидает выполнения», «В работе», «Завершено», отображающие прогресс работы над проектом или задачами.
Связывание и клонирование (Clone and Link) задач в JIRA
В JIRA вы также можете клонировать задачу. Преимущество этой функции в том, что над задачей сможет отдельно работать другая команда, позволяя решить задачу быстрее.
Помимо этого в JIRA есть такая полезная функция, как «Связывание» (Link). Связывание задач, что понятно из названия, позволяет создавать связи между существующими задачами на этом же или другом сервере JIRA. Как показано на скриншоте, мы связали задачу «ST-6 Выпадающее меню не работает» (ST-6 Drop down menu is not working) с другой «ST-4 Интерфейс не работает — необходим ретест функционала интерфейса» (ST-4 GUI is not responsive- retest GUI functions).
Создав данную связь, мы запустили однодневный спринт, который будет продолжаться определенный период времени, как можно увидеть на скриншоте ниже. Если вы работаете со «scrum» и хотите изменить приоритет или ранг задачи, вы просто можете перетащить ее в бэклог (backlog — журнал оставшейся работы, которую необходимо выполнить команде).
Помимо этого здесь же есть еще множество возможностей, которыми можно воспользоваться. Например, если вы кликните по иконке в верхнем правом углу окна, появится выпадающий список с функциями, которые вы можете применить при необходимости.
8. Отчеты (Reports) в JIRA
Для отслеживания прогресса в Agile существует диаграмма сгорания задач (Burndown Chart), отображающая выполненный и запланированный объем работы, необходимый для завершения спринта. Типичная диаграмма будет выглядеть примерно так же, как на скриншоте ниже. Красная линия отображает фактический объем выполненной работы, в то время как синяя отображает идеальный объем выполненной на протяжении scrum-цикла работы.
Помимо диаграммы сгорания задач в JIRA существует множество других опций: Отчет по спринту (Sprint Report), Отчет по эпику (Epic Report), Отчет по версиям (Version Report), Диаграмма производительности (Velocity Chart), Диаграмма управления (Control Chart), Диаграмма совокупного потока (Cumulative flow diagram). Вы можете использовать разные способы отслеживания прогресса работы над вашим проектом.
Как вы можете увидеть на скриншоте ниже, мы выбрали круговую диаграмму для отображения задач по приоритетам. На ней в процентном формате отображена статистика по задачам, включающая в себя их количество и важность. Круговая диаграмма может быть использована для отображения различных типов данных: Назначения (Assignee), Компоненты (Components), Типы задач (Issue Type), Приоритеты (Priority), Решения (Resolution), Статусы (Status) и т. д.
Вы также можете настроить то, как будет отображаться рабочая панель Scrum — для этого имеется множество опций. Элементы Scrum, которые можно настроить подобным образом, включают в себя: колонки (Columns), Swim Lane блок-схемы, быстрые фильтры (Quick Filters), цвета элементов (Card colors) и т. д. Здесь, например, мы выбрали управление колонками, а для типа отображаемой информации указали «Подсчет задач» (Issue count), что позволило нам увидеть точное число задач, находящихся в процессе выполнения, выполненных и ожидающих выполнения. Помимо этого можно выбрать множество других типов колонок, которые будут отображать ту информацию, которая вам необходима.
Фильтры (Filters)
Вы можете создавать свои фильтры в придачу к установленным по умолчанию. Фильтры могут быть по данным (date), компонентам (component), приоритетам (priority), решениям (resolution) и т.д.
Kanban-панели и управление задачами
Точно так же, как с панелью Agile Scrum, мы можем создать Kanban-панель. В данном примере мы создали проект под названием «Облачное тестирование» (Cloud Testing). Kanban-панель полезна для управления и ограничения находящейся в процессе выполнения работы. Kanban-панели отображаются в режиме работы, но не в режиме планирования.
Так мы создали две задачи на Kanban-панели: «Баг, обнаруженный во время нагрузочного тестирования» (Bug detected while load testing) и «Проверить задачи, относящиеся к облачному серверу» (Check issues related to cloud server).
Kanban считается лучшим методом для работы с багами и поддержки релизов, когда новые задачи соответственно приоритезируются и обрабатываются. Есть несколько способов повысить эффективность вашей работы в Kanban:
Сравнение JIRA Scrum и JIRA Kanban