Å lage en kvalitetsstrategi

Gjengitt med tillatelse fra Kristins utmerkede blogg, thinkingtester.

I mitt forrige innlegg introduserte jeg konseptet kvalitetsmodenhetsmodellen: en serie atferdsmønstre knyttet til kvalitetsattributter som hjelper team med å oppnå ulike kvalitetsattributter i programvaren sin.

En viktig ting å merke seg er at innføring av en kvalitetsmodenhetsmodell krever at hele teamet bidrar til kvaliteten.

Kvalitet er ikke noe som skal kastes «over muren» til testerne; det er snarere et mål som både utviklere og testere deler.

Men hvordan kan du få hele teamet til å ta ansvar for kvaliteten?

Én måte er å utarbeide en kvalitetsstrategi. Dette er et dokument som hele teamet blir enige om sammen. Se på det som en kontrakt som beskriver hvordan kvalitetsprogramvare skal utvikles, testes og lanseres av teamet. 

Her skal jeg gå gjennom noen spørsmål dere kanskje ønsker å besvare i teamets kvalitetsstrategi.

Opprette og klargjøre brukerhistorier

Spørsmål: Hvordan bestemmer teamet hvilke brukerhistorier det skal arbeide med? 

Dette kan være en beslutning som tas av hele teamet eller bare av produkteieren. Det kan også være at prioriteringen gjøres av noen utenfor teamet.

Spørsmål: Hvem klargjør brukerhistoriene slik at de blir klare for utvikling? 

Dette kan være hele teamet eller en del av teamet. Ideelt sett bør produkteieren, én utvikler og én tester delta.

Utviklingsprosess

Spørsmål: Hvordan bestemmer teamet hvem som arbeider med hvilken brukerhistorie?

Det kan hende at utviklerne kan velge en hvilken som helst brukerhistorie fra tavlen, eller at hver utvikler har brukerhistorier innen bestemte funksjonsområder som de kan velge mellom. 

I noen team arbeider programvaretestere også med enkle utviklingsoppgaver, for eksempel å endre ord eller farger på en nettside eller legge til automatiserings-ID-er for å gjøre automatisering enklere.

Spørsmål: Hvordan ser «Ferdig» ut for brukerhistorien? Måles det ved at alle akseptansekriteriene i brukerhistorien er oppfylt? Må utvikleren legge til enhetstester før brukerhistorien kan anses som ferdig? Hvordan vet dere at en funksjon er klar for testing? 

I mange team forventes det at utvikleren utfører noe innledende testing for å bekrefte at det som er kodet, er klart for videre testing.

Overlevering av funksjoner

Spørsmål: Hvordan skal en brukerhistorie overleveres til testing?

I noen team gjøres dette ganske enkelt ved å flytte brukerhistorien til kolonnen «Testing» på tavlen. I andre team kreves en mer formell overleveringsseremoni, der utvikleren demonstrerer den fungerende brukerhistorien og kommer med forslag til videre testing.

Spørsmål: Hvem distribuerer koden til testmiljøet? 

Dette virker kanskje som en bagatell, men det kan faktisk være årsaken til mange misforståelser og mye bortkastet tid. Hvis utvikleren tror at det er testerens jobb å distribuere koden til testmiljøet, og testeren antar at utvikleren har gjort det, kan testeren begynne å teste uten å oppdage at den nye koden mangler før vedkommende har brukt betydelig tid på å arbeide med applikasjonen.

Spørsmål: Hvem skal utføre testingen? 

I noen team kan utviklerne ta på seg enkle testoppgaver for å bidra til bedre leveringshastighet, mens de mer komplekse brukerhistoriene overlates til testekspertene.

Utarbeidelse av testplan

Spørsmål: Hvem skal utarbeide testplanene? Hvordan skal de utarbeides? Hvor skal testplanene lagres? 

Noen team foretrekker kanskje å gjennomføre ad hoc-utforskende testing med minimal dokumentasjon. Andre team kan ha omfattende systemer for håndtering av testtilfeller som dokumenterer alle testene for produktet. Og det finnes mange andre alternativer mellom disse ytterpunktene. 

Uansett hva dere velger, bør det være riktig for teamet og produktet deres.

Spørsmål: Hvem skal skrive testautomatiseringen?

I noen team skriver utviklerne enhetstestene, mens testerne skriver API- og UI-testene. I andre team skriver utviklerne enhets- og API-testene, mens testerne lager UI-testene. Enda bedre er det om både utviklerne og testerne deler ansvaret for å opprette og vedlikeholde API- og UI-testene. 

