Ласкаво просимо на крижану планету Хот! Пройшовши її суворі випробування, ти навчишся працювати в команді з іншими ІТ-спеціальностями. І в цьому тобі допоможе баг-трекінгова система.

Кожен тестувальник, чия компанія більша за 2 людини, працює з баг-трекінговою системою. Давай розберемося, що це за система, на прикладі JIRA.

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

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

- здійснювати підтримку користувачів,

- стежити за процесом усунення цих помилок і за виконанням чи невиконанням будь-яких ІТ-процесів.

Структура проєктів

Дає змогу призначати, розставляти пріоритети, відстежувати, створювати звіти, опрацьовувати й моніторити «баги»
Розширювана платформа, що налаштовується під конкретні бізнес-процеси
Підвищує продуктивність завдяки скороченню втрат часу на відстеження ходу вирішення проблем і координацію
Підвищує якість виконання завдяки тому, що хід виконання всіх завдань докладно фіксується аж до їх повного завершення

Як використовується Jira

Jira використовують для того, щоб формалізувати стосунки в ІТ-колективі. Тестувальник має розглядати баг-трекінгову систему насамперед як власний захист. Усі баги та завдання з тестування повинні мати свій документ у системі з відміченим статусом і результатом. Розгляньмо кілька практичних прикладів:

1. Вас викликає начальник по звіт:

BOSS: Чим ти займався весь минулий тиждень?

Безтолковий QA: Еее... Мммм... Толік попросив мене перевірити новий дизайн магазину дисків

BOSS:

- Які саме завдання тестувалися?

- Який був обсяг робіт?

- Скільки багів було відкрито?

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

Безтолковий QA: (починає виглядати безглуздо) Зараз гляну у своїх папірцях, там було щось на кшталт 12 помилок.

Розумний QA: Згідно з моїм QA-завданням було знайдено 8 critical помилок, 3 major і 2 minor. 8 багів уже виправлено. Список виконаних тестів є в Jira-завданні на тестування.

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

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

BOSS: Чому баг не було виявлено?

Безтолковий QA: Я знайшов цей баг, чесно, але програміст сказав, що це фіча, і нічого заводити не треба.

Developer: Я робив усе згідно зі специфікацією, там про це нічого не говорилося

Product manager: Це явний баг, але я нічого про нього не знав, команда тестування мені про нього не повідомила.

BOSS: Доведеться звільнити такого безвідповідального тестувальника!

Розумний QA: Я завів баг. Ось завдання - SAS-3412. Продакт-менеджер закрив його як "not a bug". Я свою роботу виконав, усі запитання до нього.

Навіть якщо ви думаєте, що, найімовірніше, ваш баг не виправлятимуть, відкривши для нього документ, ви убезпечите себе на випадок, якщо виявиться, що це таки баг — уже під час експлуатації програми.

Чому JIRA?

- То чому ми використовуємо Jira як приклад? Тому що вона краща?

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

- Може, тому що автор користувався нею на момент створення рівня?

- Хтозна... Він і Redmine свого часу багато використовував.

Скажімо так, Jira — більш поширена баг-трекінгова система, ніж решта, але абсолютним лідером вона не є. Jira активно розвивається, постійно додає нові модулі, адже це платний проєкт, на відміну від повільних open source проєктів. Важливо зрозуміти одне: усі баг-трекінгові системи схожі, і якщо ви вмієте працювати в одній із них, вам вистачить кількох годин, щоб розібратися в будь-якій іншій.

Що є в JIRA?

Загалом, будь-яка трекінгова система — це засіб електронного документообігу. Оскільки всі айтішники за зелені дерева і проти папірців, які вічно губляться, кожен потрібний документ оформлюється у вигляді завдання. Завдання бувають майже на все: написати програму, протестувати її, налаштувати для неї сервер і навіть замінити зіпсований вінчестер у робочому ноутбуці. Типи завдань, які вам траплятимуться в роботі:

