Når man som jeg har arbejdet med test, så bliver man med tiden klogere på, hvad der skal til for at kunne gøre et godt stykke arbejde med at få testet software, inden det sættes i produktion.
Helt grundlæggende er det vigtigt at forstå at test ikke er et mål i sig selv, men det er en støtteproces til udvikling af software (udviklingsprocessen). Det gælder uanset hvilken udviklingsmodel man har valgt i sin virksomhed, lige fra traditionel vandfaldstilgang og frem til f.eks. SAFe (Scaled Agile Framework) eller LeSS (Large Scale Scrum).
En af de væsentlige input til test er det som vi testere kalder Testgrundlag eller Testbasis.
Testgrundlaget er dokumentation af eller viden om produktet.
I det efterfølgende handler det primært om hvilken dokumentation der er en del af testgrundlaget. Når det handler om viden, der ikke er dokumenteret, kaldes det for orakler – det tager jeg i et andet indlæg.
Indholdet i et testgrundlag kan opdeles i følgende grupper.
Krav
Krav beskriver de ønskede funktionelle eller ikke-funktionelle komponenter eller systemadfærd.
- forretningskrav,
- funktionelle krav,
- systemkrav,
- epics,
- user stories,
- use cases
eller lignende arbejdsprodukter.
Design
Design specificerer komponent eller systemstruktur.
- diagrammer eller
- dokumenter,
der beskriver system- eller softwarearkitektur,
- designspecifikationer,
- kaldegrafer,
- modeldiagrammer,
- grænseflade-specifikationer
eller lignende arbejdsprodukter.
Implementering
Implementering af komponenten eller systemet selv, herunder kode, database metadata og forespørgsler og grænseflader.
Risikoanalyserapporter
Risikoanalyser der kan vurdere funktionelle, ikke-funktionelle og strukturelle aspekter af komponenten eller systemet.
Kvalitetsmål
F.eks. ISO 250xx eller lignende, virksomheds-standarder, branchestandarder, regulatoriske krav
Dækningskriterier
Testgrundlaget (for alle de niveauer eller typer af test, der overvejes) har målbare dækningskriterier specificeret.
Dækningskriteriet kan fungere effektivt som key performance indikatorer (KPI’er) til at styre de aktiviteter, der viser resultaterne af softwaretestens målsætninger.
Eksempel: en mobil app har en liste af krav samt en liste over understøttede enheder. Dette medfører to dækningskriterier: Krav og understøttede enheder.
Når der ikke er et testgrundlag eller et mangelfuldt testgrundlag
Når man som tester får en opgave med af få testet et stykke software, hvor der mangler f.eks. krav, beskrivelser, forretningsflows og lignende, så står man allerede to skridt bagud i forhold til at få løst sin opgave.
Der er ingen vej uden om at få fremskaffet tilstrækkelig information om softwaren og den forretning, hvor softwaren skal passe ind.
Det betyder at testeren går i detektiv-mode og prøver at opsnuse så meget information som muligt fra alle de mulige kilder, der er tilgængelige.
Min oplevelse er at den type af information, der er sværest tilgængelig, er den viden der sidder i hovedet på nøglepersoner (kaldet orakler af testere). Det næstsværeste er at have et referencesystem (også kaldet orakel) til rådighed (et system der skal erstattes med noget nyt).
For meget ofte har har nøglepersoner ikke tilstrækkelig tid til at levere informationen – sætningen “du kan bare spørge hvis du vil vide noget” kan tage modet fra selv den bedste tester. Lidt det samme med referencesystemer, hvor der sjældent er noget dokumentation og de personer der oprindeligt har fremstillet systemet er ikke længere til rådighed. Gys.
Så jeg har et meget firkantet udsagn, indrømmer jeg, men alligevel:
“Ingen testgrundlag – ingen test”.
Nogle organisationer har en generel testmetode, som i et vist omfang er fleksibel mht. indhold, men kan være strengt kontrolleret af dikterede processer. Det kan have sin relevans at teste sit produkt efter en sådan metode, hvis man ønsker at sende en raket til Mars med mennesker ombord eller hvis man har et farmaceutisk præparat til brug på mennesker. Der kan i stedet for menneskeliv være store værdier på spil, som man vil undgå at tabe, f.eks. i en bank eller en pensionsfond.
Det vigtigste formål med test er at man skal indsamle informationer nok til at kunne evaluere produktet og samtidigt nok til at lære produktet tilstrækkeligt godt at kende.
Testmanagerens indsats sikrer en kvalificeret og struktureret håndtering af testaktiviteterne. Testmanageren etablerer en løbende fokusering på de kvalitetsmæssige egenskaber af produktet i projektet.