Уровень 6             Баг трекинговые системы

Добро пожаловать в ледяную планету Хот! Пройдя ее суровые испытания, ты научишься работать в команде с другмими IT специальностями. И в этом тебе поможет баг трекинговая система. 

Каждый тестировщик, компания которого больше 2 человек, работает с баг трекинговой системой. Давай разберемся, что это за система на примере JIRA.

Насколько мне известно, под баг трекинговой системой обычно понимают прикладную программу, разработанную с целью:

- помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки и неполадки, найденные в программах,

- осуществлять поддержку пользователей,

- следить за процессом устранения этих ошибок и выполнением или невыполнением любых  IT процессов.

- Почему же мы используем в качестве примера Jira? Потому, что она лучше?

- Однозначно сказать невозможно.

- Может потому, что автор пользовался ею на момент создания уровня? 

- Кто знает ... Он и  Redmine в свое время много использовал.

 

Скажем так, Jira - более распространенная баг трекинговая система, чем остальные, но при этом она не занимает абсолютно лидирующей позиции. Jira  активно развивается, постоянно добавляет новые модули,  так как это платный проект, в отличие от медленно текущих Open Sourse  проектов. Важно понять одно - все баг трекинговые системы схожи и, умея работать в одной из них, вам хватит нескольких часов, чтобы разобраться в любой другой.

Что есть в JIRA?

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

Структура проектов
  • Позволяет вам назначать, выставлять приоритеты, отслеживать, создавать отчёты, обрабатывать и мониторить «баги»

 

  • Расширенная платформа, которая настраивается под конкретные бизнес-процессы

 

  • Повышает продуктивность за счёт сокращения потерь времени, связанных с отслеживанием хода решения проблем и координации

 

  • Повышает качество исполнения за счёт того, что ход исполнения всех задач записывается в подробностях вплоть до полного завершения задач

Как используется Jira

Jira используют для того, чтобы формализовать отношения в IT коллективе. Тестировщик должен рассматривать баг теркинговую систему в первую очередь как собственную защиту. Все баги, задачи по тестированию должны иметь свой документ в системе с отмеченным статусом и результатом. Давайте рассмотрим несколько практических примеров:

 

1. Вас вызывает начальник для отчета:

 

BOSS: Чем ты занимался всю прошлую неделю?

Глупый QA: Ээээ... Мммм... Толик попросил меня проверить новый дизайн магазина дисков

BOSS: 

Какие конкретно задачи тестировались?

- Какой был объем работ?  

- Сколько багов  было открыто?

- Сколько из них исправлено?

Глупый QA: (начинает выглядеть глупо) Я сейчас посмотрю в своих листочках, там было что-то вроде 12 ошибок.

Умный QA:  Cогласно моей QA задаче было найбено 8 critical ошибок, 3 major и 2 minor. 8 багов уже исправлены. Список выполненых тестов есть в Jira задаче для тестирования.

 

Ведя електронную документацию и открывая задачи и баги в баг трекинговой системе,  вы всегда имеете возможность получить отчет о своей работе. А главное, вы можете контролировать прогресс и видеть статус тестирования.

 

2. Пользователи жалуются на баг, который продакт менеджер определил как "фича":

 

BOSS:  Почему не был обнаружен баг?

Глупый QA: Я нашел этот баг, честно, но программист сказал, что это фича, ничего заводить не надо.

Developer:  Я делал все согласно спецификации, там об этом ничего не говорилось

Product manager: Это явный баг, но я о нем ничего не знал, команда тестирования мне о нем не сообщила.

BOSS:    Прийдется уволить такого безответственного тестировщика!

Умный QA:  Я завел баг. Вот задача - SAS-3412. Продакт менеджер закрыл его как "not a bug". Я свою работу выполнил, все вопросы к нему.

 

Даже если вы думаете, что, скорее всего, ваш баг не будут фиксить, открывая документ для него, вы обезопасите себя в случае, если окажется, что это все-таки баг уже при эксплуатации программы. 

 
 
Почему JIRA?
 
Пример структуры проектов

Общим образом структуру проектов в баг трекинговых системах можно представить этой таблицей:

Давайте рассмотрим как будет работать эта структура на примере завода по производству истребителей повстанцев, который выпускает истребители для того,  чтобы разрушить Звезду смерти:

  • Баг репорты / Позволяют отслеживать ход исправления ошибки.

 

  • HelpDesk (Поддержка клиентов / Сервисное обслуживание). Отсюда придут пропущенные баги. Не допустим этого!

 

  • Управление проектом  / Это менеджерские фичи - позволяют производить учет выполненных задач, потраченного времени, качество кода  и прочее.

 

  • Управление ходом исполнения задач / Создание cпецифического workflow.

 

  • Управление требованиями /  Cоздание задач на разработку ПО для программистов.

 

  • Рабочие процессы / Визуализация рабочих процессов через графики, таблицы и фильтры текущих задач.