Баг-репорти / Дають змогу відстежувати перебіг виправлення помилки.
HelpDesk (підтримка клієнтів / сервісне обслуговування). Саме звідси прийдуть пропущені баги. Не допустимо цього!
Управління проєктом / Це менеджерські фічі: вони дають змогу вести облік виконаних завдань, витраченого часу, якості коду тощо.
Управління ходом виконання завдань / Створення специфічного workflow.
Управління вимогами / Створення завдань на розробку ПЗ для програмістів.
Робочі процеси / Візуалізація робочих процесів через графіки, таблиці та фільтри поточних завдань.

Приклад структури проєктів

Загалом структуру проєктів у баг-трекінгових системах можна представити такою таблицею:

Розгляньмо, як працюватиме ця структура, на прикладі заводу з виробництва винищувачів повстанців, який випускає винищувачі, щоб зруйнувати Зорю смерті:

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

Далі на схемі нижче показано базовий життєвий цикл бага, заведеного в баг-трекінговій системі. Щойно ви створюєте новий баг-репорт, він автоматично отримує статус "новий". Баг-репорт потрібно закріпити за якимось програмістом або тест-менеджером (якщо є проміжна ланка). Далі в бага три шляхи: 1. "Відхилено" заклинанням "це не баг, це фіча", 2. "Відкрито", якщо його взяли в роботу, або 3. "Відкладено" — до кращих часів. Ці три стани рівноправні, і баг може переходити між ними. Далі, якщо баг виправлять, він отримає статус "Виправлено". Якщо фікс не пройде тестування, баг знову відкривається на того самого програміста, який ним займався. Так відбуватиметься доти, доки він не пройде перевірку і не буде "Закрито".

P.S. Закритий баг також можна відкрити повторно, якщо він з'явився знову. Наприклад, в іншій версії або в суміжному проєкті.

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

До речі, у тебе, напевно, виникло запитання, що таке Issue. Issue (англ. спірне питання або проблемка) — так називають екземпляр електронного документа в баг-трекінговій системі.

Тестувальник створює новий баг

Баг отримує статус "Відкрито" і чекає на свого програміста

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

Налаштування середовища тестування

Аналіз бага

Дослідили баг (відтворили за вашим сценарієм)

Безпосереднє виправлення помилки в коді

Баг позначено як виправлений. Вперед, тестувальнику!

Тут перевіряють, що баг таки виправлено. І тепер у бага лише 2 шляхи

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

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

Баг закрито, ура!

Спірний випадок. Обговорення: приймати такий фікс чи ні?

Приклад баг-репорту в Jira

Як холодно на цьому рівні...

Бррррр.....

Швидше дивись приклад issue-баг-репорту, і рушаймо далі. На жаль, це єдиний приклад російською.

Я перекладатиму тобі, але вивчити англійські назви елементів тестування необхідно. Я допоможу тобі в цьому. У кожному рівні перекладатимуться лише нові англійські слова; передбачається, що попередні ти вже вивчив.

Робота з дефектами - трекінг за ролями

Діаграма внизу відображає циркуляцію issue за ролями в тестуванні впродовж першої частини його життєвого циклу (до того, як баг буде assigned на developer). Ця частина вкрай важлива, адже, крім того що баг потрібно описати, йому треба присвоїти пріоритет, серйозність, проставити спринт, лейбли тощо, а також вирішити спірні питання з product manager щодо кожного з цих пунктів. Про ролі в тестуванні ви докладніше дізнаєтеся на восьмому рівні. Ще уточнімо, що схема виглядає саме так лише в ідеалі й тільки у великих компаніях, де є всі ці співробітники. В інших випадках усі ці активності зберігаються, от тільки ці ролі виконує одна й та сама людина. Тобто ви самі маєте вміти встановити пріоритет і важливість, призначити потрібного програміста на виправлення, а також посперечатися з продактом щодо неоднозначних моментів і вміти обґрунтувати свою точку зору.

Приклад домашньої сторінки

