Menu

JIRA Bug Tracking Tool-zelfstudie: JIRA gebruiken als een ticketingtool

jira bug tracking tool tutorial

Probeer Ons Instrument Voor Het Oplossen Van Problemen

JIRA Bug Tracking: Defect Life Cycle in JIRA

Jira downloaden en installeren werd in onze vorige tutorial in detail uitgelegd. De testteams zijn altijd beducht om JIRA voor Defect Management op te halen.

De twijfel is gerechtvaardigd. Het komt voort uit het feit dat, hoewel JIRA bug-trackingtool van toepassing is op IT-bedrijven, het een generiek ticketingsysteem is.

Zelfs voor IT-projecten maakt de populariteit van JIRA bij de ontwikkelingsteams testers en QA-teams ongemakkelijk. Ondanks het comfort of het ongemak hebben de testteams geen andere keuze dan de JIRA bug tracking tool in de meeste bedrijven te gebruiken. Onze Volledige gids over JIRA-training geeft u een uitstekende kennis van de tool.

​ Klik hier voor een complete serie JIRA-zelfstudies

Waarom? Eenvoudige logica Bedrijven willen niet investeren in meerdere tools. Het is gewoon zakelijk gezien verstandig om het gebruik van uw gereedschap te maximaliseren en niet gek te worden door te veel licenties aan te schaffen.

JIRA Bug Tracking Tool

Dus als een ontwikkelteam gebruikmaakt van Atlassian JIRA foutopsporingsprogramma om de vereisten, verbeteringen, taken of gebruikersverhalen bij te houden, waarna het testteam het hoogstwaarschijnlijk moet gebruiken voor het opsporen van fouten.

Maar ontspan ​JIRA's Defect Management is net zo goed als elk ander hulpmiddel ​In sommige situaties kan het zelfs beter zijn.

Dit is de tutorial die je, via screenshots en alles, de toepasbaarheid van JIRA op bug-tracking zal demonstreren.

Wat je leert:

De beste functies van JIRA Bug Tracking Tool

Daar gaan we.

# 1) JIRA behandelt al het werk erin als een probleem

Dus in JIRA zou het creëren van een defect zijn het creëren van een probleem van het type ' Bug ​

een probleem creëren

# 2) Bij defectrapportage moet voor elk probleem de volgende informatie worden geregistreerd:

  • Defect ID
  • Defecte titel
  • Defectbeschrijving (stappen om te reproduceren)
  • Milieu-informatie
  • Screenshot (bijlage)
  • Ernst
  • Wijs het aan iemand toe
  • Toestand- Alle statussen in de levenscyclus van de bug

Alle opties zijn beschikbaar om effectief een defect te kunnen creëren.

Let op de onderstaande rood gemarkeerde velden:

een defect creëren

De twee velden die u hier niet ziet, zijn:

  • Defect ID
  • Toestand

Deze twee velden worden automatisch aangemaakt door JIRA. Alle nummers krijgen een uniek ID toegewezen door JIRA. De status van alle problemen is standaard 'To-Do' of 'Nieuw' in JIRA bij het creëren van een bug.

Daarom alle gebruikelijke faciliteiten voor het melden van defecten zijn ook in JIRA beschikbaar. In feite kunnen meer opties zoals labels, defecten koppelen, schattingsinspanningen worden gebruikt.

# 3) Levenscyclus van defecten:

Alle status van de levenscyclus van bugs zoals in Bugzilla (of een andere populaire bug-tracker ) kan hier ook worden bereikt:

Defecte levenscyclus

Dit zal een beetje aangepast moeten worden door je JIRA-beheerder, maar het is gemakkelijk te doen. Voor degenen die zich geen zorgen willen maken over de aanpassing, kunt u ook niet fout gaan met de standaardinstelling.

# 4) Opmerkingen en samenwerking met het Dev Team

Elk nummer, de updates, de toewijzing van mensen, de opmerkingen die zijn ontvangen van het Dev-team - alles wordt bijgehouden in JIRA onder het activiteitenlogboek.

