Har du tænkt over, hvad du kunne teste?

En af de vigtigste diskussioner, vi havde i Rob Sabourins lille tutorial-gruppe på Øredev, handlede om hvorfra ideerne til test objectives og test cases egentlig kommer fra.

En del af de fremmødte luftede frustrationer over sammenhænge, hvor alle test cases forventes at komme fra en mursten af en kravspecifikation; en enkelt havde sågar oplevet at have svært ved at få lov til at rapportere fejl, hvis ikke fejlen kunne henvises direkte til test af et navngivet krav! Meget ofte vil en test, hvis udformning drives for hårdt af krav, have et meget snæver indgangsvinkel, hvor Sabourins pointe var, at vi burde se på en hel række forskellige kilder til testideer, altså potentielle test objectives.

I den øvelse, vi blev sat til at lave for at finde testideer til et fiktivt system, benyttede vi os af små papkort i forskellige farver, hvor farverne repræsenterede forskellige kilder. Pointen med farvekodningen var, at man sikrer sig, at man ikke fokuserer for ensidigt på en enkelt kilde. De kilder, vi arbejdede med i øvelsen var (et mindre udvalg af de 10 kilder nævnt i denne artikel):

  • Capabilities (har ikke helt kunne finde en god dansk oversættelse) – at man forsøger at bekræfte, at systemet faktisk kan gøre det, man forventer. Her er en kravspecifikation, hvis man har en sådan, en ganske udmærket hjælp. Man skal dog huske de mere implicitte krav som f.eks. bagudkompatibilitet, der kan være MINDST ligeså vigtige som de eksplicitte.
  • Fejltilstande – hvordan kan det gå galt? Korrupt input, begrænset miljø (eks. diskpladsbegrænsninger), store datamængder etc. Her ser man på mulighederne for at slå det faktisk designede og implementerede system i stykker, og de oprindelige krav spiller derfor en mindre rolle.
  • Kvalitetsfaktoren – her handler det i høj grad om ikke-funktionelle krav som brugervenlighed og performance. Sabourins erfaring (som jeg også har hørt andre steder fra) er, at det kan være svært at få en kunde eller andre stakeholders til at formulere kravene på forhånd, men man kan måske alligevel lokke noget brugbar information ud ved at spørge til forskellige konkrete scenarier som: ”Hvis der viser sig at være en fejl, som gør, at der kun kan være 10 samtidige brugere på, vil vi så forsinke releaset for at få det rettet?”
  • Brugscenarier – meget ofte bruges systemet i praksis på en helt anden måde end tiltænkt, eller bruges ikke på samme måde af forskellige typer brugere.
  • Kreative tilgange – alternative måder at generere testidéer på, f.eks. ved at forestille sig, hvad der ville ske, hvis Bart Simpson skulle bruge programmet. Læs også gerne mere om Soap Opera Testing, som Hans Buwalda har skrevet en artikel om i 2004, for kan man måske få forsikringssystemets regler til at bryde ned, når man lægger en Woody Allen ind, som gifter sig med sin (adoptiv)datter? Og det gør jo heller ikke noget, at det sjovt at gå på arbejde – heller ikke, når der skal testes! :-)

Hvor får du dine test-ideer fra?

Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Eskild Nielsen

I den forbindelse er det også interessant at se på hvordan man kommer ud af dem igen - Hvis det kræver at nogen aktivt gør noget, er det så acceptabelt, og bliver man ledt i den rigtige retning af de beskeder systemet giver?

  • 0
  • 0
Rasmus Bergstrøm

At teste er jo mange forskellige ting, og det første man skal holde for øje er formålet med at teste. Tester man for at finde fejl eller for at dokumentere at det er testet? Tester man på et tidspunkt i forløbet hvor det i praksis ikke vil være muligt at rette eventuelle fejl før end i et senere release, eller som en del af udviklingen hvor en enkelt iteration internt kan rette op på fejlen?
Personligt synes jeg at tests giver mening hvis man har sig det klart hvorfor man tester og hvad det er meningen at testen skal "producere". Er det en rapport over hvad der er testet eller et bedre porodukt? En blanding?
Det har også betydning om det er et nyt produkt der skal testes for første gang - hvor det kan være noget mere uoverskueligt at komme omkring det hele - eller om det er et nyt release af et eksisterende produkt - hvor der almindeligvis er en liste over "rettelser" man kan have særligt fokus på.

Det er også afgørende hvilke ressourcer man har til rådighed i forbindelse med tests. Bruger man udviklere (måske fra et andet projekt) med domænekendskab kræves der alt andet lige en del mindre forarbejde end hvis man anvender konsulenter udefra. I den helt anden ende af skemaet er "daglejere" - mennesker hyret gennem rekruteringsfirma for testens peiode men uden dybdegående kendskab. Her er det en nødvendighed at dokumentationsgraden af testen er høj.

Min foretrukne metode er at anvende en testspecifikation og exploratory testing i en løs forening. Testspecifikationen vil ofte være genereret ud fra en liste af nye ting der er tilføjet produktet og en cost/benefit-fornuftig regressionstest og sikrer at en tester kommer igennem de flows der er i produktet. Sammenkoblet med exploratory testing (en kombination af "hvad ville min mor gøre"- og "how do i fuck this up"-holdning) giver det i mine øjne en god coverage. Naturligvis betyder det at en del mere af ansvaret lægges på testerens skuldre og en del af dokumentationen af testen går tabt - det er nu en gang konsekvensen af exploratory testing - til gengeld vinder man hver gang der forsøges noget tosset udviklerne ikke lige havde fundet på.
"Men hvorfor trak du netledningen ud? Nu er du i en tilstand der ikke kan reddes!" - jamen... hvorfor ikke ?

  • 3
  • 0
Anne-Sofie Nielsen

Tester man for at finde fejl eller for at dokumentere at det er testet?

Det er et rigtig godt spørgsmål. I en del af de tilfælde, vi diskuterede, var testerne bundet af bestemte krav fra kunderne, så det i realiteten handlede mest om at kunne levere dokumentation.

I den verden, jeg selv arbejder i, hvor vi som udviklingsafdeling lever ét produkt til mange kunder, handler det især om at finde ud af, om det, vi har lavet er godt nok, til at vi vil sende det ud. Ellers må vi rette op på det, om nødvendigt ved at forsinket releaset.

Men Rob Sabourin havde en god pointe omkring hvad man skal teste, nemlig at man kun skal teste ting, hvor udfaldet af testen reelt er afgørende. Man skal ikke bruge tid på at teste ting, som ikke er vigtige nok til, at det får en konsekvens (eks. et forsinket release, at der fjernes anden funktionalitet...) hvis testen fejler. Det giver rigtig god mening, synes jeg.

  • 1
  • 0
Log ind eller Opret konto for at kommentere