JIRA. Создаем проект, с чего начать?

Казалось бы. при чем тут тестирование?

А с другой стороны, почему бы и нет? Тестировщик вполне может быть админом JIRA или любого другого инструмента для ведения ошибок. Ведь это место (скопление багов) - наша стихия. Конечно же, мы хотим уметь настраивать ее под себя.

Чем мы с Вами и займемся. Показывать администрирование я буду на примере облачной JIRA, поэтому, если у Вас она обычная - может быть немного другой вид. Но это ничего, принцип не меняется.

Итак, поехали! Для начала нам нужен проект. Где его создавать? В админке. Переходим туда. Справа в верхнем углу экрана, справа от строки поиска и слева от нашей аватарки есть такая шестереночка - нажимаем на нее и выбираем вход в админку.

Открывается примерно такой вид.

То есть общее число проектов, возможность перейти на один из них и далее длинный список всяких вкусностей, которые мы можем менять и настраивать. Но этот список нас пока не интересует, нам нужна кнопка "Add Project" - "Добавить новый проект".

Вводим название нового проекта, а нам система предлагает возможное сокращение. Вторая строка, Key - это то краткое название, которое будет преследовать Вас на протяжении всего проекта.

Дело в том, что, когда мы заводим баги / таски / истории / улучшения / итд - у нас генерируется номер задачи по принципу Key-{increment}, то есть Key-1, Key-2 и так далее по возрастанию...

Нас может не устраивать предложенное системой сокращение, давайте поменяем его на TEST.

Сохраняем проект и попадаем на страничку его администрирования и настроек.

Что нам здесь может пригодиться? Ну, во-первых, версии.
Добавляем версии.

Какие версии... Ну, разумеется, версия "1.0", наш первый релиз. А остальное... Остальное в backlog! Следующее, что нам нужно - компоненты. А вот и они, смотрите, рядом с версиями, для Вашего удобства

Компоненты...

Компоненты - это то, по чему можно будет сортировать список задач. Например, перед созданием новой ошибки признаком хорошего тона является проверка того, а не создана ли она была до Вас Вашим коллегой? Хорошо, если у Вас всего 10 открытых задачек. Просмотрели все. А если их 100 ? Уже посложнее задачка.

Но если Вы знаете компонент, всегда можно сделать сортировку по нему - а сколько по данному компоненту было поставлено баг? Кем? Какого приоритета? Сколько открытых? И прочее...

Добавим какие-нибудь стандартные компоненты...
Так! Теперь нам надо создать задачу! Как это сделать? А вот она - кнопочка сверху - "Create Issue". Несмотря на то, что мы находимся в режиме администратора, мы легко можем переключиться на простой пользовательский режим, что мы и делаем.

При создании задачи вначале необходимо определиться, какой у нее тип.

Ну, багов в нашем тестовом проекте пока нет, создадим простую задачу.

Заполняем ее поля.

• Summary - Название. Краткое описание задачи. Обязательное.
• Priority - Приоритет. Обычно Major, если более высокий, есть дефолтные значения "Критичный таск" и "Блокер", а также более низкие - "Минорная задача" или даже "Тривиальная".
• Component/s - Выпадающий список из только что добавленных компонентов. Выбрать можно как один, так и несколько (например, "формочка 1" + "отчеты" или "логи" или что-то еще...). Поле по дефолту обязательное, если мы добавили компоненты в проект. Иначе пустое.
• Affects Version/s - Выпадающий список из только что добавленных версий. Выбрать можно как один, так и несколько (например, "релиз 1.0" + "поддержка". Необязательное.
• Reporter - Автор задачи. По умолчанию тот, под кем мы залогинены. 
• Environment - Окружение, на котором найдена ошибка. Можно оставлять пустым, принимая за основное какое-то одно окружение, например, тестовый стенд. Тогда поле заполняется, только если бага была найдена на другом окружении, например, интеграционном.
• Description - Описание ошибки / задачи.

Пока хватит. Заполнили поля и создали задачу - снизу кнопочка "Create" и-и-и-и... Упс, ошибочка вышла...

Возвращаемся в админку. Под разделом "Компоненты" есть раздел "Роли". Видим там, что "Ольга Киселева" является Project Lead проекта, а Default Assignee (у которого, судя по ошибке, нет прав) - как раз Project Lead.

Ладно, смотрим еще ниже, под ролями у нас есть раздел с правами доступа. Смотрим, что за дефолтная схема у нас подключена.

Открывается примерно такой экран.

Находим там Assignable Issues (пользователь, на которого можно назначать задачки)- ага, дефолтный Assignable Issues должен входить в группу разработки, куда я не вхожу.

Давайте это исправим.
Поднимаемся выше - Actions - Edit permissions.

Теперь мы можем добавить новых людей в права доступа по каждому действию, или наоборот, удалить их оттуда.

Мы хотим добавить - Add.
Настройка очень гибкая - можно добавить права одному пользователю, какой-то группе пользователей, вообще всем, автору задачи и прочее, прочее. Да пусть можно будет всем назначать!

Возвращаемся в нашу задачу и снова пробуем сохранить. На этот раз у нас появилось новое поле - тот самый Assigner! Но оно не заполнено...

Возвращаемся в админку. Заходим в роли.

И записываем в колонку Users логины пользователей, входящих в данную группу.

Ольга Киселева будет администратором, пишем ее логин

Нажимаем Enter. Система нашла логин и подставила ФИО!

Добавим еще, пожалуй, пару пользователей и хватит. Нажимаем Update, сохраняя изменения и снова возвращаемся к задаче. Нажимаем Create... И вот она, наша первая задача!

Итого, создавая проект, создаем:

• Версии (базовый комплект)
• Компоненты (базовый комплект)
• Роли (распределение)
• Permissions (хотя бы Assignable Issues)