Dit zorgt voor een betere zichtbaarheid en samenwerking met de ontwikkelteams:

Jira opmerkingen

# 5) Het defect koppelen aan een vereiste om traceerbaarheid mogelijk te maken

Met de koppelingsoptie in de JIRA-probleemvelden kunt u een bepaald probleem aan een ander probleem koppelen. Stel dat als Defect 2 een duplicaat is van Defect 1, u die relatie kunt vaststellen.

Evenzo, als een defect een vereiste blokkeert of gerelateerd is aan een vereiste, kunt u dit aspect zichtbaar maken in JIRA.

Het defect koppelen

De resulterende links verschijnen op de pagina met probleemdetails, zoals hieronder:

probleem details pagina

De relatietypen spreken voor zich en het gebruik van eenvoudige-gewone-alledaagse-taal woorden (zoals gerelateerd aan, veroorzaakt door, etc.) maakt het supergemakkelijk en intuïtief voor elke JIRA-gebruiker om van dit recht gebruik te maken.

# 6) Defecten kunnen worden geïmporteerd vanuit een CSV-bestand

Dit helpt bij het in één keer creëren van problemen in JIRA. Als uw team nieuw is en u niet wilt dat ze problemen rechtstreeks in de tool creëren, kunt u ze de defecten in een Excel-sheet laten rapporteren. Nadat ze zijn beoordeeld en als geldig zijn bevestigd, kunnen ze met deze functionaliteit allemaal tegelijk in de tool worden geïmporteerd.

Op welke manier je het ook gebruikt, dit is een groot pluspunt.

CSV-bestand

# 7) Defecten kunnen worden geëxporteerd naar Word-, XML- en afdrukbare formaten

Defecten geëxporteerd

Dit ondersteunt een betere overdraagbaarheid van uw defectgegevens, vooral handig als u uw defectgegevens wilt delen met mensen die geen JIRA-gebruikers zijn.

# 8) Uitgebreide probleemrapporten:

Als u rapporten nodig heeft, gaat u bovendien naar ' Project - rapporten 'En genereer allerlei soorten rapporten zoals hieronder:

Uitgebreide probleemrapporten

Als we de analyses van JIRA in één woord moeten herzien, is dat fantastisch.

Geavanceerde / ervaren gebruikers van JIRA kunnen ook geavanceerde zoekfilters maken om diepere inzichten te genereren.

Bijvoorbeeld, als u alle defecten wilt bekijken die aan u zijn toegewezen in meerdere projecten (BM en AB), kunt u een JQL-query gebruiken zoals hieronder:

JQL-query

Dus al met al lijkt het opsporen van fouten / defectbeheer in JIRA sterk op, zo niet superieur aan, speciale bugvolgers. Maak u geen zorgen als u er de volgende keer aan moet werken. U bent in goede handen.

Toepasbaarheid van JIRA op testen - een alternatief dilemma

Hoewel dit de ene kant van de medaille is, is er zeker een andere dimensie aan hoe mensen de toepasbaarheid van JIRA op QA of testen zien.

Als je een groep QA's vraagt: 'Wat is JIRA?' - Velen zullen antwoorden dat JIRA een tool voor het opsporen van defecten is. Let wel, ik heb dit van veel senior QA-professionals gehoord. Dit kan komen door het feit dat defectenbeheer / tracking alles is waarvoor ze JIRA hebben gebruikt.

Maar er komt nog veel meer bij kijken. Indien correct gebruikt, kan core JIRA met zijn flexibele mogelijkheden uw one-stop-shop zijn voor projectmanagement op hoog niveau.

Het kan echt het volgen van vereisten en voortgang, het volgen van bugs, het schatten, het volgen van sprints via SCRUM- en KANBAN-borden, rapporteren en samenwerken ondersteunen.

Misschien gebruik je een tool voor één ding, maar probeer de volgende keer een paar dingen rond en over de tool te leren die je zullen helpen het beter te begrijpen en te gebruiken.