Работа с дефектами
( Трекинг дефекта в системе JIRA )

Далее на схеме ниже - базовый жизненный цикл бага, заведенного в баг трекинговой системе. Как только вы создаете новый баг репорт, он автоматически получает статус - "новый". Баг репорт нужно закрепить за каким-либо программистом или тест менеджером (если есть промежуточное звено). Далее у бага три пути: 1."Отклонен" заклинанием - "это не баг, это фича", 2."Открыт" - если его приняли в работу или 3."Отсрочен" - до лучших времен. Эти три состояния одноранговые и баг может переходить между ними. Далее, если баг пофиксят, он получит статус - "Исправлен". Если фикс не пройдет тестирование, баг переоткрывается снова на того же программиста, что им занимался. Так будет происходить до тех пор, пока он не пройдет проверку и не будет "Закрыт".

P.S. Закрытый баг также можно переоткрыть, если он появился снова. Например, в другой версии или в смежном проекте.

Не зря было замечено в описании вверху, что это базовая схема. Ведь баг трекинговая система гибкая и рабочий процесс должен настраиваться вашей компанией по ее усмотрению. Например, можно добавить статус - "На ковре у начальника" и пускай каждый баг проверяется начальником перед фиксом. Особенностью моей компании был статус для бага "In QA progress". Означает, что issue находится в работе у тестировщика и применяется для того, чтобы двое не работали над одним и тем же issue. Далее, мы рассмотрим конкретный пример жизненного цикла дефекта в Jira. 

 

Кстати, у тебя, наверняка, возник вопрос, что же такое Issue? Issue (англ. cпорный вопрос или проблемка) - так называют экземпляр электронного документа в баг трекинговой системе. 

Тестировщик создает новый баг

Баг получает статус "Открыт" и ждет своего программиста

Ура! Баг взяли в работу и он в процессе фикса. Ждем исправления

Исследовали баг (воспроизвели по вашему сценарию)

Анализ бага

Установка среды тестирования

Непосредственно исправление ошибки в коде

Баг отмечен как исправленный. Вперед, тестировщик!

Тут проверяют, что баг таки исправлен. И только 2 пути теперь у бага

Фикс принят и подтвержден

Не исправлен, или не до конца исправлен. Все по новой, баг в работу

Баг закрыт, ура!

Спорный случай. Обсуждение - принять ли такой фикс или нет?

 
Пример баг репорта в Jira

Как холодно на этом уровне ... 

Бррррр .....

Смотри скорее пример issue баг репорта и поехали дальше. К сожалению, это единственный пример на русском.

Я буду тебе переводить, но выучить английские названия элементов тестирования необходимо. Я помогу тебе в этом. В каждом уровне будут переводиться только новые слова на английском, Подразумевается, что предыдущие ты уже выучил.

 

Работа с дефектами - трекинг по ролям
Пример домашней страницы
 

Диаграмма внизу отображает циркуляцию issue по ролям в тестировании в течении первой части его жизненного цикла (до того, как баг будет assigned на developer). Эта часть крайне важна, так как помимо того, что баг описан, ему нужно присвоить приоритет, серьезность, проставить спринт, лейблы и прочее, а также решить спорные вопросы с product manager относительно каждого из этих пунктов. О ролях в тестировании вы подробнее узнаете на восьмом уровне. Еще уточним, что именно так схема выглядит только в идеале и только в больших компаниях, где есть все эти сотрудники. В других случаях все эти активности сохраняются, вот только эти роли выполняет один и тотже человек. То есть, вы сами должны уметь установить приоритет и важность, назначить нужного программиста на исправление,  а также поспорить с продактом по поводу неоднозначных моментов и уметь обосновать свою точку зрения. 

 

C чего начинается Jira? Jira, как и любая веб-система, начинается с домашней страницы. Страница эта кастомизируемая, то есть туда можно добавить интересующие вас модули. В стандартном наборе есть: новости проекта, задачи, любимые фильтры задач. 

Assigned to me задачи закрепленные за вами

Agail board

С Agail board и кофе утро свое начинаю я. В этой таблице находится весь список задач, вращающийся в компании сейчас. В каждой колонке свой статус задач: то, что только разрабатывается, что провалило тестирование, что ожидает тестирования,  что протестировали и что прошло тестирование успешно (Pass QA).

Что такое Agail board, задумаетесь вы? В нашем случае - это визуальное отображение багов и задач на этот спринт с разделением по статусу (и с различными дополнительными индикаторами).

