Først og fremst handler utforskende test om å fange opp de sidene ved et system eller en applikasjon som vi ikke ville ha observert på samme måte gjennom de oppsatte testtilfellene våre. Mens vi i scenariobasert testing setter opp tester i forkant av kjøringene for å kunne ha en synlig dokumentasjon på hvordan vi har vurdert krav og resultater, så vil vi i utforskende testing heller være åpne for det som dukker opp underveis.
En av mange oppskrifter
Det er mange måter å legge til rette for utforskende testing på. Mange av dem har til felles at de poengterer at utforskende testing ikke skal være en målløs og strukturløs øvelse. En måte å gjøre dette på er denne:
- Finn et spesifikt område av applikasjonen du vil fokusere på, og da gjerne basert på det teamet oppfatter som en risiko.
- Sett av et bestemt tidsrom for testingen. Hvor mye tid du skal sette av, må du nesten bestemme ut fra hvor mye du ønsker å teste og hvor komplekst systemet er.
- Noter noen ideer for hva som bør testes, gjerne kalt «test charters». La disse ideene styre testingen på et overordnet plan, men uten å hindre deg i å fange opp ny relevant informasjon om applikasjonen underveis.
- Underveis i testingen er det flere ting du kan gjøre for å holde sansene åpne og for å unngå tunnelsyn. Du kan f.eks. bruke sjekklister, såkalte «heuristics», hvor du fortløpende vurderer hva vil fokusere på. Det å hele tiden finne ut hvilke variasjoner som er viktige å teste, er sentralt i denne fasen.
- Skriv ned tester, funn, spørsmål, kommentarer og annet interessant underveis mens du tester. Dette er viktig for å kunne senere kunne komme tilbake for å gjenskape, avklare eller dokumentere det som du har observert. Det er forhåpentligvis flere som er interesserte i det du melder tilbake om.
- Avslutt testingen når du har gått tom for ideer og variasjoner som det er verdt å sjekke ut, eller når du føler at du har sett alt før. Husk at målet med testingen er å gi verdifull informasjon om produktet, ikke bare teste for å teste.
La oss bruke test av en side for innlogging som eksempel på en slik fremgangsmåte i praksis. De scenariobaserte testene ville nok ha dekket det meste av brukernavn og passordhåndtering, og kanskje tilogmed ha testet for grenseverdier og spesialtegn. En utforskende test kunne her ha satt for seg å teste for risikoen at ukjente får tak i data de ikke skal ha tilgang til ved å utnytte mangler ved denne funksjonaliteten. Vi kan da for eksempel sette opp et charter hvor vi skal forsøke å hente ut data ved hjelp av alle tenkelige hjelpemidler, og vi setter av 1 time til dette. Underveis noterer testeren hva som er gjort, tanker om hva som eventuelt kan gjøres og funn.
Utforskende test er av mange sett som en metode for å «bli kjent med» applikasjonen, mer enn det de oppsatte testscriptene vil være. Derfor er det ofte sagt at holdningen er først og fremst å lære seg mer om systemet, fremfor å avsjekke forventninger man allerede har.
Men virker det?
Et viktig kriterie for om utforskende testing er vellykket eller ikke vil være om man kunne ha fått informasjonen eller funnet feil gjennom det faste løpet med scenariobaserte tester og testteknikker. Derfor er utforskende testing ofte benyttet av testere som har lite tid eller lite tilgang på dokumentasjon om systemet. Fremfor å bruke tiden på å skrive ned testene basert på antakelser og forventninger, vil en utforskende test heller forsøke å fange de viktigste egenskapene ved applikasjonen på kort tid. Selv om man ikke rekker å dekke mye, vil man på den korte tiden likevel kunne ha nok informasjon til å peke på områder som bør få mer oppmerksomhet før man produksjonssetter. Etter hvert som automatisering har blitt mer vanlig, har også utforskende test økt i popularitet – nettopp for å kunne å få et bedre totalbilde av kvaliteten.
I tillegg til at testeren må ha erfaring med domenet og/eller testing for å kunne være trygg på hvilke veier man skal velge underveis i utforskingene, så krever denne metoden også at man noterer godt. I utforskende testing skriver man testen underveis.
Med denne friheten kommer også et stort ansvar.
Vil du oppdage mer?
Litteraturen om utforskende testing begynner å bli rik, og noen tips til lesing for å komme i gang er:
- «Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing” av Elisabeth Hendrickson
- “Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design” av James A. Whittaker
Michael Bolton og James Bach er to velkjente kursholdere og talsmenn for utforskende testing. Deres blogger og nettsider er også rike på anbefalinger, tips til heuristics og metode generelt:
- Michael Boltons Rapid Software Testing
- James Bach om Rapid Software Testing Methodology
Ønsker du en mer en hands-on erfaring med utforskende testing, har SOCO Academy et introduksjonskurs i eksplorativ test hvor deltakerne tester en applikasjon veiledet av Frans Dijkman.
