Меню

Инструкция за инструмента за проследяване на грешки в JIRA: Как да използваме JIRA като инструмент за билети

jira bug tracking tool tutorial

Опитайте Нашия Инструмент За Премахване На Проблемите

Проследяване на грешки в JIRA: Жизнен цикъл на дефекти в JIRA

Изтегляне и инсталиране на Jira беше обяснено подробно в предишния ни урок. Тестовите екипи винаги се притесняват да вземат JIRA за управление на дефекти.

Съмнението е оправдано. Това произтича от факта, че въпреки че инструментът за проследяване на грешки JIRA е приложим за ИТ бизнеса, той е обща система за продажба на билети.

Дори и за ИТ проекти, популярността на JIRA сред екипите за разработка прави тестерите и екипите за QA неудобни. Въпреки комфорта или дискомфорта, тестовите екипи нямат друг избор, освен да използват инструмента за проследяване на грешки JIRA в повечето компании. Нашите Пълно ръководство за обучение на JIRA ще ви даде отлични познания за инструмента.

=> Щракнете тук за пълна серия уроци по JIRA

Защо? Проста логика Компаниите не искат да инвестират в множество инструменти. Просто има добър бизнес смисъл да увеличите максимално използването на инструмента си и да не полудявате от закупуването на твърде много лицензи.

Инструмент за проследяване на грешки JIRA

Така че, ако екипът за разработка използва Atlassian JIRA инструмент за проследяване на грешки за проследяване на неговите изисквания, подобрения, задачи или потребителски истории, тогава тестовият екип, най-вероятно, трябва да го използва за проследяване на грешки.

Но, отпуснете се . Управлението на дефектите на JIRA е също толкова добро, колкото всеки друг инструмент . Всъщност в някои ситуации може дори да е по-добре.

Това е урокът, който ще ви демонстрира чрез екранни снимки и всичко, приложимостта на JIRA за проследяване на грешки.

Какво ще научите:

Най-добрите характеристики на инструмента за проследяване на грешки JIRA

Ето ни.

# 1) JIRA третира цялата работа в нея като проблем

Така че в JIRA създаването на дефект би означавало да се създаде проблем от типа „ Буболечка ”.

създайте проблем

# 2) Отчитането на дефекти се нуждае от следната информация, записана за всеки брой:

  • Идентификационен номер на дефект
  • Заглавие на дефект
  • Описание на дефекта (стъпки за възпроизвеждане)
  • Информация за околната среда
  • Снимка на екрана (прикачен файл)
  • Тежест
  • Възложете го на някой
  • Състояние- Всички състояния в жизнения цикъл на грешките

Налични са всички опции, за да можете ефективно да създадете дефект.

Моля, обърнете внимание на полетата, маркирани в червено по-долу:

създават дефект

Двете полета, които не виждате тук, са:

  • Идентификационен номер на дефект
  • Състояние

Тези две полета се създават автоматично от JIRA. Всички издания ще имат уникален идентификатор, присвоен им от JIRA. Състоянието на всички проблеми е „Задачи“ или „Нови“ в JIRA по подразбиране при създаване на грешка.

Следователно, всички общи съоръжения за докладване на дефекти са налични и в JIRA. Всъщност могат да се използват повече опции като етикети, свързващи дефекти, оценка на усилията.

# 3) Жизнен цикъл на дефекти:

Всички състояния на жизнения цикъл на грешки, както в Bugzilla (или която и да е друга популярен инструмент за проследяване на грешки ) може да се осъществи и тук:

Жизнен цикъл на дефекти

Това ще се нуждае от малко персонализиране от вашия администратор на JIRA, но е лесно да се направи. За тези, които не искат да се занимават с персонализирането, не можете да сгрешите и с настройката по подразбиране.

# 4) Коментари и сътрудничество с екипа на разработчиците

Всеки брой, неговите актуализации, назначение на хора, коментари, получени от екипа на Dev - всичко се проследява в JIRA под дневника на активността.

