QA i et nøtteskall

QA i arbeidsprosessene 

For å kunne sikre en «shift left»-tankegang og identifisere og rette feil og mangler så tidlig som mulig, er det viktig at vi også kvalitetssikrer arbeidsprosessen til teamet. Hva gjør vi for å avdekke feil og for å unngå å introdusere feil tidlig i prosessen? I tillegg til at løsning og ny funksjonalitet skal være feilfri, så skal det også gi verdi for sluttbrukeren! 

Eksempel på en arbeidsprosess 

QA bør ha oversikt over arbeidsprosessene og hvilke kvalitetssikringstiltak som til enhver tid inngår i denne, samt foreslå endringer og justeringer underveis. Det enkelte medlemmet i teamet skal vite hva som ligger i prosessen og hva dette betyr for den enkeltes arbeid. 

Eksempler på kvalitetssikringstiltak i arbeidsprosesser kan være å ha en standardisering av hvordan vi skriver brukerhistoriene våre, blant annet i form av: 

• Tydeligere beskrivelse av krav, gjerne i form av en gitt syntax, som f.eks As a <type of user>, I want <some goal>, so that <some reason> 

• Tydeligere akseptansekrav f.eks vha Gherkin syntax – Given..when..then 

Noen av våre team har tatt i bruk maler for å sikre at brukerhistoriene for ny forretningsfunksjonalitet har forutsigbar oppbygging og inneholder nok informasjon til at utviklingsteamet kan implementere ønsket funksjonalitet og verdi for sluttbrukeren på en mer effektiv måte. 

En annen faktor som vi har sett er veldig nyttig er at teamet selv blir enig om hva som er deres «Definition of Ready» (DoR) – hva må være på plass før utvikling kan starte, for eksempel tydelige akseptanse krav. INVEST kan gi inspirasjon til hva som kan inngå i en DoR. 

Tilsvarende kan «Definition of Done» (DoD) gi god verdi ved å tydeliggjøre hva som bør være gjort før en utvikler sier seg ferdig med en brukerhistorie. Eksempler her er automatisk enhetstesting, «codereview» og «buddytest». 

QA i byggeprosesser 

Før ny funksjonalitet kan tas i bruk i produksjon, må koden flyttes gjennom flere miljøer, for eksempel utvikling, test og QA. Dette er en prosess som de fleste automatiserer til en viss grad, og målet er å kunne bygge, teste og deploye løsningen raskere og tryggere. Det enkelte team må bli enige om ambisjonsnivå og om de ønsker å sikte seg mot continuous deployment, eller om continuous integration er tiltrekkelig. 

QA-rollen bør ha kjennskap og kunne komme med forslag/innspill til hvordan byggeprosessen skal settes opp og hvilke sjekker som skal kjøres underveis. Det vil være naturlig at man som en del av pipelinen i hvert fall kjører automatiske enhets- og integrasjonstester. 

Agile QA quadrant 

Den Agile test kvadranten så sitt lys i 2003 gjennom en publisering av Brian Marick. Gjennom årene har det kommet flere varianter av kvadranten. 

Vi har valgt å bruke denne som en av dimensjonene i vårt rammeverk fordi vi mener den er et godt verktøy for å kunne visualisere og forstå de forskjellige QA-testene og hvem som er ansvarlig for dem. Rammeverket skiller mellom forretnings- og teknologifokuserte tester. Den skiller også mellom tester som støtter utvikling og de som kritiserer produktet. Basert på krav, risiko og avhengigheter må hvert enkelt team ta valg og identifisere de testene de trenger. 

Q1 er nært teknologien og utviklingsteamet er ansvarlig. Her finnes det automatiske unit- og integrasjonstester og det forventes at QA har oversikt over testdekningen. 

Q2 har en kombinasjon av automatiske og manuelle tester som er mer forretningsfokuserte, men som også støtter teamets utvikling. Her inkluderes funksjonelle tester som sikrer at løsningen støtter behovene til sluttbrukerne. 