Dus als volgende stap je zou een paar andere coole functies van JIRA kunnen verkennen (die misschien niet direct gerelateerd zijn aan het opsporen van bugs) waardoor het misschien je favoriete keuze is.

  • Aanpasbare dashboards
  • Test Management Add-ons
  • Stem en bekijk een probleem
  • Tijdregistratie
  • Agile Project- en Scrumborden
  • Confluence / documentatie ondersteuning integratie, etc.

Een Jira-probleem en verschillende velden maken

Jira-problemen: verschillende soorten Jira-problemen

Jira biedt u zeer eenvoudige manieren om problemen aan te maken / vast te leggen.

Het stelt ons niet alleen in staat om bugs te melden, maar stelt ons ook in staat andere soorten ‘tickets’ of ‘verzoeken’ in te voeren. Het is meer een algemene applicatie voor aanvraagbeheer.

Deze tutorial zal meer uitleggen over probleemtypen in Jira, het creëren van een probleem, verschillende velden op de ‘Create Issue'-pagina en hun details in eenvoudige bewoordingen met een grafische weergave voor een gemakkelijk begrip.

Een JIRA-probleem creëren

Jira problemen

Verschillende organisaties kunnen verschillende soorten problemen hebben, afhankelijk van hun geschiktheid / behoeften. Een Jira-beheerder kan dit veld efficiënt aanpassen.

speel wow gratis privéserver

Problemen kunnen van verschillende typen zijn en hieronder worden de beschrijving / betekenis van de probleemtypen gegeven:

  1. Bug: Dit is elk defect of elke afwijking die in de applicatie wordt aangetroffen.
  2. Verbeteringsverzoek: Het wordt ook wel een wijzigingsverzoek (CR) genoemd. Dit type wordt gebruikt om elke wijziging in de bestaande functionaliteit of helemaal een nieuwe functionaliteit weer te geven.
  3. Taak: Dit is meer een configuratie- of analyseprobleem. Bijvoorbeeld kan het opzetten van de juiste configuraties een taak zijn.
  4. Vraag: Het probleem kan zo simpel zijn als het stellen van een vraag over het gebruik van bepaalde functionaliteit in de applicatie. Dit type wordt vaker gebruikt door de eindklanten.
  5. Episch: Dit is normaal gesproken een enorm probleem dat idealiter wordt opgesplitst in verschillende kleine problemen. Het kan meerdere sprints kosten om het belangrijkste epische probleem in een agile omgeving te voltooien.
  6. Financieel object: Vaak gebruikt project- / productmanagement dit soort problemen om hun financiën bij te houden.
  7. Verhaal: Het volledige gebruikersverhaal over een functie kan een soort probleem zijn.
  8. Testgeval ​ Probleem kan een testcase zijn. Dit type probleem zal beschikbaar zijn zodra Jira is geïntegreerd met plug-ins zoals Zypher.

Een probleem creëren

Ervan uitgaande dat een gebruiker zich heeft aangemeld bij Jira en het gewenste project.

Stap 1:

Klik op de ‘+’ (‘Maken’) werkbalkknop.

Hierdoor wordt een scherm / pagina weergegeven zoals weergegeven in de onderstaande afbeelding:

maak een probleemknop

Selecteer op deze pagina het project en het type probleem / verzoek en klik vervolgens op de knop ‘Volgende’.

Hierdoor wordt de pagina ‘Probleem maken’ geopend, zoals weergegeven in de volgende afbeeldingen:

maak een probleem in JIRA

maak probleem -2

Stap 2:

Voer de verplichte details en andere gegevens zo veel mogelijk in op de pagina ‘Probleem maken’.

Stap 3:

Klik op de knop ‘Maken’. Dit genereert een uniek probleem-ID. ID bestaat uit project-ID aaneengeschakeld met numerieke cijfers.

