Jira

1. JIRA

2. Что такое Jira?

Это небо, плачущее небо под ногами
Jira – многофункциональная система для отслеживания багов, организации задач и управления проектами
Основные преимущества Jira:
• Работает из веба
• Может базироваться как на локальных серверах компании, так и удалённо
• Имеет обширную функциональность для отслеживания и контроля выполнения задач
• Интегрируется с другими инструментами, упрощающими разработку

3. Разделение на проекты

Проектов сотни, JIRA - одна
Мир Кораблей работает в этом проекте:

4. Интеграция с Confluence, Bitbucket, Testrail

Осталось только добавить монитор.
Невероятно полезные инструменты для
разработки и тестирования, о которых
вам ещё расскажут!

5. JIRA

6. Основные поля

Summary
Priority
Reproducibility
Severity
Component
Affected/Fix Versions
Assignee
Environment
Description
Phase
Specification
Да-да. Придётся довольно много нажимать на
большую красную темно-серую кнопку.

7. Создание/Заведение бага

8. Поле Summary

Это очень важное поле, тут не будет шутки, потому что, если оно заполнено плохо, то тут не до шуток.
Summary (Название) – атрибут, содержащий краткое описание того что произошло
Основная роль этого поля – объяснить суть дефекта за одно предложение. Хорошее название часто
позволяет заинтересованным лицам даже не открывать описание чтобы понять, что случилось. Это
экономит много времени тем, кто не собирается вникать в детали/технические аспекты бага.

9. Поле Summary

Это очень важное поле, тут не будет шутки, потому что, если оно заполнено плохо, то тут не до шуток.
Принцип «Что? Где? Когда?»
(Что происходит?) +
(Где происходит?) +
(Всё остальное)

10. Поле Summary

Теги
В проекте «Мир Кораблей» в поле Summary также пишется тег, указывающий на ветку где возник
дефект, либо явный компонент:
• Для дефектов найденных на разных этапах проставляются теги. Например: [Regression_0.X.X],
[Release_0.X.X], master
• Для специфических компонентов также добавляются теги. Например: [Steam], [Ship_ID], [Map_ID],
[MemLeaks] и так далее
• Для дефектов с разных веток также используются свои теги, иногда даже несколько.

11. Priority

Теги
Атрибут, описывающий насколько срочно требуется починить дефект

12. Reproducibility & Severity

Reproducibility & Severity
Поля, описывающие частоту воспроизведения и влияние дефекта на работоспособность приложения
соответственно
Reproducibility
Как часто воспроизводится баг?
Severity
Насколько критична проблема с точки зрения
пользователя?

13. Component

В этом поле указываются одна или несколько подсистем, затронутых дефектом
Компоненты используются для категоризации и автоматического назначения ответственного за дефект.
Например:
На все дефекты с компонентом Tech:Bugs ответственным (Assignee) назначается Владислав
Свешников – Tech&Tools QA Team Lead, если при создании бага не указано иное.
А задача с компонентом Tech упадёт на Владислава Гордиенко – тимлида всего Tech отдела.
Также компоненты могут использоваться для нотификаций:
Можно подписаться на несколько компонентов, тогда на почту будут приходить нотификации обо всех
изменениях в issue, с определённым компонентом.

14. Affected Version/Fix Version

Версия, в которой появился/обнаружен дефект/в которой дефект должен быть починен
Affected Version = 25.1 – означает, что баг был обнаружен в версии 25.1
Fix Version = 13.10 – означает, что баг был/должен быть починен в версии 13.10
Fix Version = backlog – означает, что баг будет починен когда-нибудь в прекрасных кораблях будущего.

15. Assignee

Assignee – атрибут, указывающий на ответственного за дефект. По факту – текущего исполнителя задачи
Если при тестировании фичи обнаружился баг, то при его заведении в Jira в большинстве случаев стоит
выбирать Assignee конкретного программиста, который писал фичу.
В процессе работы над багом Assignee меняется.
Например: Программист подготовил фикс и перевёл багу в Ready For Testing – в этом случае Assignee
становится заводивший баг QA, который будет проверять фикс. Таким образом в задаче всегда указан
человек, который непосредственно работает над задачей.

16. Environment

Окружение, на котором воспроизвёлся баг
Обычно оформляется так: [Название ветки]+[Хэш коммита] на котором найден дефект

17. Phase

Фаза разработки, во время которой был обнаружен дефект. Используется главным образом для сбора
статистики по обнаружению дефектов
Дефект найден во время разработки фичи:
Phase = Development
Дефект найден во время регрессионного тестирования/стабилизации/на основной ветке master:
Phase = Stabilization
Дефект зарепорчен участником супер-теста в процессе ST на ветке стабилизации regression/…
Phase = External Test: Super Test
Дефект найден во время паблик-теста разработчиком или участником:
Phase = External Test: Public Test
Дефект найден на релизной версии/ Дефект найден после срезки релиз-кандидата rc/... на этапе pre-prod'а
Phase = Production

18. Specification

