jira bug tracking tool tutorial
Відстеження помилок JIRA: життєвий цикл дефектів у JIRA
Завантаження та встановлення Jira було детально пояснено в нашому попередньому навчальному посібнику. Тестові групи завжди з побоюванням ставляться до JIRA для управління дефектами.
Сумнів виправданий. Це випливає з того, що, хоча інструмент відстеження помилок JIRA застосовується до ІТ-бізнесу, це загальна система продажу квитків.
Навіть для ІТ-проектів популярність JIRA серед команд розробників робить тестерів та команди з контролю якості незручними. Незважаючи на комфорт чи дискомфорт, тестовим командам не залишається іншого вибору, як використовувати інструмент відстеження помилок JIRA у більшості компаній. Наші Повний посібник з навчання JIRA дасть вам чудові знання про інструмент.
=> Клацніть тут, щоб отримати повну серію навчальних посібників JIRA
Чому? Проста логіка Компанії не хочуть інвестувати в кілька інструментів. Просто має сенс у бізнесі максимізувати використання інструментів і не збожеволіти від придбання забагато ліцензій.
Отже, якщо команда розробників використовує Atlassian JIRA інструмент відстеження помилок, щоб відстежувати його вимоги, вдосконалення, завдання чи історії користувачів, тоді тестова група, швидше за все, повинна використовувати його для відстеження помилок.
яка найкраща операційна система
Але, розслабтеся . Управління дефектами JIRA настільки ж добре, як і будь-який інший інструмент . Насправді, в деяких ситуаціях це може бути навіть краще.
Це підручник, який продемонструє вам, за допомогою скріншотів та всього іншого, придатність JIRA до відстеження помилок.
Що ви дізнаєтесь:
- Найкращі можливості інструмента відстеження помилок JIRA
- №1) JIRA трактує всю роботу, що знаходиться в ній, як випуск
- # 2) Повідомлення про дефекти потребує наступної інформації, записаної для кожного випуску:
- # 3) Життєвий цикл дефектів:
- # 4) Коментарі та співпраця з командою розробників
- # 5) Пов’язання дефекту з вимогою забезпечити простежуваність
- # 6) Дефекти можна імпортувати з файлу CSV
- # 7) Дефекти можна експортувати у формати Word, XML та для друку
- # 8) Вичерпні звіти про проблеми:
- Застосовність JIRA до тестування - альтернативна дилема
- Створення випуску Jira та різних полів
- Як обробляються питання в JIRA
Найкращі можливості інструмента відстеження помилок JIRA
Ось і ми.
№1) JIRA трактує всю роботу, що знаходиться в ній, як випуск
Отже, в JIRA створення дефекту означало б створення проблеми типу „ Помилка '.
# 2) Повідомлення про дефекти потребує наступної інформації, записаної для кожного випуску:
- Ідентифікатор дефекту
- Назва дефекту
- Опис дефекту (кроки для відтворення)
- Інформація про довкілля
- Знімок екрана (вкладення)
- Серйозність
- Призначити комусь
- Статус- Усі статуси життєвого циклу помилки
Доступні всі варіанти, щоб ефективно створити дефект.
Зверніть увагу на поля, виділені червоним нижче:
Два поля, яких ви тут не бачите:
- Ідентифікатор дефекту
- Статус
Ці два поля автоматично створені JIRA. Усі випуски матимуть унікальний ідентифікатор, призначений їм JIRA. Статус усіх видань за замовчуванням при створенні помилки - 'Завдання' або 'Новий' у JIRA.
Отже, всі загальні засоби для повідомлення про дефекти також доступні в JIRA. Насправді може бути використано більше варіантів, таких як наклейки, дефекти зв’язування, оцінка зусиль.
# 3) Життєвий цикл дефектів:
Усі статуси життєвого циклу помилок, як у Bugzilla (або будь-який інший популярний трекер помилок - ) можна виконати і тут:
Для цього потрібно трохи налаштувати адміністратора JIRA, але це легко зробити. Для тих, хто не хоче турбуватися про налаштування, ви також не можете помилитися з налаштуванням за замовчуванням.
# 4) Коментарі та співпраця з командою розробників
Кожне випуск, його оновлення, призначення людей, коментарі, отримані від команди розробників - все відстежується в JIRA під журналом активності.
Це дозволяє покращити видимість та співпрацю з командами розробників:
# 5) Пов’язання дефекту з вимогою забезпечити простежуваність
Параметр посилання у полях випуску JIRA дозволяє зв’язати певне видання з іншим. Скажімо, якщо дефект 2 є дублікатом дефекту 1, ви можете встановити ці відносини.
Подібним чином, якщо дефект блокує вимогу або пов’язаний із вимогою - ви можете зробити цей аспект видимим у JIRA.
Отримані посилання з’являться на сторінці деталей випуску, як показано нижче:
Типи відносин є зрозумілими і використовуються проста-загально-побутова-мова слова (наприклад, стосуються, спричинені тощо) роблять надзвичайно легким та інтуїтивно зрозумілим для будь-якого користувача JIRA використовувати це право.
# 6) Дефекти можна імпортувати з файлу CSV
Це допомагає відразу масово створювати випуски в JIRA. Крім того, якщо ваша команда новачка, і ви не хочете, щоб вони створювали проблеми безпосередньо в інструменті, ви можете попросити їх повідомити про дефекти в аркуші Excel. Після того, як вони перевірені та підтверджені як дійсні, їх можна імпортувати всі відразу в інструмент, використовуючи цю функцію.
Яким би способом ви його не використовували, це великий плюс.
# 7) Дефекти можна експортувати у формати Word, XML та для друку
Це підтримує кращу портативність даних про вади, особливо корисно, якщо ви хочете поділитися своїми даними про дефекти з людьми, які не є користувачами JIRA.
# 8) Вичерпні звіти про проблеми:
Крім того, якщо вам потрібні звіти, перейдіть до “ Проект - звіти 'Та генеруйте всілякі звіти, як показано нижче:
Якщо нам доведеться переглянути аналітику JIRA одним словом, це фантастика.
Досвідчені / досвідчені користувачі JIRA також можуть створювати розширені фільтри пошуку, щоб отримати глибшу інформацію.
Наприклад, якщо ви хочете ознайомитися з усіма дефектами, присвоєними вам у кількох проектах (BM і AB), ви можете скористатися запитом JQL, як показано нижче:
Отже, у цілому відстеження помилок / управління дефектами в JIRA дуже схоже, якщо не перевершувати спеціальні трекери помилок. Наступного разу, коли вам доведеться над цим працювати, не хвилюйтеся. Ви в добрих руках.
Застосовність JIRA до тестування - альтернативна дилема
Хоча це одна сторона медалі, безумовно, є інший вимір того, як люди розглядають придатність JIRA до контролю якості або тестування.
Коли ви запитаєте групу QAs, “Що таке JIRA?” - багато хто відповість, що JIRA - це інструмент відстеження дефектів. Майте на увазі, я чув про це від багатьох вищих фахівців з контролю якості. Це могло бути пов’язано з тим, що для управління JIRA використовувалось управління / відстеження дефектів.
Але в цьому є набагато більше. При правильному використанні основний JIRA з його гнучкими можливостями може стати вашим єдиним магазином для управління проектами високого рівня.
Він може реально підтримувати відстеження вимог та прогрес, відстеження помилок, оцінку, відстеження спринту через дошки SCRUM & KANBAN, звітування та співпрацю.
Можливо, ви використовуєте інструмент для одного, але наступного разу спробуйте вивчити кілька речей навколо та про інструмент, який допоможе вам краще зрозуміти та використовувати його.
Отже, наступним кроком, Ви можете вивчити кілька інших цікавих функцій JIRA (які можуть бути безпосередньо не пов’язані з відстеженням помилок), які можуть зробити ваш вибір.
- Настроювані інформаційні панелі
- Доповнення для управління тестами
- Голосування та перегляд випуску
- Відстеження часу
- Дошки Agile Project та Scrum
- Інтеграція підтримки злиття / документації тощо.
Створення випуску Jira та різних полів
Питання про Джиру: різні типи питань про Джиру
Jira пропонує вам дуже прості способи створення / реєстрації проблем.
Це не тільки дозволяє нам реєструвати помилки, але також дає нам змогу отримувати інші типи 'квитків' або 'запитів'. Це скоріше загальна програма управління запитами.
У цьому посібнику буде детально описано типи випусків у Jira, створено випуск, різні поля на сторінці „Створення випуску” та їх деталі простими словами з графічним поданням для Вашого легкого розуміння.
Jira Issues
Різні організації можуть мати різні типи питань залежно від їх придатності / потреб. Адміністратор Jira може ефективно налаштувати це поле.
Випуски можуть бути різних типів, а нижче наведено Опис / значення типів видань:
- Помилка: Це будь-які дефекти або відхилення, виявлені в додатку.
- Запит на вдосконалення: Він також відомий як запит на зміну (CR). Цей тип використовується для відображення будь-яких змін у існуючій функціональності або в цілому нової функціональності.
- Завдання: Це більше проблема конфігурації чи аналізу. Наприклад , налаштування належних конфігурацій може бути завданням.
- Питання: Випуск може бути таким простим, як запитання про те, як використовувати певну функціональність програми. Цей тип частіше використовується кінцевими споживачами.
- Епопея: Зазвичай це величезна проблема, яка в ідеалі розбивається на кілька невеликих питань. Щоб завершити основну епічну проблему в спритному середовищі, може знадобитися кілька спринтів.
- Фінансовий об'єкт: Часто управління проектами / продуктами використовує цей тип випуску для відстеження своїх фінансів.
- Історія: Вся історія користувача про функцію може бути типом проблеми.
- Тестовий кейс : Випуск може бути тестовим прикладом. Цей тип випуску буде доступний після інтеграції Jira із такими плагінами, як Zypher.
Створення випуску
Припускаючи, що користувач увійшов у Jira та бажаний проект.
Крок 1:
Натисніть кнопку «+» («Створити») на панелі інструментів.
З’явиться екран / сторінка, як показано на малюнку нижче:
На цій сторінці виберіть проект та тип випуску / запиту, а потім натисніть кнопку «Далі».
Після цього відкриється сторінка «Створити проблему», як показано на наступних зображеннях:
Крок 2:
Введіть обов’язкові дані та інші дані якомога більше на сторінці «Створити проблему».
Крок 3:
Натисніть кнопку «Створити». Це створить унікальний ідентифікатор проблеми. Ідентифікатор складатиметься з ідентифікатора проекту, об'єднаного числовими цифрами.
У наведеному вище Прикладі обраним проектом є «TestProject», отже, ідентифікатор може бути таким, як «TESTPROJ1234».
- Після створення проблеми, після цього її можна шукати за допомогою ідентифікатора проблеми.
Опис полів на сторінці 'Створити проблему'
(Зображення сторінки створення проблем розділено на 3 частини для кращої читабельності).
Примітка :Адміністратор та / або розробник Jira можуть додавати / видаляти власні поля залежно від потреб організації.
# 1) Резюме :
Це також частіше називають заголовком випуску і є дуже важливим полем випуску Jira.
Заголовок повинен бути якомога унікальнішим і точнішим, щоб, дивлячись на сам заголовок, можна було зрозуміти проблему. Це допомагає дошці огляду помилок та / або власникам продуктів визначити пріоритет та призначити проблему, не заглиблюючись у неї.
# 2) Компонент / и :
Найменування (и) модуля або області програми, де виявлено дефект у випадку типу проблеми 'Помилка'.
Це може бути область, де потрібні зміни у випадку CR. Зазвичай це випадаюче меню, що складається з різних модулів / компонентів, які існують у програмі. Особа проекту повинна отримати його від адміністратора.
# 3) Опис :
Зазвичай повинен містити кроки для відтворення проблеми, якщо тип проблеми - помилка.
У разі запиту на вдосконалення, він повинен детально розповісти про нову вимогу, яка зазвичай називається історією в гнучкій термінології. В ідеалі це поле слід регулярно оновлювати протягом робочого циклу випуску.
# 4) Виправити версії :
Назва версії, в якій буде доставлено запит на випуск / вдосконалення. Це значення, як правило, заповнюється власником продукту за погодженням із майстром скраму в гнучкому середовищі скрам.
# 5) Пріоритет :
Це поле вказує на критичність проблеми.
Це може бути пробка для показу, тобто тестування додатків не може тривати на етапі тестування. Збій програми - ідеальний варіант Приклад випуску 'Показати пробку' (критичний).
Рада з огляду помилок та власники продуктів мають повне право змінити пріоритет проблеми. Це поле є випадаючим списком із такими значеннями, як „Низький”, „Середній” („Основний”), „Критичний”, „Тривіальний” тощо.
# 6) Етикетки :
У це поле вводяться тексти, які допоможуть класифікувати питання.
# 7) Навколишнє середовище :
Це необов’язкове поле, і тут вказано тестове середовище.
# 8) Додаток :
Підтримуючі зображення для створюваного випуску. Користувач може просто перетягувати зображення або копіювати та вставляти.
# 9) Впливає на версію / и :
Для випуску типу 'помилка' тут слід ввести версію продукту.
Наприклад 5.6, 5.7 тощо.
# 10) Пов’язані випуски :
програми для завантаження відео з YouTube
Інші відповідні проблеми можна пов’язати з новим випуском, вибравши відповідне значення з цього спадного меню.
Наприклад, якщо проблему вводить виправлення якоїсь іншої проблеми, тоді значення, яке буде вибрано зі спадного меню, може бути «Введено». Це поле стає надзвичайно важливим, якщо новий дефект викликаний певним виправленням або вдосконаленням.
=> Випуск : Після вибору належного значення в розділі «Пов’язані проблеми» тут згадується відповідний ідентифікатор проблеми.
# 11) Цесіонарій :
Це ім’я користувача, який працюватиме над цим питанням.
Наприклад, у випадку помилки, це буде ім’я розробника, який вирішить проблему. Це поле зазвичай заповнюється власником продукту або майстром scrum. Знову ж, хто призначає випуск, може відрізнятися в залежності від організації.
=> Натискання кнопки «Призначити мені» (розташоване в правому куті поля «Призначник») присвоює проблему зареєстрованому користувачеві.
# 12) Епічне посилання :
Виберіть відповідне посилання епопеї.
# 13) Спринт :
Тут вибирається назва спринту, вказуючи, коли буде працювати над випуском. Це може бути майбутній спринт за рішенням власника продукту.
# 14) Команда :
У спритному середовищі можуть бути різні команди. Випуск покладено на одну з команд. Це призначення зазвичай виконується власником продукту або майстром сутичок за погодженням з власником продукту.
# 15) Оцінка на початку :
У цьому полі буде вказано, скільки часу буде потрібно для вирішення проблеми.
Частіше називають 'вгадуванням'. Це також складатиметься з необхідних зусиль для тестування. Це може бути зазначено в годинах / днях / тижнях або сюжетах. У спритній обстановці під час планування спринту вся команда досягає загальної здогадки.
# 16) Репортер :
Цей файл автоматично заповнюється Джирою з іменем зареєстрованого користувача.
Примітка: Ми могли б мати деякі інші власні поля, як показано нижче (яких не видно на наведених вище зображеннях):
(i) Тип середовища :
Вказує, чи виявлено дефект у тестовому або виробничому середовищі.
Значення цього поля можуть різнитися залежно від організації. Якщо Jira використовується для створення питань лише внутрішньо в організації, а не кінцевими споживачами, то це поле може взагалі не існувати.
(ii) Відтворюється :
Чи відтворюваний дефект? Це поле буде недоступне для будь-якого типу проблеми, крім помилки.
(iii) Клієнт :
У цьому полі вказується кінцевий споживач, який подав проблему. У деяких організаціях, де Jira використовується лише для внутрішнього вирішення проблем, цього поля може не існувати.
Примітка: Всі описані вище поля належать до вкладки «Поле» на сторінці «Створити проблему», яка, як правило, є вкладкою за замовчуванням. Сторінку можна налаштувати, щоб мати більше вкладок, таких як „Документація“ тощо, про які ми розповімо у наступних навчальних посібниках.
Jira дає нам ефективний спосіб легко та ефективно вирішувати різні типи питань.
Завдяки великій кількості налаштувань, які сьогодні можливі, Jira стала найпопулярнішим вибором.
Як обробляються питання в JIRA
Робота з проблемами JIRA - Як зареєструвати дефект у JIRA
Перейдемо до створення проблеми, припускаючи, що користувач, який увійшов до системи, не є адміністратором, а наш тестовий проект - «Тест на STH» з компонентами - Модуль 1 та Модуль 2, версії - версія 1 та Версія 2. Ключ - TFS вже створений.
Створення випуску JIRA
Проблеми становлять суть JIRA, тому для їх створення є параметр прямо в рядку меню:
Натисніть кнопку «Створити випуск». По черзі, коли ви вводите “c”, перебуваючи на сторінці JIRA, відкриється таке діалогове вікно “Створити випуск”.
Усі поля на цій сторінці є зрозумілими. Нижче ми обговоримо найважливіший.
Проект : Кожне видання належить до проекту. Ви можете вибрати те саме, натиснувши на спадне меню та вибравши проект, до якого ви хочете належати даному випуску.
Тип випуску :У цьому полі відображаються всі типи проблем, які можна створювати та відстежувати за допомогою JIRA. У цьому списку доступні наступні опції (цей список може відрізнятися залежно від налаштування, встановленого адміністратором):
Елементи помилки, нова функція, завдання, вдосконалення - саме те, що випливає з їх назв. Епопея та історія більше відповідають спритним проектам. Історія - це вимога в Agile, яку потрібно відстежувати від початку до кінця. «Епопея» - це група історій.
За потреби виберіть тип випуску. Я збираюся піти з “Помилкою”.
Резюме : Дайте своїй помилці назву тут. При правильному використанні це поле може бути дуже успішним при передачі великої кількості важливої інформації. Деякі аспекти, на які слід звернути увагу тут:
Помилка / дефект - це, по суті, щось неправильне. Правильний спосіб підійти до заголовка помилки - це коротко визначити „що не так”.
Приклад поганого заголовка / резюме - “Повинна бути можливість очистити вміст на екрані”. Коли я прочитаю це, моя початкова реакція буде такою: „Добре, має бути, але в чому тут проблема? Цей варіант взагалі відсутній? Або варіанти присутні, а вміст не очищений? '
Також домовлено, що коли я відкрию цю помилку та детально її розгледжу, я впевнений, що знайду відповідь на це питання.
Однак тут наголошується на використанні цього поля 'Підсумок' найбільш ефективно. Тому дуже влучним резюме / заголовком було б 'Опція очищення вмісту домашньої сторінки входу не очищає поля при натисканні'.
На обмеженому просторі, яке надає це поле, спробуйте написати свій заголовок таким чином, щоб повідомляти про точну проблему без жодних двозначностей.
Пріоритет : Це поле може приймати одне з наступних значень.
Виберіть відповідний варіант для вашої помилки.
С поставити т : Цей список відображатиме компоненти Проекту. Вибирай доречно.
Постраждала версія та версія виправлення: Ці два поля відображатимуть версії, доступні для проекту. Не обов'язково, щоб певна проблема, з якою ви зіткнулися в певній версії, виправлялася в тій самій. У таких випадках ви можете вибрати відповідну версію як поточну, а виправлену - як наступну.
Крім того, ці поля можуть приймати кілька значень. Ви можете встановити, що певна проблема стосується як версії 1, так і версії 2, як показано нижче:
Цесіонарій : Ви можете ввести ім'я особи, якій цей випуск має бути переданий далі. Ви також можете призначити випуск собі.
Опис : Це необов’язкове текстове поле, яке допомагає вам ввести стільки інформації, скільки вам потрібно про вашу проблему. У випадку помилка , типово використовувати це поле для надання детальної інформації про етапи відтворення дефекту.
Надзвичайно важливо надати всю інформацію.
“Скажімо, є два поля - залежне - штат і місто. Коли я вибираю штат зі спадного меню, у полі Місто воно повинно відображати відповідні міста в штаті, який я обрав.
Якщо я підняв помилку як 'Міста порожні для деяких штатів, які я вибрав'. Поле опису - це місце для мене, щоб детальніше розглянути цей дефект.
Прикладом недостатнього опису є:
1) Зайдіть на сайт
2) Клацніть на адресній сторінці
3) Введіть інші дані, як-от ім’я, вулиця тощо.
4) Клацніть на спадне меню 'Держава'. Виберіть штат
5) Клацніть на спадне меню “Місто” - зверніть увагу на назви міст
Наведений вище опис хоч і точний, але не повний. Коли справа стосується цієї сфери, то на боці надання занадто багато інформації, але не надто мало.
Якщо до опису додати наступні кроки, це буде мати більше сенсу.
6) Виберіть штат як 'Каліфорнія' та натисніть на спадне меню 'Місто' - всі штати будуть відображені, і користувач може вибрати місто за необхідності.
7) Виберіть штат як 'Луїзіана' та натисніть на спадне меню 'Місто' - список буде порожнім.
8) Міста також порожні для штатів Нью-Джерсі та Юта.
Отже, повторіть, надайте точні кроки, точні дані та будь-яку іншу інформацію, яка, на вашу думку, необхідна для заповнення цього поля.
Прикріплення : Будь-який супровідний документ можна завантажити з випуском.
Як тільки вся інформація буде введена до вашого задоволення, випуск можна створити, натиснувши кнопку «Створити» в кінці діалогу «Створити випуск».
Випуск створюється, а користувачеві відображається повідомлення з ідентифікатором проблеми:
Примітка: зверніть увагу на ідентифікатор проблеми; він має префікс “Ключ” проекту. Це спосіб JIRA відстежувати / групувати проблеми, що належать до певного проекту.
Тепер ви можете переглянути створену проблему, натиснувши посилання, яке з’явиться у наведеному вище повідомленні.
Додаткові відомості про сторінку створення випуску
1) У верхньому правому куті сторінки 'Створити випуск' буде опція налаштування полів.
Цей параметр можна використовувати для вибору / зміни полів, які ви хотіли б бачити у діалозі створення проблем. Щойно вибір буде зроблений, JIRA запам'ятає зміни і для наступних видань.
два) Унизу сторінки 'Створити випуск' є 'створити іншу'
Коли ви вибираєте цю опцію та натискаєте «Створити» - один раз створюється поточна проблема; JIRA зберігає
Діалогове вікно «Створити випуск» відкриється у розділі «Проект», «Випуск випуску» та інших полях, окрім автоматичного вибору підсумків відповідно до попередніх створених видань.
Цим ми завершуємо тему «Створення випуску в JIRA».
У наступному навчальному посібнику Atlassian JIRA ми дізнаємося про підзавдання та як їх використовувати для конкретних цілей контролю якості.
=> Завітайте сюди, щоб отримати повну серію навчальних посібників JIRA
До вас
Тепер настав час почути вас. Ви стикалися з якимись проблемами, використовуючи JIRA для відстеження помилок?
Як ви думаєте, чи є якась вага опору, який мають випробувальні групи при адаптації JIRA для управління дефектами?
НАЗАД Підручник | НАСТУПНИЙ підручник
Рекомендована література
- Посібник із практичного огляду інструментів відстеження помилок
- Підручник з інтеграції GitLab Jira
- Завантаження та встановлення Jira за допомогою програми встановлення ліцензії Jira
- Підручник з JIRA: Повний практичний посібник із використання JIRA
- Підручник з адміністрування JIRA: Адміністратор JIRA та управління користувачами
- Підручник з інтеграції JIRA та SVN
- Поглиблені підручники Eclipse для початківців
- Підручник JIRA Agile: Як ефективно використовувати JIRA для управління гнучкими проектами