Q3 inkluderer UAT, bruker- og utforskende testing. Dette innebærer manuell testing som er utført at QA-ekspertise og sluttbrukere. Målsetningen er å sikre og øke kvaliteten i produktet som utvikles. 

Q4 inkluderer teknologinære verktøybaserte tester, som performance- og sikkerhetsrelaterte tester. 

Ved å synliggjøre hva som foregår innenfor de forskjellige kvadrantene, vil man få et helhetlig overblikk over hvilke kvalitetssikringsaktiviteter som utføres i det enkelte teamet. 

Test pyramiden 

I moderne softwareutvikling er det nærmest en selvfølge å automatisere testing. Cohns testpyramide er derfor tatt med som en av dimensjonene for å sikre at vi har fokus på dette. Hvor mye man skal automatisere er derimot ikke gitt. Det kommer blant annet an på kompleksiteten og kritikaliteten til løsningen, hvor man er i utviklingsløpet og hvilken teknologistack som er i bruk. 

Cohns testpyramide finnes i veldig mange varianter, og illustrasjonen ovenfor er den vi mener passer best for de teamene som driver med moderne softwareutvikling der man har et et REST API-lag som leverer data fra backend til frontend.  

Formen på pyramiden indikerer at det skal være flere tester i det nederste laget og færre jo høyere opp i pyramiden man kommer.  

Vi forventer at våre utviklere, både backend og frontend, skriver automatiske enhetstester. Hvor stor prosentandel man har varierer og er noe som teamet må bli enig om.  

QA bør være med og sette premissene for testautomatiseringen på alle nivåene i pyramiden og vil i noen tilfeller også være den som implementerer dette, avhengig av teknisk kompetanse.  

Når det gjelder hvilke verktøy man skal bruke for å automatisere, anbefaler vi at man bygger på det som teamet allerede har kompetanse på eller erfaring med.  

Hva har vi brukt rammeverket til? 

Gjennom en serie av workshops der dette rammeverket har vært utgangspunkt for diskusjonen, har vi fått vist at det har verdi. De respektive QA-ene har brukt den for å beskrive hva som gjøres rundt kvalitetssikring i teamet i dag, samt til å identifisere en ønsket fremtidig tilstand og konkrete tiltak som må tas for å oppnå målet.

I tillegg kan det brukes inn mot det enkelte utviklingsteamet for å oppnå en felles forståelse for av hva kvalitetssikring i softwareutvikling innebærer og hva det betyr for hver enkelt i teamet, enten det er utviklere, teamledere, UX osv. Den kan også brukes i dialog med beslutningstakere hos kunden for å visualisere ønskede eller faktiske fokusområder som det vil være hensiktsmessig at teamet prioriterer. 

Vi mener at ved å dele kvalitetssikringsarbeidet opp i fire dimensjoner så vil man lettere få oversikt over hva man allerede gjør og hva man bør fokusere på fremover. Rammeverket muliggjør en enkel visualisering av teamets QA-strategi, og gir samtidig enkelt vedlikehold. Dette gjør det enkelt å presentere og oppdatere QA-strategien på en oversiktlig måte. 

Mens testing handler om å utføre spesifikke aktiviteter der testprosedyrer og -metoder brukes for å evaluere systemets funksjonalitet, er QA en bredere tilnærming som involverer å implementere retningslinjer, prosesser og standarder for å sikre at kvalitetsmål blir satt, definert og fulgt. QA fokuserer på å bygge kvalitet inn i prosessen fra begynnelsen av og har en proaktiv tilnærming. 

QA-rollen bør eie sammenhengen mellom de fire dimensjonene, men må samtidig bruke de andre rollene i teamet til å sørge for kontinuerlig forbedring rundt kvalitetssikringen. 

Dette sier QA-ene etter å ha brukt rammeverket