Това позволява по-добра видимост и сътрудничество с разработчиците:

Коментари на Джира

# 5) Свързване на дефекта с изискване за проследяване

Опцията за връзка в полетата за издание на JIRA ви позволява да свържете конкретен проблем с друг. Да кажем, че ако Дефект 2 е дубликат на Дефект 1, можете да установите тази връзка.

По същия начин, ако дефект блокира изискване или е свързан с изискване - можете да направите този аспект видим в JIRA.

Свързване на дефекта

Получените връзки ще се появят на страницата с подробности за проблема, както е показано по-долу:

страница с подробности за изданието

Типовете взаимоотношения се обясняват и използват прост-общ-ежедневен-език думи (като свързани с, причинени от и т.н.) прави супер лесно и интуитивно за всеки потребител на JIRA да използва това право.

# 6) Дефектите могат да бъдат импортирани от CSV файл

Това помага за груповото създаване на проблеми в JIRA наведнъж. Освен това, ако вашият екип е нов и не искате да създават проблеми директно в инструмента, можете да ги накарате да докладват за дефектите в Excel лист. След като бъдат прегледани и потвърдени като валидни, те могат да бъдат импортирани наведнъж в инструмента, използвайки тази функционалност.

По който и начин да го използвате, това е голям плюс.

CSV файл

# 7) Дефектите могат да бъдат експортирани във формати Word, XML и за печат

Изнесени дефекти

Това поддържа по-добра преносимост на вашите данни за дефекти, особено полезно, ако искате да споделите вашите данни за дефекти с хора, които не са потребители на JIRA.

# 8) Изчерпателни доклади за проблемите:

Освен това, ако имате нужда от отчети, отидете на „ Проект - отчети ”И генерирайте всякакви отчети, както е показано по-долу:

Изчерпателни доклади за издаването

Ако трябва да прегледаме анализа на JIRA с една дума, това е фантастично.

Потребителите на напреднали / мощни потребители на JIRA също могат да създават разширени филтри за търсене, за да генерират по-задълбочена информация

Например, ако искате да разгледате всички дефекти, присвоени ви в множество проекти (BM и AB), можете да използвате JQL заявка като по-долу:

JQL заявка

Така че като цяло проследяването на грешки / управлението на дефектите в JIRA е много подобно, ако не и по-добро от специалните проследявачи на грешки. Следващият път, когато трябва да работите по него, не се притеснявайте. Вие сте в добри ръце.

Приложимост на JIRA за тестване - алтернативна дилема

Въпреки че това е едната страна на монетата, определено има друго измерение в начина, по който хората гледат на приложимостта на JIRA към QA или тестване.

Когато попитате група QA, „Какво е JIRA?“ - мнозина ще отговорят, че JIRA е инструмент за проследяване на дефекти. Имайте предвид, че чух това от много висши професионалисти по QA. Това може да се дължи на факта, че управлението / проследяването на дефекти е всичко, за което може да са използвали JIRA.

Но има много повече. Когато се използва правилно, основният JIRA със своите гъвкави възможности може да бъде вашето обслужване на едно гише за управление на проекти на високо ниво.

Той наистина може да поддържа проследяване и напредък на изискванията, проследяване на грешки, оценка, проследяване на спринта чрез табла SCRUM & KANBAN, докладване и сътрудничество.

Може да използвате инструмент за едно нещо, но следващия път опитайте и научете няколко неща наоколо и за инструмента, който ще ви помогне да го разберете и използвате по-добре.

Така че, като следваща стъпка, можете да разгледате няколко други страхотни функции на JIRA (които може да не са пряко свързани с проследяването на грешки), които може да го направят вашият избор.

  • Персонализиращи се табла за управление
  • Добавки за управление на тестове
  • Гласувайте и гледайте брой
  • Проследяване на времето
  • Agile Project и Scrum дъски
  • Интеграция на подкрепа за сливане / документация и др.