In het bovenstaande voorbeeld is het gekozen project ‘TestProject’, dus de ID zou kunnen zijn als ‘TESTPROJ1234’.

  • Zodra het probleem is gemaakt, kan het worden doorzocht met behulp van de probleem-ID.

Beschrijving van velden op de pagina 'Probleem maken'

(Afbeeldingen van probleempagina's zijn onderverdeeld in 3 delen voor betere leesbaarheid).

Opmerking ​De Jira-beheerder en / of ontwikkelaar kan de aangepaste velden toevoegen / verwijderen, afhankelijk van de behoeften van de organisatie.

# 1) Samenvatting ​

Dit wordt ook vaker de titel van het nummer genoemd en is een zeer belangrijk gebied van een Jira-nummer.

De titel moet zo uniek en nauwkeurig mogelijk zijn, zodat het probleem kan worden begrepen door naar de titel zelf te kijken. Dit helpt de bug review board en / of producteigenaren om prioriteiten te stellen en het probleem toe te wijzen zonder er diep in te kijken.

# 2) Component / s ​

Naam / namen van de module of het gebied van de applicatie waar het defect is gedetecteerd in het geval van het probleemtype ‘Bug’.

Het kan het gebied zijn waar de wijzigingen nodig zijn in het geval van een CR. Dit is meestal een vervolgkeuzelijst die bestaat uit verschillende modules / componenten die in de applicatie voorkomen. De projectpersoon moet het laten invullen bij de beheerder.

# 3) Beschrijving ​

Bevat doorgaans de stappen om het probleem te reproduceren als het probleemtype een bug is.

In het geval van een uitbreidingsverzoek, moet het gedetailleerd zijn over de nieuwe vereiste die doorgaans wordt genoemd als een verhaal in de agile-terminologie. Idealiter zou dit veld regelmatig moeten worden bijgewerkt tijdens de probleemworkflow.

# 4) Versies repareren ​

Naam van de versie waarin het probleem / verbeteringsverzoek zal worden afgeleverd. Deze waarde wordt typisch ingevuld door de product owner in coördinatie met de scrum master in een agile scrum omgeving.

# 5) Prioriteit ​

Dit veld geeft de ernst van het probleem aan.

Het kan een showstopper zijn, wat betekent dat het testen van applicaties niet door kan gaan in een testfase. Het crashen van een applicatie is ideaal Voorbeeld van een ‘Show Stopper’ (kritiek) probleem.

Bug review board en de producteigenaren hebben het volste recht om de prioriteit van het probleem te wijzigen. Dit veld is een vervolgkeuzelijst met waarden als ‘Laag’, ‘Gemiddeld’ (‘Groot’), ‘Kritiek’, ‘Triviaal’ enz.

# 6) Etiketten ​

Dit veld wordt ingevuld met de teksten die helpen bij het categoriseren van problemen.

# 7) Omgeving ​

Dit is een optioneel veld en de testomgeving wordt hier gespecificeerd.

# 8) Bijlage ​

Ondersteunende afbeeldingen voor het probleem dat wordt gemaakt. De gebruiker kan eenvoudig afbeeldingen slepen en neerzetten of kopiëren en plakken.

# 9) Heeft invloed op versie / s ​

Voor een 'bug'-type probleem moet de productversie hier worden ingevoerd.

Bijvoorbeeld 5.6, 5.7 enz.

# 10) Gekoppelde problemen ​

welk type test wordt gebruikt om te verifiëren dat alle programma's in een applicatie correct samenwerken

Andere relevante problemen kunnen aan het nieuwe probleem worden gekoppeld door een juiste waarde te kiezen in deze vervolgkeuzelijst.

Als het probleem bijvoorbeeld wordt geïntroduceerd door een oplossing van een ander probleem, kan de waarde die moet worden gekozen uit de vervolgkeuzelijst ‘Geïntroduceerd door’ zijn. Dit veld wordt buitengewoon belangrijk als een nieuw defect wordt veroorzaakt door een oplossing of verbetering.

=> Probleem : Na het selecteren van een juiste waarde in ‘Gelinkte problemen’, wordt de relevante probleem-ID hier vermeld.

# 11) Overnemer ​

Het is de naam van de gebruiker die aan het probleem gaat werken.

In het geval van een bug is het bijvoorbeeld de naam van de ontwikkelaar die het probleem oplost. Dit veld wordt doorgaans ingevuld door de producteigenaar of scrummaster. Nogmaals, wie de kwestie toewijst, kan van organisatie tot organisatie verschillen.

=> Door te klikken op ‘Aan mij toewijzen’ (in de rechterhoek van het veld ‘Toegewezen persoon’) wordt het probleem toegewezen aan de ingelogde gebruiker.

# 12) Epische link ​

Kies de relevante link van het epos.

# 13) Sprint ​

De naam van de sprint wordt hier geselecteerd en geeft aan wanneer er aan het probleem zal worden gewerkt. Het kan een toekomstige sprint zijn, zoals besloten door de producteigenaar.

# 14) Team ​

In een Agile-omgeving kunnen er verschillende teams zijn. Het probleem wordt toegewezen aan een van de teams. Deze opdracht wordt meestal gedaan door de product owner of scrum master in afstemming met de product owner.

# 15) Schatting aan het begin ​

Dit veld geeft aan hoeveel tijd er nodig is om het probleem op te lossen.

Vaker genoemd als ‘schatting’. Dit zal ook bestaan ​​uit de vereiste testinspanningen. Het kan worden vermeld in uren / dagen / weken of verhaalpunten. In een agile omgeving tijdens sprintplanning komt het hele team tot een gemeenschappelijke gok.

# 16) Verslaggever ​

Dit bestand wordt door Jira automatisch ingevuld met de naam van de ingelogde gebruiker.

Notitie: We kunnen enkele andere aangepaste velden hebben, zoals hieronder (die niet te zien zijn in de bovenstaande afbeeldingen):

(i) Omgevingstype ​

Geeft aan of er een defect is gevonden in een test- of productieomgeving.

Deze veldwaarden kunnen van organisatie tot organisatie verschillen. Als Jira alleen intern in de organisatie wordt gebruikt om problemen te creëren en niet door eindklanten, bestaat dit veld mogelijk helemaal niet.

(ii) Reproduceerbaar ​

Is het defect reproduceerbaar? Dit veld is niet beschikbaar voor een ander type probleem dan een bug.

(iii) Klant ​

In dit veld wordt de eindklant genoemd die het probleem heeft ingediend. In sommige organisaties waar Jira alleen wordt gebruikt voor interne probleemafhandeling, bestaat dit veld mogelijk niet.

windows 10 wifi standaard gateway niet beschikbaar

Notitie: Alle hierboven beschreven velden behoren tot het tabblad ‘Veld’ op de pagina ‘Probleem maken’, dat meestal het standaardtabblad is. De pagina kan worden aangepast om meer tabbladen te hebben, zoals ’Documentatie’ enz. Die we in onze volgende tutorials zullen behandelen.

Jira biedt ons een effectieve manier om de verschillende soorten problemen gemakkelijk en efficiënt te beheren.

Met veel maatwerk dat tegenwoordig mogelijk is, is Jira de meest populaire keuze geworden.

Hoe worden problemen afgehandeld in JIRA

Werken met JIRA-problemen - Hoe defect in JIRA te loggen

Laten we verder gaan met het maken van een probleem, ervan uitgaande dat de aangemelde gebruiker geen admin is en ons testproject 'Test voor STH' is met componenten - Module 1 en Module 2, versies - versie 1 en versie 2. Sleutel - TFS is al gemaakt.

Problemen behandeld in JIRA

Een JIRA-probleem creëren

Problemen vormen de crux van JIRA, dus om ze te creëren is er een optie direct in de menubalk:

Een JIRA-issue aanmaken 1

Klik op de 'Create Issue' knop. Als alternatief, wanneer u 'c' typt terwijl u op de JIRA-pagina bent, wordt het volgende dialoogvenster ‘Probleem maken’ geopend.

Problemen aanmaken in JIRA 2

Alle velden op deze pagina spreken voor zich. We zullen de belangrijkste hieronder bespreken.

Project : Elk nummer hoort bij een project. U kunt hetzelfde kiezen door op de vervolgkeuzelijst te klikken en het project te kiezen waartoe u dit probleem wilt laten behoren.

Problemen creëren in JIRA 3

Probleem type ​Dit veld toont alle soorten problemen die kunnen worden gemaakt en gevolgd via JIRA. De volgende opties zijn beschikbaar in deze lijst (deze lijst kan verschillen afhankelijk van de instelling die is ingesteld door de beheerder):

Problemen aanmaken in JIRA 4

De items Bug, nieuwe functie, taak, verbetering zijn precies wat hun namen impliceren. Episch en verhaal zijn relevanter voor de agile projecten. Een verhaal is een vereiste in Agile dat van het begin tot het einde moet worden gevolgd. An Epic is een groep verhalen.

Kies indien nodig het probleemtype. Ik ga met 'Bug'.

Overzicht : Geef uw bug hier een titel. Bij correct gebruik kan dit veld zeer succesvol zijn bij het verzenden van veel kritische informatie. Enkele aspecten om hier op te merken:

Een bug / defect is in wezen iets dat niet klopt. De juiste manier om een ​​bugtitel te benaderen, is door kort te definiëren ‘wat is er mis’.

Een voorbeeld van een slechte titel / samenvatting is 'Er zou een optie moeten zijn om de inhoud op het scherm te wissen'. Als ik dit lees, zal mijn eerste reactie zijn: 'Oké, dat moet, maar wat is hier het probleem? Is de optie helemaal niet aanwezig? Of zijn de opties aanwezig en wordt de inhoud niet gewist? '

Er is ook afgesproken dat wanneer ik deze bug open en er in detail naar kijk, ik zeker weet dat ik het antwoord op deze vraag zal vinden.

De nadruk ligt hier echter op het zo efficiënt mogelijk gebruiken van dit veld 'Samenvatting'. Daarom zou een zeer geschikte samenvatting / titel zijn: 'De optie om de inhoud van de inlogpagina van de homepage te wissen, wist de velden niet wanneer erop wordt geklikt.'

In de beperkte ruimte die dit veld biedt, probeer je titel zo te schrijven dat het exacte probleem zonder enige dubbelzinnigheid communiceert.

Prioriteit : Dit veld kan een van de volgende waarden aannemen.

Kies een geschikte optie voor uw bug.

Problemen aanmaken in JIRA 5

Met zetten t : Deze lijst toont de componenten van het project. Kies de juiste keuze.

Betrokken versie en herstelversie​ Deze twee velden geven de versies weer die beschikbaar zijn voor het project. Het is niet nodig dat een bepaald probleem dat u in een bepaalde versie tegenkwam, in dezelfde versie wordt opgelost. In dat soort gevallen kunt u de betrokken versie kiezen als de huidige versie en de fixversie als de volgende.

Deze velden kunnen ook meerdere waarden aannemen. U kunt ervoor kiezen om in te stellen dat een bepaald probleem zowel versie 1 als versie 2 treft, zoals hieronder:

Problemen aanmaken in JIRA 6

Cessionaris : U kunt de naam typen van de persoon aan wie dit probleem verder moet worden overgedragen. U kunt ook uzelf een probleem toewijzen.

Problemen aanmaken in JIRA 7

Omschrijving : Dit is een optioneel tekstveld dat u helpt om zoveel informatie over uw probleem in te voeren als u wilt. In het geval van een bug , is het typisch om dit veld te gebruiken om gedetailleerde informatie te geven over de stappen om het defect te reproduceren.
Het is van het grootste belang om alle informatie te geven.

'Stel dat er twee velden zijn - afhankelijke velden - staat en stad. Wanneer ik Staat kies in de vervolgkeuzelijst, moet in het veld Stad de respectieve steden worden weergegeven in de staat die ik heb gekozen.

Als ik een bug heb opgeworpen als 'De steden zijn leeg voor sommige staten die ik heb geselecteerd'. Het beschrijvingsveld is de plek waar ik op dit defect kan ingaan.

Een voorbeeld van een onvoldoende beschrijving is:

1) Ga naar de site
2) Klik op de adrespagina
3) Voer de andere details in zoals naam, adres enz.
4) Klik op de vervolgkeuzelijst 'Staat'. Kies een staat
5) Klik op de vervolgkeuzelijst 'Stad' - noteer de plaatsnamen