Поле, в котором кратко описывается информация об исправлении дефекта, значимости этой задачи для
пользователя и источнике возникновения дефекта
Tech – описание технического аспекта
фикса.
User – значимость исправления для
пользователя. Используется для
составления патчноутов.
Source – указание на источник
возникновения дефекта (в рамках какой
задачи мог возникнуть дефект).
Ошибок в заполнении этого поля было настолько много, что вот
ссылка на документацию специально для него:
https://confluence.lesta.group/pages/viewpage.action?pageId=2164541806

19. Labels & Documentation Link

Labels & Documentation Link
Labels – они же лейблы. Нужны для упрощения поиска задач относящихся к определенному и
указанному лейблом подразделу. Служат для фильтрации тасок.
Documentation Link – она же дока или документация. Нужна для более подробного и более детального
описания фичи.

20. Description

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

21. Description

Шаги для воспроизведения, ожидаемый результат, фактический результат
Шаблон, подходящий для подавляющего большинства багов:
Шаги для воспроизведения
1) [Действие 1]
2) [Действие 2]
3) [Действие 3]
Фактический результат
[То, что происходит в результате выполненных действий вопреки документации, требованиям заказчика фичи и,
конечно же, здравому смыслу]
Ожидаемый результат
[То, что должно происходить в результате выполненных действий в соответствии с документацией, требованиями
заказчика фичи и, конечно же, здравым смыслом]

22. Description

Общие советы по оформлению и форматированию

23. Description. Attachments

Шаги для воспроизведения, ожидаемый результат, фактический результат
Если дефект заключается в падении клиента, или требуется вставить большой кусок кода, логов,
callstack и другие подобные вещи, стоит воспользоваться элементом вставки кода – так текст будет
занимать меньше места и станет более читаемым:

24. Description

Любые файлы (логи, скриншоты, видео, дампы и так далее) можно прикрепить к issue, просто
перетащив их на экран создания issue.

25. Description

Главное правило при оформлении любой issue:
Уважайте чужое время.

26. Test Report

Подробный Test Report помогает оценить полноту тестирования задачи
Test Report составляется по результатам проверки задачи/дефекта
В комментариях к задаче указывается:
Окружение – Ветка + hash коммита, на которых были осуществлены проверки
Статус – Дефект исправлен/не исправлен
Проверки – Список проверок смежных областей, если нужно
Тест-кейс – Создан или обновлён тест-кейс, если нужно

27. Issue & Workflow

Issue &
Workflow

28. Статусы: NEW & OPEN

Статусы: NEW & OPEN
Любая новая issue по умолчанию принимает статус New
Статус New означает что задача создана, но ей пока никто не занимается.
Статус Open означает что задачу видели, знают о ней и, возможно, скоро
приступят

29. Статусы: In Progress & Resolved

Статусы: In Progress & Resolved
Названия говорят сами за себя
Статус In Progress означает что задача находится в работе, ответственный (Assignee)
уже приступил к её выполнению.
Статус Resolved означает что основная часть работы со стороны Assignee выполнена –
задача ожидает code review или необходимых аппрувов, может перемещаться к
следующему статусу и Assignee.

30. Статусы: Ready For Testing & In Testing

Статусы: Ready For Testing & In Testing
Статус Ready For Testing означает, что задача готова к тестированию: все необходимые
процедуры (например согласования как всё должно выглядеть и работать) пройдены,
code-review окончен. На этом этапе задача ожидает смены Assignee на ответственного за
тестирование QA.
Статус In Testing означает, что ответственный QA проводит необходимые проверки.

31. Статусы: Need More Info & Canceled

Статусы: Need More Info & Canceled
«Гладко было на бумаге, да забыли про овраги…»
Статус Need More Info выставляется, если во время тестирования задачи были
выявлены недочёты/баги или возникли дополнительные вопросы в духе: «А так
вообще должно быть?» В случае выставления статуса Need More Info, ответственный
QA перевешивает задачу назад на человека, занимавшейся ей до статуса Resolved
чтобы он ответил на вопросы и/или починил баги.
Статус Canceled означает, что на одном из этапов работы над задачей стало понятно,
что по каким-то причинам не стоит ей заниматься, а выполнять её вовсе никто не
будет.

32. Статусы: Ready For Integration, Closed, Reopened

Вчерашний день — это история. Завтрашний — загадка. Сегодняшний — подарок.
Статус Ready For Integration означает, что все проверки требуемые в проекте
перед интеграцией (заливкой фичи/фикса в основную ветку разработки) закончены.
Статус Closed означает, что все работы над задачей закончены.
Статус Reopened означает, что к задаче по какой-то причине было решено
вернуться. Например, если обнаружилось что баг не пофикшен и/или что-то ещё
нужно исследовать или переделывать.

33. Jira Issue

Issue – кирпичик любого проекта и основная сущность, с которой взаимодействует пользователь Jira
Jira issue могут иметь разные типы:
• Bug
• Task
• Sub-Task
• Epic Story
• User Story
• Improvement
Главное, что стоит понять сейчас: Видишь багу? Это issue. Эпик? Тоже issue. Кто-то ругается в
комментах в жире? Это происходит внутри issue. Одумайся, возможно весь мир – одна
большая незакрытая issue.