Създаване на издание на Jira и различни полета

Проблеми с Jira: Различни видове проблеми с Jira

Jira ви дава много лесни начини за създаване / регистриране на проблеми.

Това не само ни позволява да подаваме грешки, но ни дава възможност и за други видове „билети“ или „заявки“. Това е по-скоро общо приложение за управление на заявки.

Този урок ще обясни повече за типовете издания в Jira, създаването на издание, различни полета на страницата „Създаване на издание“ и техните подробности с прости изрази с изобразително представяне за вашето лесно разбиране.

Създаване на JIRA проблем

Jira Issues

Различните организации могат да имат различни видове проблеми в зависимост от тяхната пригодност / нужди. Администратор на Jira може ефективно да персонализира това поле.

Изданията могат да бъдат от различен тип, а по-долу са описанието / значението на типовете издания:

  1. Буболечка: Това е всеки дефект или отклонение, установено в приложението.
  2. Искане за подобрение: Той е известен също като искане за промяна (CR). Този тип се използва за изобразяване на всяка промяна в съществуващата функционалност или изцяло нова функционалност.
  3. Задача: Това е по-скоро проблем с конфигурацията или анализа. Например , създаването на правилни конфигурации може да бъде задача.
  4. Въпрос: Проблемът може да бъде толкова прост, колкото задаването на въпрос за това как да използвате някои функции в приложението. Този тип се използва по-често от крайните клиенти.
  5. Епичен: Това обикновено е огромен проблем, който в идеалния случай се разделя на няколко малки проблема. Може да отнеме няколко спринта, за да завършите основния епичен въпрос в пъргава среда.
  6. Финансов обект: Често управлението на проекти / продукти използва този тип издания, за да проследява своите финанси.
  7. История: Цялата потребителска история за дадена функция може да бъде вид проблем.
  8. Тестов случай : Изданието може да бъде тестов случай. Този тип издание ще бъде налице, след като Jira бъде интегрирана с приставки като Zypher.

Създаване на издание

Ако приемем, че потребител е влязъл в Jira и желания проект.

Етап 1:

Кликнете върху бутона „+“ („Създаване“) на лентата с инструменти.

Това ще покаже екран / страница, както е показано на изображението по-долу:

бутон за създаване на проблем

На тази страница изберете проект и тип на издаване / заявка и след това кликнете върху бутона „Напред“.

Това ще отвори страницата „Създаване на проблем“, както е показано на следните изображения:

Въпроси и отговори за интервюта на бизнес анализатор

създайте издание в JIRA

създайте брой -2

Стъпка 2:

Въведете задължителните подробности и други данни колкото е възможно повече на страницата „Създаване на проблем“.

Стъпка 3:

Кликнете върху бутона „Създаване“. Това ще генерира уникален идентификационен номер на изданието. ИД ще се състои от идентификатор на проект, обединен с цифрови цифри.

В горния пример избраният проект е „TestProject“, следователно идентификаторът може да бъде като „TESTPROJ1234“.

  • След като проблемът е създаден, след това той може да бъде търсен с помощта на идентификатора на изданието.

Описание на полетата на страницата „Създаване на проблем“

(Създайте изображения на страници с проблеми са разделени на 3 части за по-добра четливост).

Забележка :Администраторът и / или разработчикът на Jira може да добавя / премахва персонализираните полета в зависимост от нуждите на организацията.

# 1) Обобщение :

Това също се нарича по-често като заглавие на изданието и е много важно поле на издание на Jira.

Заглавието трябва да бъде възможно най-уникално и прецизно, така че като погледнете самото заглавие, проблемът може да бъде разбран. Това помага на борда за преглед на грешки и / или собствениците на продукти да определят приоритетите и да задават проблема, без да се вглеждат дълбоко в него.

# 2) Компонент / и :

Име (а) на модула или областта на приложението, където се открива дефектът в случай на тип на проблема „Bug“.