З чого починається Jira? Jira, як і будь-яка веб-система, починається з домашньої сторінки. Ця сторінка кастомізується, тобто туди можна додати цікаві вам модулі. У стандартному наборі є: новини проєкту, завдання, улюблені фільтри завдань.

Assigned to me завдання, закріплені за вами

Favorite filters - найчастіше використовувані фільтри Jira-завдань

Agile board

З Agile board і кавою ранок свій розпочинаю я. У цій таблиці міститься весь список завдань, що обертаються в компанії просто зараз. У кожній колонці — свій статус завдань: те, що лише розробляється, що провалило тестування, що очікує на тестування, що протестували і що успішно пройшло тестування (Pass QA).

Що таке Agile board, замислитесь ви? У нашому випадку це візуальне відображення багів і завдань на цей спринт із розподілом за статусом (і з різними додатковими індикаторами).

Щоб тобі було простіше розібратися з картинкою:

In Dev - завдання, що перебувають у розробці
Fail QA - те, що не пройшло тестування
Ready for QA - те, що очікує на тестування, банк роботи для тестувальника
QA in progress - те, що перебуває на тестуванні на цей момент
Done - те, що завершено/протестовано, баги виправлено

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 - версія, що містить фікс для бага. У цій версії або в пізнішій баг перевіряється

І як тепер зрозуміти, у чому відмінність між epic link і label, а також між Status і Resolution??

Bug

Нарешті ми дісталися опису бага. Поспішаю втішити: він дуже наближений до стандарту баг-репорту, який ми вже вивчили на попередньому рівні. Але створювати баг-репорт у Jira — суцільне задоволення. Уся структура готова, тільки обери потрібне значення. Крім того, зазвичай розробляється єдина схема опису бага, яка шаблоном додається під час створення бага.

Стандартний опис бага має містити: тестове середовище (server name), пристрій/програму, схильні до бага (browser name), preliminaries — передумови, Test scenario — тестовий сценарій, Актуальний та Очікуваний результат.

Панель поточного статусу завдання однакова для всіх типів завдань. Єдина відмінність — type - bug

Опис бага

Description - альтернативний опис (не потрібен, якщо все вже внесено в QA info)

Скриншот бага

Активність, коментарі, історія, запитання

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

Автор цілком визнає, що баг-трекінгових систем, а також інших систем автоматизованого управління документообігом так само багато, як риби в морі й користувачів в інтернеті. Вони всі схожі й стануть легким підручним засобом для того, хто вміє тестувати й знає, як правильно завести баг. Розгляньмо деякі аналогічні системи, щоб розширити кругозір і бути готовими до всього.

Друга за популярністю система після Jira — це Redmine. Її головна відмінність полягає в open source основі. Тому, щоб її адмініструвати, потрібні певні навички роботи з Linux. Але тестувальників це абсолютно не стосується. Ми працюємо лише з інтерфейсом. Докладніше порівняння систем ви знайдете у цій статті

Статті для прочитання за темою

1. Порівняння популярних систем баг-трекінгу

2. Відеоогляд деяких популярних трекінгових систем

Запитання та підсумки

Навчальне відео

Навчальне відео стане вишенькою на нашому Jira-торті. Переглянувши його, переходь до практики!

Для додаткового поглибленого вивчення ось тобі посилання на університет Jira. Ти знайдеш там повний навчальний курс із баг-трекінгової системи Jira від виробника.

Практика

Створи тренувальний баг — будь-який із твого домашнього завдання. Закріпи його за адміністратором проєкту.

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

Для входу потрібно, щоб вам надали доступ до Jira-проєкту. Повідом нам, якщо не отримував листа з доступом.

Домашнє завдання

На вас чекає захопливе практичне завдання і, як завжди, теоретичний тест. Опис практики ти зможеш знайти в Jira-завданні. Не забудь надіслати свою роботу через форму.

Jira-завдання

Тест

Надіслати

Шановний майбутній тестувальнику, перш ніж ви перейдете далі, раджу вам прочитати статті за темою рівня:

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

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