På denne måten kan utviklerne bidra med sin ekspertise innen kodehåndtering, mens testerne bidrar med sin ekspertise i å vite hva som bør testes.

Spørsmål: Hvem skal utføre andre typer testing, som sikkerhetstesting, ytelsestesting, tilgjengelighetstesting og testing av brukeropplevelsen? 

Noen større selskaper kan ha egne sikkerhets- og ytelsesingeniører som tar seg av denne testingen. Små oppstartsbedrifter har kanskje bare ett utviklingsteam som må ha ansvaret for alt.

Testverktøy

Spørsmål: Hvilke verktøy skal brukes til manuell og automatisert testing? 

Valg av testverktøy er svært viktig når du ønsker at hele teamet skal ha ansvar for testingen. Utviklere vil mest sannsynlig ønske å bruke verktøy som benytter det samme språket som de bruker i utviklingen, fordi dette reduserer behovet for kontekstbytte.

Testvedlikehold

Spørsmål: Hvem har ansvar for å vedlikeholde testene? 

Det er utrolig hvor raskt testautomatisering kan bli utdatert. Én endring av et ord på en side kan føre til at en test mislykkes. Ideelt sett bør et team ha en «du ødelegger den, du fikser den»-policy, der testene blir rettet av personen som sjekket inn koden som ødela dem.

Hvis det ikke er mulig, bør du i det minste sørge for at alle i teamet forstår hvordan testene fungerer, og hvordan de skal rette dem i en situasjon der det er behov for en rask løsning.

Feil og teknisk gjeld

Spørsmål: Hvordan håndteres feil når de oppdages under testing? Diskuteres de av utvikleren og testeren, prioriteres de av hele teamet, eller logges de i en oppgaveliste for å bli sett på senere?

Det er ofte lurt å rette feil så snart de oppdages, fordi utvikleren allerede arbeider i den delen av koden.

Spørsmål: Hvordan skal teamet håndtere teknisk gjeld?

Har teamet en avtale om å ta på seg en viss mengde teknisk gjeld per sprint? Noen team har en policy om at når en utvikler ikke har flere brukerhistorier å arbeide med, velger vedkommende oppgaver knyttet til teknisk gjeld fra oppgavelisten.

Utgivelser

Spørsmål: Hva slags testing skal dere utføre før en utgivelse? Vil det finnes en plan for regresjonstesting som hele teamet kan gjennomføre sammen? Hva med utforskende testing?

Et høytytende team jeg kjenner, samles for utforskende testing rett før de lanserer. Ved å bruke denne strategien har de avdekket vanskelige feil og rettet dem før programvaren ble satt i produksjon.

Spørsmål: Hvordan skal programvaren utgis?

I noen selskaper finnes det en utgivelsesansvarlig som tar seg av gjennomføringen av utgivelsen. I andre selskaper bytter teammedlemmene på å utgi programvaren. En svært nyttig teknikk er kontinuerlig distribusjon, der programvaren distribueres automatisk og tester kjøres automatisk for å bekrefte distribusjonen til hvert miljø, noe som sparer alle for tid og arbeid.

Relatert lesning: SLIK KJØRER DU API-RØYKGASS-TESTER I DIN KONTINUERLIGE DISTRIBUSJONSPROGRAMLØYPE

Vedlikehold

Spørsmål: Hvordan skal dere måle hvor vellykket utgivelsen er? 

Når programvaren er utgitt, er det lett for utviklingsteam å glemme den, men det er nå brukerne begynner å arbeide med den. Hvilke typer måleverdier kan dere bruke for å måle hvor godt produktet fungerer? Dere kan følge med på feil som rapporteres av kunder, eller se etter uventede feil i logger.

Spørsmål: Hvordan skal dere overvåke helsetilstanden til applikasjonen?

Det kan være lurt å sette opp varsler slik at dere får vite om problemer med applikasjonen før brukerne gjør det. 

Spørsmål: Hvilke typer atferd bør dere se etter?

Kvalitetsstrategier kan være like forskjellige som snøfnugg. Tenk på forskjellene mellom en liten oppstartsbedrift med ti personer som lager en mobil chatteapp, og et selskap med tjue tusen ansatte som utvikler programvare som får fly fly. Disse to selskapene vil trenge svært ulike strategier! 

Dere kan utforme en kvalitetsstrategi som fungerer godt for teamet, ved å diskutere disse spørsmålene sammen og utarbeide en strategi som dere alle kan bli enige om.

Hvis du vil ha verktøy og teknologi som kan hjelpe med prosessene dine, kan du se på denne listen over DE 10 BESTE VERKTØYENE FOR HÅNDTERING AV TESTDATA.