Това може да е областта, в която се изискват промените в случай на CR. Това обикновено е падащо меню, състоящо се от различни модули / компоненти, които съществуват в приложението. Лицето на проекта трябва да го попълни от администратора.

# 3) Описание :

Обикновено трябва да съдържа стъпките за възпроизвеждане на проблема, ако видът на проблема е грешка.

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

# 4) Fix версии :

Име на версията, в която ще бъде доставена заявката за издаване / подобрение. Тази стойност обикновено се попълва от собственика на продукта в координация с главния скрам в гъвкава скрам среда.

# 5) Приоритет :

Това поле показва критичността на проблема.

Това може да бъде запушалка на шоуто, което означава, че тестването на приложения не може да продължи във фаза на тестване. Сривът на приложение е идеален Пример на „Show Stopper“ (критичен) брой.

Съветът за преглед на грешки и собствениците на продукти имат пълното право да променят приоритета на проблема. Това поле е падащ списък със стойности като „Ниско“, „Средно“ („Основно“), „Критично“, „Тривиално“ и т.н.

# 6) Етикети :

Това поле се въвежда с текстовете, които ще помогнат при категоризирането на проблемите.

# 7) Околна среда :

Това е незадължително поле и тук е посочена тестовата среда.

# 8) Прикачен файл :

Поддържащи изображения за създадения проблем. Потребителят може просто да плъзга и пуска изображения или да копира и поставя.

# 9) Засяга версия / и :

За издание тип „бъг“ тук трябва да се въведе версията на продукта.

Например 5.6, 5.7 и т.н.

# 10) Свързани проблеми :

Други важни проблеми могат да бъдат свързани с новия брой, като изберете подходяща стойност от това падащо меню.

Например, ако проблемът е въведен чрез поправка на друг проблем, тогава стойността, която трябва да бъде избрана от падащото меню, може да бъде „Въведено от“. Това поле става изключително важно, ако нов дефект се задейства от някаква корекция или подобрение.

=> Издание : След като изберете правилна стойност в „Свързани проблеми“, тук се споменава съответния идентификатор на проблема.

# 11) Цесионер :

Това е името на потребителя, който ще работи по въпроса.

Например, в случай на грешка, името на разработчика ще реши проблема. Това поле обикновено се попълва от собственика на продукта или от scrum master. Отново кой възлага проблема може да варира в различните организации.

=> Щракването върху „Assign to me“ (намира се в десния ъгъл на полето „Assignee“) ще присвои проблема на влезлия потребител.

# 12) Epic Link :

Изберете съответната връзка на епоса.

# 13) Спринт :

Тук е избрано името на спринта, което указва кога ще се работи по изданието. Това може да бъде бъдещ спринт според решението на собственика на продукта.

# 14) Екип :

В Agile среда може да има различни екипи. Изданието е възложено на един от екипите. Това възлагане обикновено се извършва от собственика на продукта или майстора на скрама в координация със собственика на продукта.

# 15) Оценка в началото :

Това поле ще посочи колко време ще е необходимо за разрешаване на проблема.

По-често се нарича „предположение“. Това ще се състои и от необходимите усилия за тестване. Може да се спомене в часове / дни / седмици или сюжетни точки. В пъргава обстановка по време на планиране на спринта целият екип стига до общо предположение.

# 16) Репортер :

Това поле се попълва автоматично от Jira с името на влезлия потребител.

Забележка: Може да имаме някои други персонализирани полета, както по-долу (които не се виждат на горните изображения):

(i) Тип на околната среда :

Показва дали е открит дефект в тестова или производствена среда.

Стойностите на това поле могат да варират при различните организации. Ако Jira се използва за създаване на проблеми само вътрешно в организацията, а не от крайни клиенти, това поле може изобщо да не съществува.

(ii) Възпроизводими :

Възпроизводим ли е дефектът? Това поле няма да бъде достъпно за друг вид издание, освен за грешка.

(iii) Клиент :

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