34. WORKFLOW: BUG

35. Task

aka таска, тасочка, задача, ишью, тикет
Универсальный тип issue, который может использоваться как отдельно для выполнения
какой-либо задачи, так и как вспомогательная issue, слинкованная к импрувменту/или эпику.
Таски не обязательно связаны с разработкой

36. Связи между задачами

Child task, included task, related task
1) При заведении нового бага находим поле «Linked Issues»
2) В выпадающем меню выбираем is child task of
3) В поле «issue» чуть ниже находим нужный импрув, к которому относится баг.

37. Improvement

Когда изменений не так много
Тип задачи Improvement используется при
добавлении фичи с небольшим объёмом
изменений и не затрагивающей несколько
систем.
Improvement может включать в себя несколько
подзадач. Например: если необходимо
дополнительное performance-тестирование,
создаётся отдельная issue типа Task.
В случае, если в процессе тестирования
импрува находятся дефекты, они заводятся
отдельной issue, которая прикрепляется к
issue импрува как дочерняя.
На скриншотах пример задач типа Improvement: объём
изменений небольшой – апскейлер является достаточно
изолированной системой рендера – отличный кандидат
на то, чтобы стать импрувом!

38. WORKFLOW: Improvement

39. Epic Story

Эпичные истории ещё никогда не были такими эпичными!
Issue типа Epic Story используются тогда, когда готовятся большие изменения, которые могут
затронуть много подсистем, отделов разработки и просто включают в себя много всего.
В проекте WOWS PC к Epic Story линкуются все относящиеся к ней задачи.
Подлодки это действительно эпичная история

40. WORKFLOW: EPIC

41. Move

Я там таску в RFT перевел, но правда там Diff не открывается
При надобности любую issue можно переделать в issue другого типа. Для
этого нужно нажать Move в меню под названием задачи. Затем Jira
вежливо спросит в задачу какого типа вы хотите переделать текущую
issue и попросит заполнить недостающую для нового типа информацию,
если таковая имеется.

42. Итак, Вы нашли дефект. Что делать?

Или пособие по жестокому обращению с багами
Стоит задать себе несколько вопросов:
1) Какие подсистемы он затрагивает?
2) Относится ли он к проверяемой ветке?
3) В следствие чего, примерно, появился дефект?
4) Кто его должен чинить?
5) Заведён ли уже этот дефект?
Ответив на эти вопросы уже станет понятно как заполнять большую часть полей в при
заведении дефекта в Jira, а главное – стоит ли вообще заводить дефект (например если он
уже заведён на основную ветку разработки).

43. А как искать?

А главное что искать?
Использовать форму поиска!
Project – проект к которому относится искомая issue
Type – тип искомой issue
Status – статус искомой issue
Assignee – текущий assignee искомой issue
Пустое поле для ввода – текст, который должен содержаться в искомой issue

44. Расширенный поиск

Нам понадобится:
project = WWSD AND issuetype = Bug AND reporter in (v_sveshnikov) AND status not in (Closed) and
description ~ "visibilityFlags"
Расширенный поиск – полезная штука, если знать как ей пользоваться. Для написания
запросов расширенного поиска используется JQL (Jira Query Language). Справку по
использованию JQL всегда можно открыть по нажатию на знак вопроса в конце поисковой
строки.
Расширенный поиск позволяет писать сложные условия для поисковых запросов, позволяя
быстро находить то, ради чего в basic строке поиска пришлось бы сперва посмотреть пару
десятков issue.
Также запросы расширенного поиска можно сохранять, тогда они станут доступны в боковой
панельке:

45. Терминология проекта

Трудности перевода
При поиске багов часто можно столкнуться с неочевидной проблемой: многие названия фич/юайных
элементов в разных командах могут называться по-разному. И даже для такие распространённых
определений всё равно случаются вариации: падение, краш, вылет. Поэтому при поиске уже
заведённых дефектов стоит попробовать несколько вариантов нужных элементов.
Меташоп, адмиралтейство, арсенал, миллиардер, плейбой,
филантроп.

46. Нотификации в почте

Нет, это не спам. Почти всегда.
Как уже упоминалось ранее – Jira отправляет нотификации о созданиях/изменениях в задачах по
компонентам, выставленных в них. Если Вы хотите подписаться на какой-то определённый компонент –
попросите своего непосредственного руководителя, и он добавит Вас в настройках рассылок.
Так же у каждой issue есть графа «Watchers». Добавив себя в вотчеры, Вы также подпишетесь на
оповещения обо всех обновлениях issue.

47. Dashboard

Мишборд, Сашборд.
Dashboard – удобный способ представления различных Jira issue и страниц с других интегрируемых
сервисов (Confluence, BB) на одном экране.
По умолчанию в Jira настроен System Dashboard. При желании можно настроить себе дополнительный:

48. Board

Теперь без dash.
Boards – способ представления issue, предоставляющие
гибкий способ для просмотра, управления и отчёта о
прогрессе задач. Доски в Jira делятся на три типа:
Kanban board
Scrum board
Team-managed board