jira bug tracking tool tutorial
JIRA Bug Tracking: Defekt Livscyklus i JIRA
Jira Download og installation blev forklaret detaljeret i vores tidligere tutorial. Testholdene er altid bange for at hente JIRA til defekthåndtering.
Tvivlen er berettiget. Det stammer fra det faktum, at selvom JIRA bug tracking tool er anvendeligt til it-virksomheder, er det et generisk billetsystem.
Selv for it-projekter gør JIRAs popularitet hos Development teams testere og QA teams ubehagelige. På trods af komforten eller ubehaget har testteamene intet andet valg end at bruge JIRA bug tracking-værktøjet i de fleste virksomheder. Vores Komplet guide til JIRA træning vil give dig en fremragende viden om værktøjet.
=> Klik her for komplette JIRA-vejledningsserier
Hvorfor? Enkel logik- Virksomheder ønsker ikke at investere i flere værktøjer. Det giver bare god forretningsmæssig mening at maksimere din værktøjsudnyttelse og ikke blive skør med at købe for mange licenser.
Så hvis et udviklingsteam bruger Atlassian JIRA fejlsporingsværktøj til at spore dets krav, forbedringer, opgaver eller brugerhistorier, så er testteamet sandsynligvis nødt til at bruge det til bugsporing.
Men slap af . JIRAs Defect Management er lige så god som ethvert andet værktøj . Faktisk kunne det i nogle situationer endda være bedre.
Dette er vejledningen, der vil demonstrere for dig via skærmbilleder og alt, JIRAs anvendelighed til sporing af fejl.
Hvad du vil lære:
- De bedste funktioner i JIRA Bug Tracking Tool
- # 1) JIRA behandler alt arbejde inde i det som et emne
- # 2) Fejlrapportering har brug for følgende oplysninger registreret for hvert problem:
- # 3) Defekt livscyklus:
- # 4) Kommentarer og samarbejde med Dev Team
- # 5) Kæde af manglen til et krav for at muliggøre sporbarhed
- # 6) Fejl kan importeres fra en CSV-fil
- # 7) Fejl kan eksporteres til Word-, XML- og udskrivbare formater
- # 8) Omfattende problemrapporter:
- Anvendelighed af JIRA til testning - et alternativt dilemma
- Oprettelse af en Jira-udgave og forskellige felter
- Hvordan håndteres problemer i JIRA
De bedste funktioner i JIRA Bug Tracking Tool
Nu sker det.
# 1) JIRA behandler alt arbejde inde i det som et emne
Så i JIRA ville det være at skabe et problem af typen 'at skabe en defekt' Insekt ”.
# 2) Fejlrapportering har brug for følgende oplysninger registreret for hvert problem:
- Defekt-id
- Defekt titel
- Fejlbeskrivelse (trin til reproduktion)
- Miljøoplysninger
- Skærmbillede (vedhæftet fil)
- Alvorlighed
- Tildel det til nogen
- Status- Alle status i bugens livscyklus
Alle muligheder er tilgængelige for at kunne skabe en defekt effektivt.
Bemærk felterne fremhævet med rødt nedenfor:
De to felter, du ikke ser her, er:
- Defekt-id
- Status
Disse to felter oprettes automatisk af JIRA. Alle udgaver vil have et unikt ID tildelt af JIRA. Status for alle problemer er 'To-Do' eller 'New' i JIRA som standard ved oprettelse af en fejl.
Derfor, alle de fælles faciliteter til rapportering af mangler er også tilgængelige i JIRA. Faktisk kan flere muligheder såsom etiketter, sammenkædningsfejl og estimering af indsats bruges.
# 3) Defekt livscyklus:
Alle fejl livscyklus statuser som i Bugzilla (eller andre populær bug tracker ) kan også opnås her:
Dette kræver en lille smule tilpasning af din JIRA-administrator, men det er let at gøre. For dem ønsker du ikke at bekymre dig om tilpasningen, du kan ikke gå galt med standardopsætningen også.
# 4) Kommentarer og samarbejde med Dev Team
Hvert nummer, dets opdateringer, personaletildeling, kommentarer modtaget fra Dev-teamet - alt spores i JIRA under aktivitetsloggen.
Dette giver bedre synlighed og samarbejde med udviklingsteamene:
# 5) Kæde af manglen til et krav for at muliggøre sporbarhed
Linkindstilling i JIRA-felterne giver dig mulighed for at linke et bestemt problem til et andet. Lad os sige, at hvis Fejl 2 er en duplikat af Fejl 1, kan du etablere det forhold.
Tilsvarende, hvis en defekt blokerer for et krav eller er relateret til et krav - kan du gøre dette aspekt synligt i JIRA.
De resulterende links vises på siden med udgaveoplysninger som nedenfor:
Forholdstyperne er selvforklarende og brugen af simpelt almindeligt-hverdagssprog ord (som f.eks. vedrører, forårsaget af osv.) gør det super nemt og intuitivt for enhver JIRA-bruger at bruge denne ret.
# 6) Fejl kan importeres fra en CSV-fil
Dette hjælper bulk oprettelsen af problemer i JIRA på én gang. Hvis dit team er nyt, og du ikke vil have dem til at oprette problemer direkte i værktøjet, kan du også få dem til at rapportere manglerne i et excel-ark. Når de er gennemgået og bekræftet som gyldige, kan de importeres på én gang til værktøjet ved hjælp af denne funktionalitet.
Uanset hvilken måde du bruger det, er dette et stort plus.
# 7) Fejl kan eksporteres til Word-, XML- og udskrivbare formater
Dette understøtter bedre bærbarhed af dine defektdata, især nyttigt, hvis du vil dele dine defektdata med mennesker, der ikke er JIRA-brugere.
# 8) Omfattende problemrapporter:
Desuden, hvis du har brug for rapporter, gå til “ Projekt - rapporter ”Og generer alle mulige rapporter som nedenfor:
Hvis vi skal gennemgå JIRAs analyser i et ord, er det fantastisk.
Avancerede / kraftige brugere af JIRA kan også oprette avancerede søgefiltre for at generere dybere indsigt.
For eksempel, Hvis du vil se på alle de mangler, der er tildelt dig på tværs af flere projekter (BM og AB), kan du bruge en JQL-forespørgsel som nedenfor:
Så alt i alt er bug tracking / defect management i JIRA meget ens, hvis ikke bedre end dedikerede bug trackers. Næste gang du skal arbejde på det, skal du ikke bekymre dig. Du er i gode hænder.
Anvendelighed af JIRA til testning - et alternativt dilemma
Selvom dette er den ene side af mønten, er der bestemt en anden dimension til, hvordan folk ser anvendeligheden af JIRA på QA eller test.
Når du spørger en gruppe QA'er, “Hvad er JIRA?” - Mange vil svare, at JIRA er et værktøj til mangelfølgning. Husk, jeg har hørt dette fra mange senior QA-fagfolk. Dette kan skyldes, at defektstyring / sporing er alt, hvad de måske har brugt JIRA til.
Men der er meget mere til det. Når det bruges rigtigt, kan kernen JIRA med sine smidige funktioner være din one-stop-shop for projektledelse på højt niveau.
Det kan virkelig understøtte kravsporing og fremskridt, bug tracking, estimering, sprint tracking via SCRUM & KANBAN boards, rapportering og samarbejde.
Du bruger muligvis et værktøj til en ting, men prøv næste gang at lære et par ting omkring og om værktøjet, der hjælper dig med at forstå og bruge det bedre.
Så som et næste trin, du kunne udforske et par andre seje funktioner i JIRA (som måske ikke direkte er relateret til bug tracking), der muligvis gør det til dit valg.
- Kan tilpasses Dashboards
- Add Management til testhåndtering
- Stem og se et problem
- Tidssporing
- Agile Project og Scrum boards
- Integration af sammenløb / dokumentation osv.
Oprettelse af en Jira-udgave og forskellige felter
Jira Issues: Forskellige typer Jira Issues
Jira giver dig meget enkle måder at oprette / logge problemer på.
Det giver os ikke kun mulighed for at arkivere fejl, men det giver os også mulighed for andre former for 'billetter' eller 'anmodninger'. Det er mere en generel applikationsadministrationsapplikation.
Denne tutorial forklarer mere om problemtyper i Jira, oprettelse af et problem, forskellige felter på siden 'Opret problem' og deres detaljer i enkle termer med billedlig gengivelse for din nemme forståelse.
Jira-spørgsmål
Forskellige organisationer kan have forskellige typer spørgsmål afhængigt af deres egnethed / behov. En Jira-administrator kan effektivt tilpasse dette felt.
hvordan man opretter et computerprogram til begyndere
Problemer kan være af forskellige typer, og nedenfor er beskrivelsen / betydningen af problemtyperne:
- Insekt: Dette er enhver fejl eller afvigelse, der findes i applikationen.
- Forbedring af forbedring: Det er også kendt som en ændringsanmodning (CR). Denne type bruges til at skildre enhver ændring i den eksisterende funktionalitet eller helt en ny funktionalitet.
- Opgave: Dette er mere et konfigurations- eller analyseproblem. For eksempel , opsætning af korrekte konfigurationer kan være en opgave.
- Spørgsmål: Problemet kan være så simpelt som at stille et spørgsmål om, hvordan man bruger en vis funktionalitet i applikationen. Denne type bruges oftere af slutkunderne.
- Episk: Dette er normalt et stort problem, som ideelt set er opdelt i flere små problemer. Det kan tage flere sprints at afslutte det største episke problem i et smidigt miljø.
- Finansielt objekt: Ofte bruger projekt- / produktstyring denne type spørgsmål til at spore deres økonomi.
- Historie: Hele brugerhistorien om en funktion kan være en type problem.
- Test sag : Problemet kan være en prøvesag. Denne type problemer vil være tilgængelig, når Jira er integreret med plug-ins som Zypher.
Oprettelse af et problem
Forudsat at en bruger har logget ind på Jira og det ønskede projekt.
Trin 1:
Klik på knappen '+' ('Opret') på værktøjslinjen.
Dette viser en skærm / side som vist i nedenstående billede:
På denne side skal du vælge projekt- og udgave- / anmodningstype og derefter klikke på knappen 'Næste'.
Dette åbner siden 'Opret problem' som vist på følgende billeder:
Trin 2:
Indtast de obligatoriske detaljer og andre data så meget som muligt på siden 'Opret problem'.
Trin 3:
Klik på knappen 'Opret'. Dette genererer et unikt problem-id. ID vil bestå af projektidentifikator sammenkædet med numeriske cifre.
I ovenstående eksempel er det valgte projekt 'TestProject', hvorved ID'et kan være som 'TESTPROJ1234'.
- Når problemet er oprettet, kan det derefter søges ved hjælp af problem-id'et.
Beskrivelse af felter på siden 'Opret problem'
(Opret billeder til emnesider er opdelt i 3 dele for bedre læsbarhed).
Bemærk :Jira-administrator og / eller udvikler kan tilføje / fjerne de brugerdefinerede felter afhængigt af organisationens behov.
# 1) Resume :
Dette kaldes også oftere som titlen på udgaven og er et meget vigtigt felt i et Jira-emne.
Titlen skal være så unik og præcis som muligt, så spørgsmålet kan forstås ved at se på selve titlen. Dette hjælper fejlanmeldelseskortet og / eller produktejere med at prioritere og tildele problemet uden at se dybt ind i det.
# 2) Komponent (er) :
Navn (er) på modulet eller området i applikationen, hvor defekten opdages i tilfælde af problemtypen 'Bug'.
Det kan være det område, hvor ændringerne kræves i tilfælde af en CR. Dette er normalt en drop-down bestående af forskellige moduler / komponenter, der findes i applikationen. Projektperson skal få det udfyldt fra administratoren.
# 3) Beskrivelse :
Typisk skal indeholde trinnene til at gengive problemet, hvis emnetypen er en fejl.
I tilfælde af en anmodning om forbedring skal det detaljeres om det nye krav, der typisk kaldes som en historie i den agile terminologi. Ideelt set bør dette felt opdateres regelmæssigt i løbet af udgavens workflow.
# 4) Fix versioner :
Navnet på den version, hvor anmodningen om udstedelse / forbedring skal leveres. Denne værdi udfyldes typisk af produktejeren i koordination med scrummasteren i et smidigt scrummiljø.
# 5) Prioritet :
Dette felt angiver problemets kritiske betydning.
Det kan være en showstopper, hvilket betyder, at applikationstest ikke kan fortsætte i en testfase. En applikations nedbrud er et ideal Eksempel af en 'Show Stopper' (kritisk) udgave.
Fejlfindingskort og produktejere har ret til at ændre problemets prioritet. Dette felt er en rulleliste med værdier som 'Lav', 'Medium' ('Major'), 'Kritisk', 'Trivial' osv.
# 6) Mærkater :
Dette felt indtastes med de tekster, der hjælper med at kategorisere emner.
# 7) Miljø :
Dette er et valgfrit felt, og testmiljøet er angivet her.
# 8) Vedhæftet fil :
Understøtter billeder til det problem, der oprettes. Brugeren kan simpelthen trække og slippe billeder eller kopiere og indsætte.
# 9) Påvirker version / er :
For en 'bug' type problem skal produktversionen indtastes her.
For eksempel 5.6, 5.7 osv.
# 10) Sammenkædede problemer :
whitebox og blackbox test med eksempel
Andre relevante problemer kan knyttes til den nye udgave ved at vælge en passende værdi i rullemenuen.
For eksempel, hvis problemet introduceres ved en løsning af et andet problem, kan den værdi, der skal vælges fra rullemenuen, være 'Introduceret af'. Dette felt bliver ekstremt vigtigt, hvis en ny defekt udløses af en eller anden rettelse eller forbedring.
=> Udgave : Efter at have valgt en korrekt værdi i 'Tilknyttede problemer' nævnes relevant problem-id her.
# 11) Modtager :
Det er navnet på den bruger, der vil arbejde på problemet.
For eksempel i tilfælde af en fejl vil det være navnet på udvikleren, der løser problemet. Dette felt udfyldes typisk af produktejeren eller scrummasteren. Igen, der tildeler problemet, kan variere fra en organisation til en anden.
=> Ved at klikke på 'Tildel til mig' (placeret i højre hjørne af feltet 'Tildelt') tildeles problemet til den indloggede bruger.
# 12) Episk link :
Vælg det relevante link til eposet.
# 13) Sprint :
Sprintens navn er valgt her, hvilket indikerer, hvornår problemet vil blive behandlet. Det kan være en fremtidig sprint som besluttet af produktejeren.
# 14) Hold :
Der kan være forskellige hold i et agilt miljø. Emnet tildeles et af holdene. Denne opgave udføres normalt af produktejeren eller scrummasteren i samordning med produktejeren.
# 15) Anslået ved starten :
Dette felt angiver, hvor lang tid der kræves for at løse problemet.
Oftere kaldet 'guesstimate'. Dette vil også bestå af den krævede testindsats. Det kunne nævnes i timer / dage / uger eller historiepunkter. I et smidigt miljø under sprintplanlægning når hele holdet et fælles gæt.
# 16) Reporter :
Denne arkiv udfyldes automatisk af Jira med navnet på den indloggede bruger.
Bemærk: Vi kunne have nogle andre brugerdefinerede felter som nedenfor (som ikke ses i ovenstående billeder):
(i) Miljøtype :
Angiver, om der findes en defekt i et test- eller produktionsmiljø.
Disse feltværdier kan variere fra organisation til organisation. Hvis Jira kun bruges til at oprette problemer internt i organisationen og ikke af slutkunder, eksisterer dette felt muligvis slet ikke.
(ii) reproducerbar :
Er manglen reproducerbar? Dette felt vil ikke være tilgængeligt for andre typer problemer end en fejl.
(iii) kunde :
Dette felt navngiver slutkunden, der har arkiveret problemet. I nogle organisationer, hvor Jira kun bruges til intern problemhåndtering, eksisterer dette felt muligvis ikke.
hvordan man spiller .torrent filer
Bemærk: Alle de ovenfor beskrevne felter hører til fanen 'Felt' på siden 'Opret problem', som normalt er standardfanen. Siden kan tilpasses til at have flere faner som 'Dokumentation' osv., Som vi vil dække i vores efterfølgende tutorials.
Jira giver os en effektiv måde at styre de forskellige typer problemer let og effektivt på.
Med masser af tilpasning, der er mulige i dag, er Jira blevet det mest populære valg.
Hvordan håndteres problemer i JIRA
Arbejde med JIRA-problemer - Sådan logges fejl i JIRA
Lad os gå videre til at oprette et problem, forudsat at brugeren, der er logget ind, ikke er administrator, og vores testprojekt er “Test for STH” med komponenter - Modul 1 og Modul 2, versioner - version 1 og Version 2. Nøgle - TFS er allerede oprettet.
Oprettelse af et JIRA-nummer
Problemer udgør kernen i JIRA, så for at oprette dem er der en mulighed lige på menulinjen:
Klik på knappen 'Opret problem'. Alternativt, når du skriver “c”, mens du er på JIRA-siden, åbnes den følgende 'Opret problem'-dialog.
Alle felter på denne side er selvforklarende. Vi vil diskutere den vigtigste nedenfor.
Projekt : Hvert emne tilhører et projekt. Du kan vælge det samme ved at klikke på rullemenuen og vælge det projekt, som du vil have dette emne til.
Problemstype :Dette felt viser alle de typer problemer, der kan oprettes og spores via JIRA. Følgende muligheder er tilgængelige på denne liste (denne liste kan variere afhængigt af den indstilling, der er indstillet af administratoren):
Varerne Bug, ny funktion, opgave, forbedring er nøjagtigt hvad deres navne antyder. Epic og historie er mere relevante for de agile projekter. En historie er et krav i Agile, der skal spores fra start til slut. En episk er en gruppe historier.
Vælg emnetype efter behov. Jeg går med 'Bug'.
Resumé : Giv din bug en titel her. Når det bruges rigtigt, kan dette felt være meget vellykket til at overføre en masse kritisk information. Nogle aspekter at bemærke her:
En fejl / fejl er i det væsentlige noget, der ikke er rigtigt. Den rigtige måde at nærme sig en bugtitel er ved kortfattet at definere 'hvad der er forkert'.
Et eksempel af en dårlig titel / oversigt er “Der skal være en mulighed for at rydde indholdet på skærmen”. Når jeg læser dette, bliver min første reaktion - ”Okay, der burde være - men hvad er problemet her? Er muligheden slet ikke til stede? Eller er indstillingerne til stede og rydder ikke indholdet? ”
Det er også aftalt, at når jeg åbner denne fejl og ser nærmere på den, er jeg sikker på, at jeg finder svaret på dette spørgsmål.
Vægten her er dog at bruge dette “Resumé” -felt på den mest effektive måde. Derfor ville en meget passende opsummering / titel være 'Muligheden for at rydde indholdet på startsiden til login sletter ikke felterne, når der klikkes på.'
I det begrænsede rum, som dette felt giver, skal du prøve at skrive din titel på en måde, der kommunikerer det nøjagtige problem uden tvetydighed.
Prioritet : Dette felt kan tage en af følgende værdier.
Vælg en passende indstilling til din fejl.
Med sætte t : Denne liste viser komponenterne i projektet. Vælg passende.
Berørt version og Fix-version: Disse to felter viser de tilgængelige versioner til projektet. Det er ikke nødvendigt, at et bestemt problem, som du stødte på i en bestemt version, løses i det samme. I sådanne tilfælde kan du vælge den berørte version som den aktuelle version og fixversionen som den næste.
Disse felter kan også tage flere værdier. Du kan vælge at indstille, at et bestemt problem påvirker både version 1 og version 2 som nedenfor:
Modtager : Du kan skrive navnet på den person, som dette emne skal overdrages videre til. Du kan også tildele et problem til dig selv.
Beskrivelse : Dette er et valgfrit tekstfelt, der hjælper dig med at indtaste så mange oplysninger, som du ønsker om dit problem. I tilfælde af en insekt , er det typisk at bruge dette felt til at give en detaljeret information om trinene til reproduktion af defekten.
Det er yderst vigtigt at give alle oplysningerne.
”Sig, der er to felter - afhængige - stat og by. Når jeg vælger Stat fra rullemenuen, skal det i feltet By vise de respektive byer i den stat, jeg valgte.
Hvis jeg rejste en fejl som 'Byerne er tomme for nogle stater, valgte jeg'. Beskrivelsen felt det stedet for mig at uddybe denne mangel.
Et eksempel på en utilstrækkelig beskrivelse er:
1) Gå ind på siden
2) Klik på adressesiden
3) Indtast de andre detaljer som navn, gadenavn osv.
4) Klik på rullemenuen ”Stat”. Vælg en stat
5) Klik på rullemenuen “By” - noter bynavne
Ovenstående beskrivelse, selvom den er præcis, er den ikke komplet. Når det kommer til dette felt, er den side af at give for meget information, men ikke for lidt.
Hvis følgende trin føjes til beskrivelsen, vil dette ske giver mere mening.
6) Vælg staten som 'Californien', og klik på rullemenuen 'By' - alle stater vises, og brugeren kan vælge en by efter behov.
7) Vælg staten som “Louisiana”, og klik på rullemenuen “By” - listen vil være tom.
8) Byerne er tomme for staterne New Jersey og Utah også.
Så gentag, angiv de nøjagtige trin, de nøjagtige data og andre oplysninger, som du mener er nødvendige for at udfylde dette felt.
Vedhæftet fil : Ethvert støttedokument kan uploades med et problem.
Når alle oplysningerne er indtastet til din tilfredshed, kan problemet oprettes ved at klikke på knappen 'Opret' i slutningen af dialogen 'Opret problem'.
Problemet oprettes, og der vises en besked til brugeren med problem-ID:
Bemærk: bemærk problemets id; det er forud for projektets 'nøgle'. Det er JIRAs måde at spore / gruppere de problemer, der hører til et bestemt projekt.
Du kan nu se det oprettede problem ved at klikke på det link, der vises i ovenstående meddelelse.
Yderligere detaljer om siden Opret problem
1) Der vil være en konfigurationsfeltmulighed, der findes i øverste højre hjørne af siden 'Opret problem'.
Denne mulighed kan bruges til at vælge / ændre de felter, som du gerne vil se i din dialog om oprettelse af spørgsmål. Når et valg er foretaget, husker JIRA også ændringerne for dine efterfølgende udgaver.
to) Nederst på siden 'Opret problem' er der 'Opret en anden'
Når du vælger denne mulighed og klikker på 'Opret' - en gang oprettes det aktuelle problem; JIRA beholder
Dialogboksen 'Opret problem' er åben med Project, Issue-type og andre felter undtagen opsummering automatisk valgt i henhold til de tidligere oprettede problemer.
Dermed afslutter vi emnet “Oprettelse af et emne i JIRA”.
I den næste Atlassian JIRA-tutorial lærer vi om underopgaver, og hvordan man bruger dem til specifikke QA-formål.
=> Besøg her for komplette JIRA tutorials-serier
Over til dig
Nu er det tid til at høre fra dig. Har du haft nogen udfordringer ved at bruge JIRA til bugsporing?
Tror du, at der er nogen vægt på den modstand, som testhold har til at tilpasse JIRA til defekthåndtering?
PREV-vejledning | NÆSTE vejledning
Anbefalet læsning
- Backlog Bug Tracking Tool Praktisk gennemgangsvejledning
- GitLab Jira Integrationsvejledning
- Jira Download og installation med Jira License Setup
- JIRA-vejledning: En komplet brugervenlig JIRA-guide
- JIRA Administration Tutorial: JIRA Admin og User Management
- JIRA og SVN Integration Tutorial
- Dybdegående formørkelsesvejledninger til begyndere
- JIRA Agile Tutorial: Sådan bruges JIRA effektivt til styring af agile projekter