Забележка: Всички гореописани полета принадлежат към раздела „Поле“ на страницата „Създаване на проблем“, който обикновено е раздел по подразбиране. Страницата може да бъде персонализирана, за да има повече раздели като „Документация“ и др., Които ще разгледаме в следващите ни уроци.

Jira ни дава ефективен начин за лесно и ефективно управление на различните видове проблеми.

С много персонализации, които са възможни в наши дни, Jira се превърна в най-популярния избор.

Как се обработват проблемите в JIRA

Работа с проблеми на JIRA - Как да регистрирам дефект в JIRA

Нека да преминем към създаването на проблем, ако приемем, че влезлият потребител не е администратор и нашият тестов проект е „Тест за STH“ с компоненти - Модул 1 и Модул 2, версии - версия 1 и Версия 2. Ключ - TFS вече е създаден.

Проблеми, обработени в JIRA

Създаване на JIRA брой

Проблемите формират същността на JIRA, така че за да ги създадете, има опция точно в лентата с менюта:

Създаване на JIRA брой 1

Кликнете върху бутона „Създаване на издание“. Като алтернатива, когато напишете „c“, докато сте на страницата JIRA, се отваря следният диалог „Създаване на проблем“.

Създаване на проблеми в JIRA 2

Всички полета на тази страница са обяснителни. По-долу ще обсъдим най-важното.

Проект : Всеки брой принадлежи на проект. Можете да изберете същото, като кликнете върху падащото меню и изберете проекта, към който искате да принадлежи този проблем.

Създаване на проблеми в JIRA 3

Вид издание :Това поле показва всички видове проблеми, които могат да бъдат създадени и проследявани чрез JIRA. В този списък са налични следните опции (този списък може да се различава в зависимост от настройката, зададена от администратора):

Създаване на проблеми в JIRA 4

Елементите Грешка, нова функция, задача, подобрение са точно това, което предполагат имената им. Епосът и историята са по-подходящи за гъвкавите проекти. Историята е изискване в Agile, което трябва да се проследява от началото до края. Epic е група от истории.

Изберете вида на изданието според нуждите. Ще отида с “Bug”.

Обобщение : Дайте заглавие на грешката си тук. Когато се използва правилно, това поле може да бъде много успешно при предаване на много критична информация. Някои аспекти, които трябва да отбележите тук:

Грешка / дефект по същество е нещо, което не е правилно. Правилният начин да се обърнете към заглавието на грешка е да дефинирате сбито „какво не е наред“.

Пример на лошо заглавие / резюме е „Трябва да има опция за изчистване на съдържанието на екрана“. Когато чета това, първоначалната ми реакция ще бъде - „Добре, трябва да има - но какъв е проблемът тук? Възможността изобщо не присъства? Или опциите присъстват и не изчистват съдържанието? “

Също така е договорено, че когато отворя тази грешка и я разгледам подробно, съм сигурен, че ще намеря отговора на този въпрос.

Акцентът тук обаче е да се използва това поле „Обобщение“ по най-ефективния начин. Следователно много подходящо резюме / заглавие би било „Опцията за изчистване на съдържанието на началната страница за вход не изчиства полетата при щракване“.

В ограниченото пространство, което предоставя това поле, опитайте се да напишете заглавието си по начин, който съобщава точния проблем, без никакви неясноти.

Приоритет : Това поле може да приеме една от следните стойности.

Изберете подходяща опция за вашата грешка.

Създаване на проблеми в JIRA 5

С слагам т : Този списък ще покаже компонентите на проекта. Изберете подходящо.

Засегната версия и Fix версия: Тези две полета ще показват версиите, налични за проекта. Не е необходимо даден проблем, който сте срещнали в определена версия, да бъде отстранен в същата. В такива случаи можете да изберете засегнатата версия като текуща версия и версията за поправяне като следващата.

Също така тези полета могат да приемат множество стойности. Можете да изберете да зададете, че даден проблем засяга както версия 1, така и версия 2, както е показано по-долу:

