En skabelon til fejlsporing er et foruddefineret format til dokumentation og rapportering af fejl i softwareudvikling. En skabelon sikrer, at afgørende detaljer registreres ensartet, hvilket gør det lettere at spore og prioritere fejl samt kommunikere om dem i et team.
Jira er et værktøj til sagsstyring fra Atlassian, og det er sandsynligvis et af de mest populære værktøjer til fejlsporing, der bruges til styring af udviklingsprojekter (især i agile miljøer). Jeg har brugt det til mange projekter gennem årene, både med Scrum og Kanban, og jeg synes, det er meget alsidigt.
I denne artikel gennemgår jeg Jiras alsidighed inden for fejlsporing, tilpasning og arbejdsgangsstyring samt forbedring af fejlrapportering med Jira.
Uanset om du er ansvarlig for at opsætte Jira-arbejdsgangene, eller om du rapporterer fejl ved hjælp af det, skader det ikke at vide, hvordan det fungerer. Jira er mere end blot et værktøj til fejlrapportering, men i denne artikel fokuserer vi mere på sporing af fejl end på håndtering af andre typer sager.
Opsætning af et nyt projekt med Jira Software
Hvis dit projekt er nyt, er det første, du skal gøre, at opsætte Jira-projektet. Denne opgave ligger normalt hos Scrum-masteren eller projektlederen, men hvis din QA-rolle overlapper med en af disse roller, kan opgaven lande på dine skuldre. Det er ikke kompliceret, og det bør under alle omstændigheder kun være nødvendigt at gøre én gang!
Det er gratis at tilmelde sig, og til små projekter med færre end ti brugere kan du bruge den gratis plan. Hvis du har et større team eller har brug for avancerede funktioner, kan du vælge en af de betalte planer. Jeg vil ikke gå i detaljer, men du kan se Jiras prisside, hvis du er interesseret.
Jeg har kun oprettet nye projekter for at undervise på et kursus, men processen er ret intuitiv. Du får mulighed for at vælge mellem forskellige projekttyper til softwareudvikling:
Projekttyper
- Et Kanban-projekt giver dig mulighed for at oprette Kanban-tavler. Du kan bruge den klassiske skabelon med de klassiske faser: Skal udføres, I gang og Færdig.
- Scrum – Denne skabelon giver teamet mulighed for at håndtere deres sprint og opgaveliste ved hjælp af Scrum-rammeværket.
- Fejlsporing – En simpel skabelon, der giver mulighed for sagsstyring uden at bruge nogen agil metode.
Alle projekter kan tilpasses, så de indeholder de faser, overgange og statusser, som projektet har brug for.
I denne vejledning bruger jeg Scrum-projektskabelonen, så du kan spore brugerhistorier og fejl i det samme projekt, men bare rolig – alt det, jeg viser, kan også anvendes på andre projekttyper!
Have an account? Log In
Sagstyper
De standardsagstyper, Jira stiller til rådighed, er:
- Episk: I agil udvikling er en episk en overordnet samling af brugerhistorier og opgaver.
- Fejl: Den sagstype, vi bruger i Jira til at spore opdagede fejl og mangler. Vi fokuserer på disse i resten af artiklen.
- Historie: En agil brugerhistorie (beskrivelsen af den funktion eller funktionalitet, der skal udvikles og testes).
- Opgave: Bruges normalt til at spore enkelte sager eller punkter på en opgaveliste, f.eks. undersøge et nyt værktøj til testautomatisering eller opdatere dokumentationen.
- Underopgave: Dette er en individuel opgave, der er tildelt et teammedlem, og som er en underordnet sag til den ovenfor nævnte sag af typen “Opgave”.
Som jeg allerede har nævnt, er Jira meget alsidigt, og hvis du har brug for at oprette din egen sagstype, kan du gøre det når som helst i projektet.
Jeg arbejdede f.eks. tidligere på et projekt, hvor vi havde en separat sagstype til forbedringer. Disse lignede brugerhistorier, men var hovedsageligt relateret til forbedringer af eksisterende funktioner i applikationen.
Eller du kan oprette en problemtype til testsager, men det vender vi tilbage til lidt senere, hvor vi gennemgår tilgængelige plugins og Jira-integrationsværktøjer.
Fejlsporing med Jira
Lad os gå videre til det, der interesserer os som testere – fejlrapportering og -sporing. Selvom Jira er et projektstyringsværktøj og ikke specifikt et fejlsporingsværktøj, vil vi som QA-medarbejdere sandsynligvis bruge det til at rapportere en masse fejl 😁.
Arbejdsgang og fejlens livscyklus
Den standardarbejdsgang for fejl (og faktisk for alle problemer), som Jira leverer, ser sådan ud:
Når et problem åbnes, oprettes det med status 'Gøremål' . Derefter kan problemet eller fejlen flyttes til enhver af de andre statuser.
Teststyringsteamet, scrum masteren eller projektlederen har normalt ansvaret for at designe tilpassede arbejdsgange.
Arbejdsgangen afspejler den livscyklus for fejl, som du ønsker at have i projektet. Du kan beholde den enkle standardarbejdsgang eller gøre den så kompleks, som det er nødvendigt. Jeg har ærligt talt aldrig arbejdet på et projekt, der ikke havde sine egne, tilpassede statuser og overgange.
Hvis du vil tilpasse livscyklussen, skal du gå til projektindstillingerne, vælge problemtypen for fejl og klikke på 'Rediger arbejdsgang.'
Her kan du tilføje en ny status og vælge en specifik overgang, hvis det er nødvendigt. Her er et eksempel:
I dette tilfælde vil et nyt problem, når det oprettes, have statussen 'Gøremål' , hvorfra det kun kan flyttes til 'I gang.' Derefter skal koden gennemgås, før fejlen kan testes. QA-teamet kan lukke den, når den er valideret i statussen 'I QA'. Naturligvis kan kodegennemgangen og QA-processerne mislykkes, og i så fald flyttes fejlen tilbage til 'I gang.'
Oprettelse af arbejdsgang trin for trin
Jeg gennemgår hvert trin, du skal udføre for at gå fra den første arbejdsgang til den anden (eller til en hvilken som helst tilpasset arbejdsgang, der passer til dit projekt):
1. Klik først på knappen 'Rediger arbejdsgang'
2. Hvis du vil tilføje en ny status, skal du klikke på en af statuserne – statuserne er opdelt i tre kategorier: 'Gøremål,' 'I gang,' og 'Færdig', som hver har en bestemt farve. Du kan vælge, hvor din status passer bedst. Jeg besluttede, at statuserne 'I kodegennemgang' og 'I QA' betyder, at problemet stadig er under behandling:
Du kan også have andre statuser under 'Gøremål'; for eksempel en status som 'I gennemgang' , når en ny funktion åbnes, og produktejeren eller forretningsanalytikeren stadig skal tilføje oplysninger om den, eller når teamet endnu ikke har færdiggjort den og besluttet dens kompleksitet eller estimeret dens historiepoint.
3. Når du har tilføjet den nye status, kan du tilføje en overgang til den. Som standard kan statussen opdateres fra enhver anden status. Hvis du ikke ønsker specifikke regler for overgange, er det helt i orden. En god arbejdsgang bør dog kun tillade, at fejl og problemer flyttes til bestemte statuser, efter at de har gennemgået bestemte procestrin.
I mit eksempel ovenfor kan QA-teamet ikke begynde at kontrollere rettelsen, før en anden udvikler har gennemgået koden. Klik på knappen 'Overgang' for at tilføje denne overgang, og indtast oplysningerne:
4. Du kan også slette eksisterende overgange og statuser, hvis du ønsker, at alt skal være 100 % tilpasset.
5. En virkelig smart funktion er de automatiske tildelinger. Dette gøres også fra arbejdsgangen, hvor du kan angive en standardbruger, der tildeles, når en bestemt overgang udføres på problemet (dette er også en vigtig fordel ved software til problemsporing).
For eksempel bliver en fejl, efter at den er 'Gennemgået' og flyttet til 'I QA,' automatisk tildelt en bestemt tester eller testlederen, som beslutter, hvem der skal arbejde på den. Det samme gælder for 'I gang' og udviklingsteamet. Nyoprettede sager kan automatisk tildeles en projektleder eller produktejer, som vil prioritere dem i backloggen. Det kan i høj grad tilpasses, så du kan konfigurere det, så det fungerer for dit team.
Selv hvis du ikke er ansvarlig for at opsætte sagernes livscyklusser, eller hvis du ikke har adgang til projektindstillingerne, kan du se arbejdsgangen for hver Jira-sag ved at udvide rullemenuen for status:
Visning af sager i Jira
Hvis projektet ikke er et fejlsporingsprojekt, kan du se de aktuelle sager på Kanban- eller Scrum-tavlerne:
Dette er kun for at demonstrere det; jeg tvivler på, at du nogensinde vil være så heldig at have et sprint med kun én brugerhistorie og én fejl 😅.
Hvis du klikker på en sag, vises dens detaljer. Disse omfatter blandt andet et ID, som automatisk oprettes af Jira, en titel, en beskrivelse, rapportøren, den tildelte person samt eventuelle vedhæftede filer eller kommentarer, som teammedlemmerne har tilføjet.
Felterne kan også tilpasses, og det vil jeg demonstrere, når vi gennemgår, hvad en god fejlrapport bør indeholde.
Tildelte personer
Alle Jira-sager kan tildeles et bestemt teammedlem. Du kan tagge personer i kommentarerne eller beskrivelsen ved at bruge @-tegnet foran brugerens navn.
Du modtager notifikationer, når nogen tagger dig, og når en sag, der er tildelt til dig eller rapporteret af dig, bliver opdateret. Du kan også “holde øje med” sager. Du får besked, når sager, du holder øje med, bliver opdateret, uanset hvem der har rapporteret dem, eller hvem de er tildelt til.
Fejlrapportering i Jira
En app med få fejl er det, alle stræber efter, men lad os være ærlige: Testere er altid glade, når vi finder en god fejl.
Men en god fejl er kun så god som den måde, vi rapporterer den på – en god fejlrapport sikrer, at den bliver rettet med så lidt frem og tilbage mellem test- og udviklingsteamene som muligt. Jira er et fremragende værktøj til fejlsporing. Har jeg allerede nævnt det? Det giver stor fleksibilitet.
Hvis du vil oprette en ny sag, skal du klikke på den store knap 'Opret', hvorefter en dialogboks åbnes. Her vælger du sagstypen 'Fejl' :
En god fejlrapport bør indeholde en god beskrivelse (eller 'Resumé' i Jira). Den bør være kortfattet, men indeholde tilstrækkelige oplysninger til at gøre det klart, hvad sagen drejer sig om.
Tilføj derefter alle relevante oplysninger i beskrivelsen. Du kan strukturere dem på klassisk vis:
- Trin til at genskabe fejlen
- Forventet resultat
- Faktisk resultat
Medtag derefter alle andre oplysninger, der er relevante for fejlen. Skærmbilleder eller optagelser er altid en god idé, ligesom logfiler eller specifikke filer, der blev brugt under udførelsen.
Jira gør det muligt at tilføje brugerdefinerede felter til sager. Jeg foretrækker at adskille 'Alvorlighedsgrad' fra 'Prioritet.' Mens 'Prioritet' er et standardfelt, der tilføjes af Jira, kan du tilføje et brugerdefineret felt for 'Alvorlighedsgrad.'
Andre brugerdefinerede felter, der kan være værd at tilføje, kan vedrøre operativsystemet – et tekstfelt eller en rullemenu med foruddefinerede værdier, såsom de Android- og iOS-versioner, der bruges i testningen, browseren, buildnummeret eller andre oplysninger, der kan være relevante ved fejlsporing.
Hvis du vil tilføje nye felter, kan du gå til projektindstillingerne, vælge typen 'Fejl' og vælge, hvilken type felt du har brug for:
Testcases i Jira
Det sidste, jeg vil tale om, er testcases. Jira-software kan integreres med forskellige værktøjer til teststyring, eller du kan tilføje Atlassian-udvidelser og tilføjelser såsom Zephyr (som tidligere var min favorit) eller Xray. Når du opretter en fejl som følge af en mislykket testcase, kan testen knyttes til fejlen, hvilket kan være meget nyttigt til håndtering af fejl, tests og udførelse af testcases.
Vil du vide mere?
Jira kan være et fremragende værktøj til fejlsporing og kan forbedre udviklingsprocessen, fordi det giver mulighed for omfattende tilpasning. Når det gælder fejl, er det virkelig nyttigt, fordi du kan tilpasse arbejdsgangen, så den passer til den livscyklus, du ønsker for dit projekt. Du kan knytte fejl til testcases og tilføje brugerdefinerede felter på den måde, der giver bedst mening for dit specifikke projekt.
Hvis du vil have flere vejledninger som denne, kan du tilmelde dig The QA Leads nyhedsbrev.
