Timingen er hele poenget. Skriver du testkapittelet før konkurransen, definerer du hva som er god nok leveranse mens alle fortsatt er enige og ingen har brukt penger. Skriver du det underveis, forhandler du om det samme spørsmålet med en leverandør som venter på betaling og en organisasjon som venter på systemet.
De fire testnivåene
| Test | Hvem utfører | Svarer på |
|---|---|---|
| Systemtest | Leverandøren | Virker løsningen slik den er bygget? |
| Integrasjonstest | Begge, sammen med tredjepart | Snakker systemene sammen i praksis? |
| Akseptansetest | Dere | Er kravene oppfylt? |
| Brukertest | Faktiske sluttbrukere | Kan folk gjøre jobben sin med dette? |
De to siste blandes ofte, og det er uheldig. Akseptansetesten er formell og knyttet til kravnumrene. Brukertesten kan avdekke at noe er tungvint selv om alle krav er oppfylt — og det er en verdifull opplysning, men den er ikke grunnlag for å nekte godkjenning med mindre det finnes et krav den bryter.
Knytt testen til kravnumrene
Hvert skal-krav skal ha en måte å bli verifisert på. Har du fylt ut «verifiseres ved» allerede i kravkapitlene, er testplanen nesten skrevet av seg selv.
| Verifikasjonsmåte | Passer for |
|---|---|
| Demonstrasjon | Funksjonalitet en bruker kan se |
| Måling | Ytelse, svartid, kapasitet |
| Dokumentgjennomgang | Rutiner, arkitektur, sikkerhetsdokumentasjon |
| Test med produksjonslike data | Migrering, søk, rapporter |
| Attest eller sertifisering | Standarder, universell utforming |
Se kravet må kunne bevises oppfylt og akseptansekriterier for håndverket i selve kravsetningen. Sporbarheten fra krav til test er beskrevet under nummerering og sporbarhet.
Feilklasser: definer dem på forhånd
Uten avtalte feilklasser blir hver eneste feil en diskusjon om hvor alvorlig den er. Med dem blir den en diskusjon om hvilken klasse den tilhører, som er en langt kortere samtale.
A — kritisk: Arbeidet kan ikke utføres, eller data går tapt. Blokkerer godkjenning. Rettes innen avtalt frist.
B — alvorlig: Vesentlig funksjon mangler eller virker feil, men det finnes en akseptabel omvei. Godkjenning kan skje med avtalt rettefrist.
C — mindre: Feil eller mangel som ikke hindrer bruk. Rettes i neste planlagte oppdatering.
Skriv også hvor mange feil av hver klasse som kan stå åpne ved godkjenning. «Ingen A-feil og maksimalt fem B-feil, alle med avtalt rettefrist» er en setning som sparer uker.
Bestem det nå. Som regel er det dere som klassifiserer, med leverandørens rett til å bestride. Uten en avtalt mekanisme ender uenigheten i et møte uten fasit.
Testdata er et krav i seg selv
En akseptansetest på ti oppdiktede saker beviser lite. Skal du teste ytelse, søk eller migrering, trenger du produksjonslike data i realistisk volum — og da må du samtidig ha ryddet i personvernspørsmålet om hvordan ekte data kan brukes i test.
Skriv derfor et krav om testmiljø med realistisk datavolum, og avklar tidlig om data skal anonymiseres. Det er en jobb som tar tid, og som stopper testen hvis den ikke er gjort.
Sett av nok tid, og de rette folkene
Akseptansetest utføres av dem som kan faget, ikke av prosjektgruppen alene. De samme menneskene har en jobb ved siden av. En testperiode på to uker med fire deltakere er en konkret kostnad som må stå i planen — ellers blir testen utført av én person på overtid, og da finner den bare det som er åpenbart.
Vanlige feil
- Testkapittelet skrives etter kontraktsinngåelse. Da har du gitt fra deg definisjonsmakten over hva som er godkjent leveranse.
- Krav som ikke kan testes. De oppdages her, og da er det for sent. Se kravet ingen kan teste.
- Ingen definisjon av godkjent. Uten terskel blir godkjenning et spørsmål om tålmodighet.
- Testen kjøres på tomme data. Ytelse og migrering kan ikke verifiseres uten volum.