De bovenstaande beschrijving is weliswaar nauwkeurig, maar niet volledig. Als het op dit gebied aankomt, staat aan de kant van het verstrekken van te veel informatie, maar niet te weinig.

Als de volgende stappen aan de beschrijving worden toegevoegd, zal dit gebeuren logischer zijn.

6) Kies de staat als 'Californië' en klik op de vervolgkeuzelijst 'Stad' - alle staten worden weergegeven en de gebruiker kan indien nodig een stad selecteren.
7) Kies de staat als 'Louisiana' en klik op de vervolgkeuzelijst 'Stad' - de lijst zal leeg zijn.
8) De steden zijn ook leeg voor de staten New Jersey en Utah.

Geef dus, nogmaals, de exacte stappen, de exacte gegevens en alle andere informatie die u denkt nodig te hebben om dit veld in te vullen.

Hechting : Elk ondersteunend document kan worden geüpload met een probleem.

Zodra alle informatie naar tevredenheid is ingevoerd, kan het probleem worden aangemaakt door te klikken op de knop 'Maken' aan het einde van het dialoogvenster 'Probleem maken'.

Het probleem wordt aangemaakt en er wordt een bericht weergegeven aan de gebruiker met het probleem-ID:

Problemen aanmaken in JIRA 8

Opmerking: let op de probleem-ID; het wordt voorafgegaan door de 'Sleutel' van het project. Het is JIRA's manier om de issues die bij een bepaald project horen te volgen / groeperen.

