Planlegg for feil!

Leveranser skal skje på gitte tidspunkter. Ofte jobbes det knallhardt inn mot lansering. Har en ikke planlagt for å drive med kvalitetsarbeid og testledelse i utviklingsfasen kan det fort gå galt. Å planlegge for feil er en investering som lønner seg.

Av: Torbjørn Laukvik, seniorkonsulent i Webstep

Når rutinene for å spore feil er blitt etablert, og alle går i samme retning, er det en fordel å tenke litt langsiktig på hvordan man kan teste for å sikre kvalitet i alle ledd. Enkelt sagt så betyr det at man lager en testplan.

En testplan er gjerne det første man lager for å ha en kontrollert fremgangsmåte når en tester. Hvis din bedrift har mange parallelle prosjekter, så kan det lønne seg å lage en strategi også. Noen kaller dette en “teststrategi” mens andre har kaller det en “master testplan”. Kjært barn har mange navn.

Så hva trenger man? Skal en ha både teststrategi og testplan? Skal vi alle ta en Ole Brumm, og si “Ja takk begge deler”, eller holder det med en av delene?

Enkelt forklart kan vi si at en teststrategi vil legge frem de store linjene for hvordan bedriften eller avdelingen skal teste, mens en testplan identifiserer hvordan et enkelt prosjekt skal gjøre dette rent praktisk.

Med denne tolkningen kan vi trygt si at det aller viktigste er å lage en testplan. Planen kan være meget enkel, men skal dokumentere for andre aktører at prosjektet har gjort seg visse tanker om verifisering av kvaliteten på sluttproduktet.

Og det er dette som er målsettingen for alt av testarbeid, nemlig sikre seg at sluttproduktet faktisk er av god nok kvalitet til å kunne brukes av andre.

Innholdsfortegnelse og mange vil ha mer

Tar man et raskt nettsøk om testplan så vil det dukke opp mange eksempler og standarder for dette. Den mest kjente er nok IEEE 829, og den er et godt utgangspunkt. Vi i Webstep har også laget en presentasjon som kan være nyttig for å forstå de viktigste punktene som bør dekkes når en testplan skal utvikles. Presentasjonen finner du nederst på denne siden.

Om følgende punkter er hensyntatt, har man et godt utgangspunkt for å planlegge et testløp:

– Testaktivitetene – beskrivelse av aktiviteter, teknikker og verktøy
Funksjonelle tester
Ikke-funksjonelle tester
– Plan/tidspunkt for når de ulike aktivitetene skal utføres
– Ressurser som trengs for å gjennomføre testene
– Krav til testmiljø og testdata ihht. GDPR
– Testverktøy
– Akseptansekriterier
– Risikoer forbundet med testplanen
– Leveranser

Det aller viktigste man skal ta med seg når man lager en testplan er at lengden på dem ikke er avgjørende. De kan være lange og omfattende eller korte og konsise. Det viktigste er at den blir tatt i bruk og at den gir en verdiøkning til både planleggingen og gjennomføringen av prosjektet eller endringen.

Aksepetansekriterier

Et av de viktigste punktene i listen over er akseptansekriterier for prosjektet. Hva er godt nok til å gå ut i produksjon? La oss ta et lite dykk angående dette, og se på hva det betyr for ditt prosjekt. For dette er som alle andre punkter på listen sterkt påvirket av hva som utvikles.

Et prosjekt som utvikler en plattform hvor liv og helse står på spill, vil gjerne ha strengere krav for hva som kan aksepteres av kjente feil, enn en spillapplikasjon på en telefon. På den andre side kan et spill gi store økonomiske tap ved lav kvalitet. Dette må hensyntas.

Antall feil

Det er veldig vanlig i standardkontrakter at man har definert et visst antall feil som godkjent for å kunne gå i produksjon. Dette ser gjerne slik ut:

– Hvor mange Blokkerende
– Hvor mange Kritiske
– Hvor mange Alvorlig
– Hvor mange Mindre alvorlig
– (trivielle er gjerne ikke med her)

Disse punktene er ofte ikke relevante for et prosjekt, fordi det reduserer en kompleks leveranse til en enkelt oversikt. Det er ekstremt sjeldent prosjektet blindt vil bruke dette som en avgjørelse på om en produksjonssettelse er fornuftig. Ofte vil tidspress og andre hensyn bety mer enn om det er 5 eller 6 kritiske feil i løsningen. Og hva om det er planlagt feilretting kort tid etter release? Da er det kanskje ikke så galt å ferdigstille prosjektet. Det er helheten i hva som kan gjøres og utbedres som er avgjørende.

For å sammenligne med snekkerarbeidet, og grunnen til at vi tester; Hvor stort behov er det for kunden å bo i hjemmet som har blitt bygget? Vil det være akseptabelt å flytte inn hvis vinduet som mangler blir byttet en uke etter? Holder det med et plastvindu i mellomtiden? Er det vinter eller sommer?

Det viktigste er at prosjektet tar en beslutning på hvor det er og hvor fort det kan korrigere problemer og viktige feil. Dette bør være beslutningsgrunnlaget, og ikke et gitt standard tall som i realiteten “aldri” brukes.

Andre måter å se på status

Etter at man blir enige om hvordan akseptere feil, er det et par andre ting man også bør ta med i en rapport. Dette kan gi innsyn i hvor godt man har testet og en generell status på antatt risk.

– Prosent av antall tester kjørt ifht. planlagte tester
Status på test: feilet eller godkjent

– Inndele tester i kategorier:
Feil pr kategori. Dette kan vi kalle opphoping av feil
Tester kjørt per kategori

– Prosent av definert risikoområde dekket

– Liste over feil:
Basert på alvorlighetsgrad
Evt andre måter å kategorisere feil på som gir mening for ditt prosjekt

Det finnes mange måter å definere hva som er godt nok. Dette er bare generelle forslag og kan ses på som et utgangspunkt.Det viktigste er at testplanen/rapporten blir kommunisert ut, og at vi får en bred enighet og forståelse for test-aspekter  gjennom prosjektet.

Oppsummering

I en teststrategi skal man kort  forklare hvorfor man tester, og hvilke aktiviteter virksomheten ønsker skal gjennomføres for at prosjektet skal bli realisert med en akseptabel grad av kvalitet.

Testplan handler om hvordan et spesifikt prosjekt skal oppfylle strategien, men kan fint planlegges uten tilhørende strategi. Det aller viktigste med en testplan er at den inneholder informasjon i et format som blir lest og hensyntatt. Less is more!

Ledende på test

Hvis du har et behov for å verifisere en leveranse eller et prosjekt, så nøl ikke med å ta kontakt med oss! Vi dekker hele test- og kvalitetsløpet, fra kvalitets- og teststrategi, til gjennomføring, oppsummering og rapportering.

Webstep har lang erfaring fra testing av ulike plattformer og teknologier, og er sertifiserte innen standarder som ISO, ISEB/ISTQB Test Manager, Advanced og Agile Test. Ta kontakt for en prat om mulighetene!