Създаване на проблеми в JIRA 6

Цесионер : Можете да въведете името на лицето, на което този проблем трябва да бъде предаден допълнително. Можете също да зададете проблем на себе си.

Създаване на проблеми в JIRA 7

Описание : Това е незадължително текстово поле, което ви помага да въведете толкова информация, колкото искате за вашия проблем. В случай на a буболечка , типично е да използвате това поле, за да предоставите подробна информация за стъпките за възпроизвеждане на дефекта.
Изключително важно е да се предостави цялата информация.

„Да кажем, има две полета - зависими - Щат и Град. Когато избирам държава от падащото меню, в полето City трябва да се показват съответните градове в държавата, която съм избрал.

Ако повдигна грешка като „Градовете са празни за някои щати, които избрах“. Полето за описание е мястото за мен да разгледам този дефект.

Пример за недостатъчно описание е:

1) Влезте в сайта
2) Щракнете върху адресната страница
3) Въведете останалите подробности като име, адрес и т.н.
4) Щракнете върху падащото меню „Държава“. Изберете държава
5) Кликнете върху падащото меню „Град“ - отбележете имената на градовете

Горното описание, макар и точно, не е пълно. Когато става въпрос за тази област, е от страната на предоставянето на твърде много информация, но не и на твърде малко.

Ако към описанието се добавят следните стъпки, това ще стане имат повече смисъл.

6) Изберете щат като „Калифорния“ и кликнете върху падащото меню „Град“ - всички щати ще бъдат показани и потребителят може да избере град според нуждите.
7) Изберете щат като „Луизиана“ и кликнете върху падащото меню „Град“ - списъкът ще бъде празен.
8) Градовете са празни и за щатите Ню Джърси и Юта.

Така че, за да повторите, предоставете точните стъпки, точните данни и всяка друга информация, която смятате, че е необходима за попълване на това поле.

Прикачен файл : Всеки поддържащ документ може да бъде качен с проблем.

След като цялата информация бъде въведена за ваше удовлетворение, изданието може да бъде създадено, като кликнете върху бутона „Създаване“ в края на диалога „Създаване на издание“.

Проблемът се създава и на потребителя се показва съобщение с идентификатор на проблема:

Създаване на проблеми в JIRA 8

Забележка: обърнете внимание на идентификационния номер на изданието; той е с префикс от „Ключ“ на проекта. Това е начинът на JIRA да проследява / групира проблемите, които принадлежат към определен проект.

Вече можете да видите създадения проблем, като щракнете върху връзката, която се появява в горното съобщение.

Допълнителни подробности за страницата за създаване на издание

1) В горния десен ъгъл на страницата „Създаване на проблем“ ще има опция за конфигуриране на полета.

Създаване на проблеми в JIRA 9

Тази опция може да се използва за избор / промяна на полетата, които искате да видите в диалога за създаване на проблем. След като бъде направен избор, JIRA ще запомни промените и за следващите ви издания.

две) В долната част на страницата „Създаване на издание“ има „създаване на друг“

Създаване на проблеми в JIRA 10

Когато изберете тази опция и щракнете върху „Създаване“ - веднъж се създава текущият проблем; JIRA поддържа
Диалогът „Създаване на издание“ се отваря с проект, тип на изданието и други полета, с изключение на автоматичното обобщение, избрано според предишните създадени издания.

С това завършваме темата „Създаване на проблем в JIRA“.

В следващия урок на Atlassian JIRA ще научим за подзадачи и как да ги използваме за специфични цели на QA.

=> Посетете тук за пълна серия уроци по JIRA

Над вас

Сега е време да се чуем. Сблъсквали ли сте се с някакви предизвикателства, използвайки JIRA за проследяване на грешки?

Смятате ли, че има някаква тежест за съпротивлението, което тестовите екипи имат при адаптирането на JIRA за управление на дефекти?

PREV Урок | СЛЕДВАЩ урок

Препоръчително четене

^