U kunt nu de gemaakte uitgave bekijken door op de link te klikken die in het bovenstaande bericht verschijnt.

Aanvullende details over de pagina Probleem maken

1) Er zal een optie voor het configureren van velden in de rechterbovenhoek van de pagina 'Probleem maken' worden gevonden.

Problemen aanmaken in JIRA 9

Deze optie kan worden gebruikt om de velden te kiezen / wijzigen die u zou willen zien in uw dialoogvenster voor het maken van een probleem. Zodra een keuze is gemaakt, onthoudt JIRA de wijzigingen ook voor uw volgende problemen.

twee) Onderaan de pagina 'Probleem maken' staat een 'nog een maken'

Problemen aanmaken in JIRA 10

Wanneer u deze optie kiest en eenmaal op 'Aanmaken' klikt, wordt de huidige uitgave aangemaakt; JIRA behoudt de
Het dialoogvenster “Probleem maken” wordt geopend met Project, Probleemtype en andere velden behalve automatisch geselecteerde samenvatting volgens de eerder gemaakte nummers.

Daarmee sluiten we het onderwerp “Een issue creëren in JIRA” af.

In de volgende Atlassian JIRA-tutorial zullen we leren over subtaken en hoe we deze kunnen gebruiken voor specifieke QA-doeleinden.

​ Bezoek hier voor complete JIRA Tutorials-serie

Terug naar jou

Nu is het tijd om van u te horen. Heeft u problemen ondervonden bij het gebruik van JIRA voor het opsporen van fouten?

Denk je dat de weerstand die testteams hebben bij het aanpassen van JIRA voor defectmanagement, enig gewicht heeft?

PREV-zelfstudie ​ VOLGENDE zelfstudie

Aanbevolen literatuur

^