En mal for feilsporing er et forhåndsdefinert format for dokumentasjon og rapportering av feil i programvareutvikling. Ved å ha en mal sikrer man at viktige detaljer registreres på en konsekvent måte, noe som gjør det enklere å spore feil, prioritere dem og kommunisere om dem i et team.
Jira er et verktøy for problemsporing fra Atlassian, og det er sannsynligvis et av de mest populære verktøyene for feilsporing som brukes til prosjektstyring innen programvareutvikling (særlig i smidige miljøer). Jeg har brukt det i mange prosjekter de siste årene, både med Scrum og Kanban, og synes det er svært allsidig.
I denne artikkelen skal jeg gjennomgå Jiras allsidighet innen feilsporing, tilpasning og arbeidsflytstyring, samt hvordan feilrapportering kan forbedres med Jira.
Enten du har ansvar for å sette opp Jira-arbeidsflytene eller rapporterer feil ved hjelp av verktøyet, skader det ikke å vite hvordan det fungerer. Jira er mer enn bare et verktøy for feilrapportering, men i denne artikkelen fokuserer vi mer på sporing av feil enn på håndtering av andre typer problemer.
Slik setter du opp et nytt prosjekt med Jira Software
Hvis prosjektet ditt er nytt, er det første du må gjøre å sette opp Jira-prosjektet. Denne oppgaven ligger vanligvis hos scrum-masteren eller prosjektlederen, men hvis QA-rollen din overlapper med en av disse rollene, kan oppgaven havne på ditt bord. Det er ikke komplisert, og uansett bør det være noe du bare trenger å gjøre én gang!
Det er gratis å registrere seg, og for små prosjekter med færre enn ti brukere kan du bruke gratisabonnementet. Hvis du har et større team eller trenger avanserte funksjoner, kan du velge et av betalingsabonnementene. Jeg skal ikke gå inn på detaljene, men du kan sjekke Jiras prisside hvis du er interessert.
Jeg har bare opprettet nye prosjekter for å undervise i en klasse, men prosessen er ganske intuitiv. Du får muligheten til å velge mellom ulike prosjekttyper for programvareutvikling:
Prosjekttyper
- Et Kanban-prosjekt lar deg opprette Kanban-tavler. Du kan bruke den klassiske malen med de klassiske fasene: Å gjøre, Pågår og Ferdig.
- Scrum – Denne malen lar teamet administrere sprintene og oppgavekøen ved hjelp av Scrum-rammeverket.
- Feilsporing – En enkel mal som lar deg spore problemer uten å bruke noen smidig metodikk.
Alle prosjekter kan tilpasses slik at de inkluderer fasene, overgangene og statusene prosjektet trenger.
I denne veiledningen bruker jeg Scrum-prosjektmalen, slik at du kan spore brukerhistorier og feil i det samme prosjektet, men ikke bekymre deg – alt jeg viser, kan også brukes på andre prosjekttyper!
Have an account? Log In
Problemtyper
Standardtypene for problemer som følger med Jira, er:
- Epos: I smidig utvikling er et epos en overordnet samling av brukerhistorier og oppgaver.
- Feil: Problemtypen vi bruker i Jira til å spore oppdagede feil og mangler. Vi skal fokusere på disse i resten av artikkelen.
- Brukerhistorie: En smidig brukerhistorie (beskrivelsen av funksjonen eller egenskapen som skal utvikles og testes).
- Oppgave: Brukes vanligvis til å spore enkeltproblemer eller gjøremål, for eksempel å undersøke et nytt verktøy for testautomatisering eller oppdatere dokumentasjonen.
- Underoppgave: Dette er en individuell oppgave som er tildelt et teammedlem, og som er et underordnet problem under «Oppgave»-problemet som er nevnt ovenfor.
Som jeg allerede har nevnt, er Jira svært allsidig, og hvis du trenger å opprette din egen problemtype, kan du gjøre det når som helst i prosjektet.
Jeg jobbet for eksempel tidligere med et prosjekt der vi hadde en egen problemtype for forbedringer. Disse lignet på brukerhistorier, men var hovedsakelig knyttet til forbedringer av eksisterende funksjoner i applikasjonen.
Eller kan du opprette en sakstype for testtilfeller, men det kommer vi tilbake til litt senere, der vi går gjennom tilgjengelige programtillegg og Jira-integrasjonsverktøy.
Feilsporing med Jira
La oss gå videre til det som interesserer oss som testere – feilrapportering og -sporing. Selv om Jira er et prosjektstyringsverktøy, og ikke spesifikt et verktøy for feilsporing, kommer vi som QA-er sannsynligvis til å bruke det til mye feilrapportering 😁.
Arbeidsflyt og feilens livssyklus
Standardarbeidsflyten for feil (og for alle saker, faktisk) som Jira tilbyr, ser slik ut:
Når en sak åpnes, opprettes den med statusen «Å gjøre». Deretter kan saken, eller feilen, flyttes til hvilken som helst av de andre statusene.
Teststyringsteamet, scrum masteren eller prosjektlederen har vanligvis ansvaret for å utforme eventuelle tilpassede arbeidsflyter.
Arbeidsflyten gjenspeiler feilens livssyklus slik du ønsker å ha den i prosjektet. Du kan beholde den enkle standardvarianten eller gjøre den så kompleks som nødvendig. Jeg har ærlig talt aldri jobbet med et prosjekt som ikke hadde egne, tilpassede statuser og overganger.
For å tilpasse livssyklusen må du gå til prosjektinnstillingene, velge sakstypen for feil og klikke på «Rediger arbeidsflyt».
Her kan du legge til en ny status og velge en bestemt overgang ved behov. Her er et eksempel:
I dette tilfellet får en ny sak statusen «Å gjøre» når den opprettes, og derfra kan den bare flyttes til «Pågår». Før feilen kan testes, må koden deretter gjennomgås. QA-teamet kan lukke den når den er validert i statusen «I QA». Selvfølgelig kan både kodegjennomgangen og QA-prosessene mislykkes, og i så fall flyttes feilen tilbake til «Pågår».
Opprette en arbeidsflyt trinn for trinn
Jeg skal gå gjennom hvert trinn du må utføre for å gå fra den første arbeidsflyten til den andre (eller en annen tilpasset arbeidsflyt du mener passer for prosjektet ditt):
1. Klikk først på knappen «Rediger arbeidsflyt»
2. For å legge til en ny status klikker du på en av statusene – statusene er delt inn i tre kategorier: «Å gjøre», «Pågår» og «Ferdig», og hver kategori har sin egen farge. Du kan velge hvor statusen din passer best. Jeg bestemte at statusene «Under kodegjennomgang» og «I QA» betyr at saken fortsatt pågår:
Du kan også ha andre statuser under «Å gjøre», for eksempel statusen «Til gjennomgang» for når en ny funksjon åpnes og produkteieren eller forretningsanalytikeren fortsatt må legge til informasjon om den, eller teamet ennå ikke har videreutviklet den og bestemt seg for kompleksiteten eller anslaget for oppgavepoengene.
3. Når du har lagt til den nye statusen, kan du legge til en overgang for den. Som standard kan statusen oppdateres fra hvilken som helst annen status. Hvis du ikke ønsker bestemte overgangsregler, er det helt greit. En god arbeidsflyt bør imidlertid gjøre det mulig å flytte feil og saker til bestemte statuser først etter at de har gått gjennom bestemte prosesstrinn.
I eksempelet mitt ovenfor kan ikke QA-teamet begynne å verifisere rettingen før en annen utvikler har gjennomgått koden. For å legge til denne overgangen klikker du på knappen «Overgang» og angir detaljene:
4. Du kan også slette eksisterende overganger og statuser hvis du ønsker at alt skal være 100 % tilpasset.
5. En virkelig nyttig funksjon er automatisk tildeling. Dette gjøres også fra arbeidsflyten, der du kan angi en standardtilordnet bruker når en bestemt overgang utføres for saken (dette er også en viktig fordel med programvare for sakssporing).
For eksempel blir en feil automatisk tildelt en bestemt tester eller testansvarlig som avgjør hvem som skal arbeide med den, etter at feilen er 'Gjennomgått.' Det samme gjelder 'I QA.' Det samme gjelder 'Under arbeid' og utviklingsteamet. Nyopprettede saker kan automatisk tildeles en prosjektleder eller produkteier, som vil prioritere dem i etterslepet. Det kan tilpasses i stor grad, slik at du kan konfigurere det slik det fungerer best for teamet ditt.
Selv om du ikke har ansvar for å sette opp livssyklusene for sakene, eller ikke har tilgang til prosjektinnstillingene, kan du se arbeidsflyten for hver Jira-sak ved å utvide rullegardinlisten for status:
Vise saker i Jira
Hvis prosjektet ikke er et feilsporingsprosjekt, kan du vise de aktuelle sakene på Kanban- eller Scrum-tavlene:
Dette er bare for å demonstrere; jeg tviler på at du noen gang vil være så heldig å ha en sprint med bare én brukerhistorie og én feil 😅.
Når du klikker på en sak, vises detaljene. Disse inneholder blant annet en ID, som opprettes automatisk av Jira, en tittel, en beskrivelse, innmelderen, den tildelte personen samt eventuelle vedlegg eller kommentarer som teammedlemmene har lagt til.
Feltene kan også tilpasses, og jeg skal demonstrere dette når vi diskuterer hva vi bør inkludere i en god feilrapport.
Tildelte personer
Alle Jira-saker kan tildeles et bestemt teammedlem. Du kan merke personer i kommentarene eller beskrivelsen ved å bruke @-tegnet foran brukerens navn.
Du mottar varsler når noen merker deg, og når en sak som er tildelt deg eller meldt inn av deg, blir oppdatert. Du kan også «følge» saker. Du blir varslet når saker du følger, blir oppdatert, uavhengig av hvem som meldte dem inn eller hvem de er tildelt.
Feilrapportering i Jira
Alle ønsker seg en app med få feil, men la oss være ærlige: Testere blir alltid glade når vi finner en god feil.
Men en god feilrapport er bare så god som måten vi rapporterer den på – en god feilrapport sørger for at feilen blir rettet med så lite frem og tilbake mellom test- og utviklingsteamene som mulig. Jira er et flott verktøy for feilsporing. Har jeg nevnt det allerede? Det gir stor fleksibilitet.
Hvis du vil opprette en ny sak, klikker du på den store knappen «Opprett», så åpnes en dialogboks. Her velger du sakstypen «Feil»:
En god feilrapport bør inneholde en god beskrivelse (eller «Sammendrag» i Jira). Den bør være kortfattet, men samtidig inneholde nok detaljer til at det er tydelig hva saken gjelder.
Deretter legger du til alle relevante detaljer i beskrivelsen. Du kan strukturere dem på en klassisk måte:
- Trinn for å gjenskape
- Forventet resultat
- Faktisk resultat
Ta deretter med eventuelle andre detaljer som er relevante for feilen. Skjermbilder eller opptak er alltid en god idé, i tillegg til logger eller bestemte filer som ble brukt under kjøringen.
Jira lar deg legge til egendefinerte felt i saker. Jeg liker å skille mellom «Alvorlighetsgrad» og «Prioritet». Selv om «Prioritet» er et standardfelt som legges til av Jira, kan du legge til et egendefinert felt for «Alvorlighetsgrad».
Andre egendefinerte felt som kan være verdt å legge til, kan være knyttet til operativsystemet – et tekstfelt eller en rullegardinliste med forhåndsdefinerte verdier, for eksempel Android- og iOS-versjonene som brukes i testingen, nettleseren, byggnummeret eller annen informasjon som kan være relevant ved feilsporing.
Hvis du vil legge til nye felt, kan du gå til prosjektinnstillingene, velge typen «Feil» og velge hvilken type felt du trenger:
Testtilfeller i Jira
Det siste jeg vil snakke om, er testtilfeller. Jira-programvaren kan integreres med ulike verktøy for teststyring, eller du kan legge til Atlassian-utvidelser og tillegg, for eksempel Zephyr (som tidligere var favoritten min) eller Xray. Når du oppretter en feil som følge av et mislykket testtilfelle, kan testen kobles til feilen, noe som kan være svært nyttig når du skal håndtere feil, tester og gjennomføring av testtilfeller.
Vil du vite mer?
Jira kan være et godt verktøy for feilsporing og kan forbedre utviklingsprosessen fordi det gir mange muligheter for tilpasning. Når det gjelder feil, er det svært nyttig fordi du kan tilpasse arbeidsflyten slik at den passer til livssyklusen du ønsker å ha i prosjektet. Du kan koble feil til testtilfeller og legge til egendefinerte felt på den måten som gir mest mening for akkurat ditt prosjekt.
Hvis du vil ha flere veiledninger som denne, kan du abonnere på nyhetsbrevet fra The QA Lead.
