Kategorier
Nyheder Værktøj

Testgrundlag

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”.