1

2

3

4

5

Чтобы тебе было проще разобраться с  картинкой :

  1. In Dev - задачи, которые находятся в разработке

  2. Fail QA - то, что не прошло тестирование

  3. Ready for QA -  то, что ожидает тестировани, банк работы для тестировщика

  4. QA in progress - то, что находится на тестировании в данный момент

  5. Done  - то, что завершено/протестировано/, баги исправлены

Favorite filters - наиболее часто используемые фильтры jira задач

DEV task

DEV task - это задача на разработку, первичный документ, с которым начинает работать тестировщик при тестировании нового функционала. Задача на разработку создается для всех в компании, но в первую очередь, для программиста. Этот документ содержит всю ключевую информацию по задаче + ссылки на более подробные документы как, например,  спецификацию если фича большая, а если нет, то все описыватся в самом issue. 

К тестировщику этот документ попадает из колонки Ready for QA, когда разработка завершена и наступает черед тестирования. Давай пройдем по основным пунктам DEV task:

Название проекта
Панель текущего статуса задачи 
Кнопка для создания задачи
Уникальный номер задачи
Основное описание
Информация по задаче
Приложение для скриншотов
и необходимых файлов
Связанные issue (задачи) или тикеты в Jira
Активности:
комментарии , история действий , вопросы
Кнопка редактировать
Имя задачи 
Подзадачи
Даты создания, обновления и закрытия задачи
 

Давайте рассмотрим панель текущего статуса задачи подробнее

 

Текущий статус задачи

 

  • Type - Тип задачи.

 

  • Priority - Приоритет.

 

  • Affects versions - версия, в которой был обнаружен баг

 

  • Labels - Логотип, указывающий на принадлежность к какой-то фиче, структуре,

релизу и тому подобное 

 

  • Epic link - Аналог label, но образует жесткую структуру и автоматически формирует связку задач и фильтр.

 

  • Status -  текущий статус бага. Pass QA/Fail QA/Resolved/Closed/In progress/Open/Reopen ....

 

  • Resolution - вердикт, вынесенный багу. Перекликается со статусом, но имеет дополнительную информацию.  Например, если баг закрыт (Closed), Resolution указывает почему он закрыт: fixed/not a bug/duplicate/can't reproduce...

 

  • Fix version - версия, содержащая Fix для бага. В этой версии или в версии более позд, баг проверяется

И как теперь понять, в чем отличие epic link и label, а также Status и Resolution ??

Альтернативные системы

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

 

Вторая по популярности система после Jira -  это Redmine. Главное ее отличие состоит в open sourse основе. Поэтому, чтобы ее администровать, нужны определенные навыки работы с Linux системой. Но тестировщиков это абсолютно не касается. Мы работаем только с интерфейсом. Более подробное сравнение систем вы найдете в этой статье

 
 
Bug

Наконец, мы добрались до описания бага. Спешу обрадовать - оно очень приближенно к стандарту баг репорта, который мы уже выучили на предыдущем уровне. Но создавать баг репорт в Jira - одно удовольствие. Вся структура готова, только выбери нужное значение. Кроме того, обычно разрабатывается единая схема описания бага, которая шаблоном добавляется при создании бага. 

Стандартное описание бага должно содержать: тестовую среду (server name), подверженное багу устройство/программу (browser name), preliminaries - предусловия, Test scenario - тестовый сценарий, Актуальный и Ожидаемый результат.

 

Описание бага
Панель текущего статуса задачи -аналогичная для всех типов задач. Единственное отличие type- bug
Description - альтернативное описание (оно не требуется, если все уже внесено в  QA info)
Скриншот бага
Активность, комментарии , история , вопросы
Вопросы и итоги
Обучающее видео
 

Обучающее видео будет вишенкой на нашем пироге  Jira. Просмотрев его, приступай к практике! 

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

Практика

Cоздай тренировочный баг - любой из твоего домашнего задания. Прикрепи его на администратора проекта.

 

Заходи на Jira портал.

Для входа нужно, чтобы вам дали доступ к Jira проекту. Сообщи нам, если не получал письма с доступом.

Домашнее задание

Вас ждет увлекательное практическое задание и, как всегда, теоретический тест. Описание практики ты сможешь найти в Jira задаче. Не забудь отправить свою работу через форму.

Уважаемый будующий тестировщик, прежде чем вы перейдете далее, посоватую вам статьи по теме уровня для прочтения:

Как планируют спринты в подразделении Яндекс 

Для перехода на уровень 7, необходимо набрать минимум 13,8 баллов (60%)  за задания уровня 6.

Уровень 7