jira bug tracking tool tutorial
JIRA Bug Tracking: Defect Life Cycle i JIRA
Jira Last ned og installasjon ble forklart i detalj i vår forrige opplæring. Testteamene er alltid engstelig for å plukke opp JIRA for Defect Management.
Tvilen er berettiget. Det stammer fra det faktum at selv om JIRA bug tracking tool er aktuelt for IT-virksomheter, er det et generelt billettsystem.
Selv for IT-prosjekter gjør JIRAs popularitet med utviklingsteamene testere og QA-team ubehagelige. Til tross for komfort eller ubehag, har testteamene ikke noe annet valg enn å bruke JIRA bug tracking tool i de fleste selskaper. Våre Komplett guide om JIRA-trening vil gi deg en utmerket kunnskap om verktøyet.
=> Klikk her for komplette JIRA-opplæringsserier
Hvorfor? Enkel logikk- Bedrifter ønsker ikke å investere i flere verktøy. Det gir bare god forretningsmessig mening å maksimere verktøyutnyttelsen din og ikke bli gal med å kjøpe for mange lisenser.
Så hvis et utviklingsteam bruker Atlassian JIRA feilsporingsverktøy for å spore kravene, forbedringene, oppgavene eller brukerhistoriene, må testteamet sannsynligvis bruke det til bugsporing.
Men slapp av . JIRAs Defect Management er like bra som ethvert annet verktøy . I noen situasjoner kan det til og med være bedre.
Dette er opplæringen som vil demonstrere for deg, via skjermbilder og alt, JIRAs anvendelighet til bugsporing.
Hva du vil lære:
- De beste funksjonene i JIRA Bug Tracking Tool
- # 1) JIRA behandler alt arbeid i det som et problem
- # 2) Manglerapportering trenger følgende informasjon registrert for hvert problem:
- # 3) Defekt livssyklus:
- # 4) Kommentarer og samarbeid med Dev Team
- # 5) Koble mangelen til et krav for å muliggjøre sporbarhet
- # 6) Mangler kan importeres fra en CSV-fil
- # 7) Mangler kan eksporteres til Word-, XML- og utskrivbare formater
- # 8) Omfattende problemrapporter:
- Anvendeligheten av JIRA til testing - et alternativt dilemma
- Opprette en Jira-utgave og forskjellige felt
- Hvordan håndteres problemer i JIRA
De beste funksjonene i JIRA Bug Tracking Tool
Her går vi.
# 1) JIRA behandler alt arbeid i det som et problem
Så i JIRA ville det å skape en feil være å skape et problem av typen “ Feil ”.
# 2) Manglerapportering trenger følgende informasjon registrert for hvert problem:
- Defekt-ID
- Defekt tittel
- Feilbeskrivelse (trinn for reproduksjon)
- Miljøinformasjon
- Skjermbilde (vedlegg)
- Alvorlighetsgrad
- Tilordne det til noen
- Status- Alle statusene i livssyklusen for feilen
Alle alternativene er tilgjengelige for å kunne skape en feil effektivt.
Vær oppmerksom på feltene markert med rødt nedenfor:
anime-nettsteder for å se anime gratis
De to feltene du ikke ser her er:
- Defekt-ID
- Status
Disse to feltene er opprettet automatisk av JIRA. Alle utgaver vil ha en unik ID tildelt av JIRA. Status for alle problemer er 'To-Do' eller 'New' i JIRA som standard når du oppretter en feil.
Derfor, alle de vanlige fasilitetene for feilrapportering er også tilgjengelig i JIRA. Faktisk kan flere alternativer som etiketter, koblingsfeil, estimering av innsats brukes.
# 3) Defekt livssyklus:
Alle insekts livssyklusstatuser som i Bugzilla (eller andre populær bug tracker ) kan oppnås også her:
Dette trenger litt tilpassing av JIRA-administratoren din, men det er enkelt å gjøre. For de som ikke vil bry deg med tilpasningen, kan du ikke gå galt med standardoppsettet også.
# 4) Kommentarer og samarbeid med Dev Team
Hvert nummer, oppdateringer, personoppdrag, kommentarer mottatt fra Dev-teamet - alt blir sporet i JIRA under aktivitetsloggen.
Dette gir bedre synlighet og samarbeid med utviklingsteamene:
# 5) Koble mangelen til et krav for å muliggjøre sporbarhet
Koblingsalternativ i JIRA-problemfeltene lar deg koble et bestemt problem til et annet. La oss si at hvis Feil 2 er et duplikat av Feil 1, kan du etablere det forholdet.
Tilsvarende, hvis en mangel blokkerer et krav eller er relatert til et krav - kan du gjøre dette aspektet synlig i JIRA.
De resulterende koblingene vises på siden med utgivelsesdetaljer som nedenfor:
Forholdstypene er selvforklarende og bruken av enkelt-vanlig-hverdagsspråk ord (som forholder seg til, forårsaket av, etc.) gjør det superenkelt og intuitivt for enhver JIRA-bruker å bruke denne retten.
# 6) Mangler kan importeres fra en CSV-fil
Dette hjelper bulkopprettingen av problemer i JIRA på en gang. Hvis teamet ditt er nytt, og du ikke vil at det skal skape problemer direkte i verktøyet, kan du få dem til å rapportere feilene i et Excel-ark. Når de er gjennomgått og bekreftet som gyldige, kan de importeres samtidig til verktøyet ved hjelp av denne funksjonaliteten.
Uansett hvilken måte du bruker det, er dette et stort pluss.
# 7) Mangler kan eksporteres til Word-, XML- og utskrivbare formater
Dette støtter bedre bærbarhet av feildataene dine, spesielt nyttig hvis du vil dele dine feildata med personer som ikke er JIRA-brukere.
# 8) Omfattende problemrapporter:
I tillegg, hvis du trenger rapporter, gå til “ Prosjekt - rapporter ”Og generer alle slags rapporter som nedenfor:
Hvis vi må gjennomgå JIRAs analyser i ett ord, er det fantastisk.
Avanserte / kraftige brukere av JIRA kan også lage avanserte søkefiltre for å generere dypere innsikt.
For eksempel, Hvis du vil se på alle feilene du har fått i flere prosjekter (BM og AB), kan du bruke et JQL-spørsmål som nedenfor:
Så alt i alt er bug tracking / defect management i JIRA veldig lik om ikke overlegen til dedikerte bug trackers. Ikke bekymre deg neste gang du må jobbe med det. Du er i gode hender.
Anvendeligheten av JIRA til testing - et alternativt dilemma
Selv om dette er den ene siden av mynten, er det definitivt en annen dimensjon til hvordan folk ser på anvendeligheten av JIRA til QA eller testing.
Når du spør en gruppe QAer, “Hva er JIRA?” - Mange vil svare at JIRA er et sporingsverktøy for mangler. Husk deg, jeg har hørt dette fra mange senior QA-fagpersoner. Dette kan være fra det faktum at mangelforvaltning / sporing er alt de kan ha brukt JIRA til.
Men det er mye mer. Når det brukes riktig, kan kjernen JIRA med sine smidige evner være din one-stop-shop for høyt nivå prosjektledelse.
Det kan virkelig støtte kravsporing og fremgang, bug tracking, estimering, sprint tracking via SCRUM & KANBAN boards, rapportering og samarbeid.
Du bruker kanskje et verktøy for en ting, men prøv neste gang å lære noen ting rundt og om verktøyet som vil hjelpe deg å forstå og bruke det bedre.
Så, som et neste trinn, du kan utforske noen andre kule funksjoner i JIRA (som kanskje ikke direkte er relatert til feilsporing) som kan gjøre det til ditt valg.
- Tilpassbare dashboards
- Test Management Add-ons
- Stem og se på et problem
- Tidssporing
- Agile Project og Scrum boards
- Integrasjon av sammenløp / dokumentasjon, etc.
Opprette en Jira-utgave og forskjellige felt
Jira Issues: Ulike typer Jira Issues
Jira gir deg veldig enkle måter å opprette / logge problemer på.
Det lar oss ikke bare arkivere feil, men gjør det også mulig for oss i andre typer 'billetter' eller 'forespørsler'. Det er mer en applikasjon for generell forespørsel.
Denne opplæringen vil forklare mer om problemtyper i Jira, opprette et problem, forskjellige felt på 'Create Issue' -siden og deres detaljer i enkle termer med billedlig fremstilling for enkel forståelse.
Jira Issues
Ulike organisasjoner kan ha forskjellige typer problemer avhengig av egnethet / behov. En Jira-administrator kan effektivt tilpasse dette feltet.
Problemer kan være av forskjellige typer, og nedenfor er beskrivelsen / betydningen av problemtyper:
- Feil: Dette er enhver feil eller avvik som finnes i applikasjonen.
- Forbedring av forbedring: Det er også kjent som en endringsforespørsel (CR). Denne typen brukes til å skildre enhver endring i eksisterende funksjonalitet eller helt en ny funksjonalitet.
- Oppgave: Dette er mer et konfigurasjons- eller analyseproblem. For eksempel , å sette opp riktige konfigurasjoner kan være en oppgave.
- Spørsmål: Problemet kan være så enkelt som å stille et spørsmål om hvordan du bruker litt funksjonalitet i applikasjonen. Denne typen brukes oftere av sluttkundene.
- Episk: Dette er normalt et stort problem som ideelt sett er delt inn i flere små problemer. Det kan ta flere sprinter å fullføre det viktigste episke problemet i et smidig miljø.
- Finansielt objekt: Ofte bruker prosjekt- / produktledelse denne typen problemer for å spore økonomien.
- Historie: Hele brukerhistorien om en funksjon kan være en type problem.
- Testforsøk : Problemet kan være en prøvesak. Denne typen problemer vil være tilgjengelig når Jira er integrert med plugin-moduler som Zypher.
Opprette et problem
Forutsatt at en bruker har logget på Jira og ønsket prosjekt.
Trinn 1:
Klikk på verktøylinjeknappen ‘+’ (‘Opprett’).
Dette vil vise en skjerm / side som vist på bildet nedenfor:
Velg prosjekt og type / forespørselstype på denne siden, og klikk deretter på ‘Neste’ -knappen.
Dette åpner siden 'Opprett problem' som vist på følgende bilder:
Steg 2:
Skriv inn obligatoriske detaljer og andre data så mye som mulig på siden 'Opprett problem'.
Trinn 3:
Klikk på knappen ‘Opprett’. Dette vil generere en unik problem-ID. ID vil bestå av prosjektidentifikator sammenkoblet med numeriske sifre.
I eksemplet ovenfor er det valgte prosjektet 'TestProject', derav ID kan være som 'TESTPROJ1234'.
- Når problemet er opprettet, kan det søkes i det ved hjelp av problem-ID-en.
Beskrivelse av felt på siden 'Opprett problem'
(Opprett utgavesidebilder er delt inn i 3 deler for bedre lesbarhet).
Merk :Jira-administrator og / eller utvikler kan legge til / fjerne de tilpassede feltene avhengig av organisasjonens behov.
# 1) Sammendrag :
Dette kalles også oftere som tittelen på utgaven og er et veldig viktig felt i et Jira-nummer.
Tittelen skal være så unik og presis som mulig, slik at man ved å se på selve tittelen kan forstås. Dette hjelper feilanmeldelseskortet og / eller produkteiere å prioritere og tildele problemet uten å se dypt inn i det.
# 2) Komponent / er :
Navn (er) på modulen eller området for applikasjonen der feilen oppdages i tilfelle problemet med feilen.
Det kan være området der det kreves endringer i tilfelle CR. Dette er vanligvis en rullegardinmeny som består av forskjellige moduler / komponenter som finnes i applikasjonen. Prosjektpersonen må få den fylt ut av administratoren.
# 3) Beskrivelse :
Skal vanligvis inneholde trinnene for å reprodusere problemet hvis problemtypen er en feil.
I tilfelle en forbedringsforespørsel, bør den detaljere om det nye kravet som vanligvis kalles som en historie i den smidige terminologien. Ideelt sett bør dette feltet oppdateres regelmessig i løpet av arbeidsflyten.
# 4) Fix versjoner :
Navnet på versjonen der forespørselen om utstedelse / forbedring blir levert. Denne verdien fylles vanligvis av produkteieren i samordning med scrummasteren i et smidig scrummiljø.
# 5) Prioritet :
Dette feltet indikerer hvor kritisk problemet er.
Det kan være en showstopper, noe som betyr at applikasjonstesting ikke kan fortsette i en testfase. Krasj av en applikasjon er et ideal Eksempel av en 'Show Stopper' (kritisk) utgave.
Feilsøkingskort og produkteiere har full rett til å endre prioriteten til problemet. Dette feltet er en rullegardinliste med verdier som 'Lav', 'Medium' ('Major'), 'Kritisk', 'Trivial' osv.
# 6) Etiketter :
Dette feltet er skrevet inn med tekstene som hjelper til med å kategorisere problemstillinger.
# 7) Miljø :
Dette er et valgfritt felt, og testmiljøet er spesifisert her.
# 8) Vedlegg :
Støtter bilder for problemet som opprettes. Brukeren kan bare dra og slippe bilder eller kopiere og lime inn.
# 9) Påvirker versjon / er :
For en 'feil' -type, bør produktversjonen legges inn her.
For eksempel 5.6, 5.7 etc.
# 10) Koblede problemer :
Andre relevante problemer kan knyttes til den nye utgaven ved å velge en riktig verdi fra denne rullegardinmenyen.
For eksempel, hvis problemet blir introdusert av en løsning av et annet problem, kan verdien som skal velges fra rullegardinmenyen være 'Introdusert av'. Dette feltet blir ekstremt viktig hvis en ny feil utløses av en løsning eller forbedring.
=> Utgave : Etter at du har valgt en riktig verdi i ‘Koblede utgaver’, blir relevant problem-ID nevnt her.
# 11) Oppdragsgiver :
Det er navnet på brukeren som skal jobbe med problemet.
For eksempel, i tilfelle en feil, vil det være navnet på utvikleren som vil løse problemet. Dette feltet fylles vanligvis ut av produkteieren eller scrum master. Igjen hvem som tildeler problemet, kan variere fra en organisasjon til en annen.
=> Ved å klikke på ‘Tildel til meg’ (plassert i høyre hjørne av ‘Tildelt’ -feltet) tildeles problemet til den påloggede brukeren.
# 12) Episk lenke :
Velg den relevante lenken til eposet.
# 13) Sprint :
Sprintens navn er valgt her, noe som indikerer når problemet vil bli jobbet med. Det kan være en fremtidig sprint som bestemt av produkteieren.
# 14) Team :
Det kan være forskjellige team, i et smidig miljø. Utgaven tildeles et av lagene. Denne oppgaven gjøres vanligvis av produkteieren eller scrum master i koordinering med produkteieren.
# 15) Anslag i starten :
Dette feltet vil indikere hvor mye tid som kreves for å løse problemet.
Oftere kalt som ‘guesstimate’. Dette vil også bestå av den nødvendige testinnsatsen. Det kan nevnes i timer / dager / uker eller historiepoeng. I et smidig miljø under sprintplanlegging når hele teamet en felles gjetning.
# 16) Reporter :
Dette arkivert blir automatisk fylt ut av Jira med navnet på den påloggede brukeren.
Merk: Vi kan ha noen andre egendefinerte felt som nedenfor (som ikke vises på bildene ovenfor):
(i) Miljøtype :
Indikerer om en feil er funnet i et test- eller produksjonsmiljø.
Feltverdiene kan variere fra organisasjon til organisasjon. Hvis Jira brukes til å opprette problemer bare internt i organisasjonen og ikke av sluttkunder, kan dette feltet ikke eksistere i det hele tatt.
(ii) Reproduserbar :
Er mangelen reproduserbar? Dette feltet vil ikke være tilgjengelig for andre typer problemer enn en feil.
(iii) Kunden :
Dette feltet navngir sluttkunden som har arkivert problemet. I noen organisasjoner der Jira bare brukes til intern problemhåndtering, eksisterer kanskje ikke dette feltet.
Merk: Alle de ovennevnte feltene tilhører 'Felt' -fanen på 'Opprett problem' -siden, som vanligvis er standardfanen. Siden kan tilpasses slik at den har flere faner som 'Dokumentasjon' osv. Som vi vil dekke i de påfølgende veiledningene.
Jira gir oss en effektiv måte å håndtere de forskjellige typene problemer enkelt og effektivt.
Med mange tilpasninger som er mulige i dag, har Jira blitt det mest populære valget.
Hvordan håndteres problemer i JIRA
Arbeide med JIRA-problemer - Hvordan logge feil i JIRA
La oss gå videre til å opprette et problem, forutsatt at brukeren som er pålogget ikke er administrator, og vårt testprosjekt er 'Test for STH' med komponenter - Modul 1 og Modul 2, versjoner - versjon 1 og versjon 2. Nøkkel - TFS er allerede opprettet.
Opprette et JIRA-problem
Problemer utgjør kjernen i JIRA, så for å lage dem er det et alternativ rett på menylinjen:
Klikk på knappen 'Opprett problem'. Alternativt, når du skriver “c” mens du er på JIRA-siden, åpnes følgende dialogboksen ‘Opprett problem’.
Alle feltene på denne siden er selvforklarende. Vi vil diskutere den viktigste nedenfor.
Prosjekt : Hver utgave tilhører et prosjekt. Du kan velge det samme ved å klikke på rullegardinmenyen og velge prosjektet du vil at denne utgaven skal tilhøre.
Problemstype :Dette feltet viser alle typer problemer som kan opprettes og spores via JIRA. Følgende alternativer er tilgjengelige på denne listen (denne listen kan variere avhengig av innstillingen som er angitt av administratoren):
Elementene Bug, ny funksjon, oppgave, forbedring er nøyaktig hva navnene deres innebærer. Episk historie er mer relevant for de smidige prosjektene. En historie er et krav i Agile som må spores fra start til slutt. En episk er en gruppe historier.
Velg problemtype etter behov. Jeg skal gå med “Bug”.
Sammendrag : Gi feilen din en tittel her. Når det brukes riktig, kan dette feltet være veldig vellykket til å overføre mye viktig informasjon. Noen aspekter å merke seg her:
En feil / mangel er egentlig noe som ikke er riktig. Den riktige måten å nærme seg en feiltittel på er å definere kortfattet ‘hva som er galt’.
Et eksempel av en dårlig tittel / oppsummering er “Det bør være et alternativ for å fjerne innholdet på skjermen”. Når jeg leser dette, blir den første reaksjonen min: 'Ok, det burde være - men hva er problemet her? Er alternativet ikke i det hele tatt? Eller er alternativene til stede og ikke rydder innholdet? '
Det er også enighet om at når jeg åpner denne feilen og ser nærmere på den, er jeg sikker på at jeg vil finne svaret på dette spørsmålet.
Vekten her er imidlertid å bruke dette “Sammendrag” -feltet på den mest effektive måten. Derfor vil et veldig passende sammendrag / tittel være 'Alternativet for å tømme innholdet på startsiden for pålogging, tømmer ikke feltene når du klikker på.'
I det begrensede rommet som dette feltet gir, prøv å skrive tittelen din på en måte som kommuniserer det nøyaktige problemet uten tvetydighet.
Prioritet : Dette feltet kan ta en av følgende verdier.
Velg et passende alternativ for feilen din.
Med sette t : Denne listen vil vise komponentene i prosjektet. Velg riktig.
Berørt versjon og Fix-versjon: Disse to feltene viser versjonene som er tilgjengelige for prosjektet. Det er ikke nødvendig at et bestemt problem du møtte i en bestemt versjon blir løst i det samme. I slike tilfeller kan du velge den berørte versjonen som den nåværende versjonen og fikseversjonen som den neste.
Disse feltene kan også ta flere verdier. Du kan velge å angi at et bestemt problem påvirker både versjon 1 og versjon 2 som nedenfor:
Tildelt : Du kan skrive inn navnet på personen som dette problemet skal overleveres til videre. Du kan også tildele et problem til deg selv.
Beskrivelse : Dette er et valgfritt tekstfelt som hjelper deg med å legge inn så mye informasjon du vil om problemet ditt. I tilfelle en feil , er det typisk å bruke dette feltet for å gi inn detaljert informasjon om trinnene for å reprodusere feilen.
Det er av største betydning å gi all informasjonen.
“Si, det er to felt - avhengige - stat og by. Når jeg velger Stat fra rullegardinmenyen, skal det i byfeltet vise de respektive byene i staten jeg valgte.
Hvis jeg tok opp en feil som 'Byene er tomme for noen stater valgte jeg'. Beskrivelsen felt det stedet for meg å utdype denne feilen.
Et eksempel på en utilstrekkelig beskrivelse er:
1) Gå inn på nettstedet
2) Klikk på adressesiden
3) Skriv inn de andre detaljene som navn, gateadresse osv.
4) Klikk på rullegardinmenyen 'Stat'. Velg en stat
5) Klikk på rullegardinmenyen “By” - noter bynavn
Ovennevnte beskrivelse, selv om den er presis, er den ikke fullstendig. Når det gjelder dette feltet, er på siden av å gi for mye informasjon, men ikke for lite.
Hvis følgende trinn legges til beskrivelsen, vil dette gi mer mening.
6) Velg staten som “California” og klikk på rullegardinmenyen “By” - alle statene vil vises, og brukeren kan velge en by etter behov.
7) Velg staten som “Louisiana” og klikk på rullegardinmenyen “By” - listen vil være tom.
8) Byene er tomme for delstatene New Jersey og Utah også.
Så, for å gjenta, oppgi de nøyaktige trinnene, de nøyaktige dataene og all annen informasjon du mener som er nødvendig for å fullføre dette feltet.
Vedlegg : Ethvert støttedokument kan lastes opp med et problem.
Når all informasjon er oppgitt til din tilfredshet, kan problemet opprettes ved å klikke på “Opprett” -knappen på slutten av dialogboksen “Opprett problem”.
Problemet blir opprettet og en melding vises til brukeren med problem-ID:
Merk: legg merke til problem-ID-en; det er prefikset av 'nøkkelen' til prosjektet. Det er JIRAs måte å spore / gruppere problemene som tilhører et bestemt prosjekt.
Du kan nå se det opprettede problemet ved å klikke på lenken som vises i meldingen ovenfor.
Ytterligere detaljer om siden Opprett problem
1) Det vil være et konfigurasjonsfeltalternativ øverst til høyre på siden 'Opprett problem'.
Dette alternativet kan brukes til å velge / endre feltene du vil se i dialogboksen din. Når et valg er gjort, vil JIRA også huske endringene for dine påfølgende utgaver.
to) Nederst på siden 'Opprett problem' er det en 'opprett en ny'
Når du velger dette alternativet og klikker “Opprett” - en gang, opprettes det aktuelle problemet; JIRA beholder
Dialogboksen 'Opprett problem' åpnes med Prosjekt, Utgavetype og andre felt, bortsett fra sammendrag automatisk valgt i henhold til de tidligere utgavene.
Med det avslutter vi temaet “Opprette et problem i JIRA”.
I den neste Atlassian JIRA-opplæringen vil vi lære om underoppgaver og hvordan du bruker dem til spesifikke QA-formål.
=> Besøk her for komplette JIRA-opplæringsserier
Over til deg
Nå er det på tide å høre fra deg. Har du møtt noen utfordringer ved å bruke JIRA for bug tracking?
Tror du det er noe tyngde mot motstanden testteamene har for å tilpasse JIRA for mangelhåndtering?
PREV Opplæring | NESTE veiledning
Anbefalt lesing
- Backlog Bug Tracking Tool Praktisk gjennomgangsveiledning
- GitLab Jira Integration Tutorial
- Jira nedlasting og installasjon med Jira License Setup
- JIRA-opplæring: En komplett brukervennlig JIRA-guide
- JIRA Administration Tutorial: JIRA Admin and User Management
- JIRA og SVN Integration Tutorial
- In-Depth Eclipse Tutorials For Beginners
- JIRA Agile Tutorial: Hvordan bruke JIRA effektivt til å håndtere smidige prosjekter