Utforskande tester med Tour Testing

2014-08-26 Artikelbanken Test Läst 7870 gånger

Exploratory testing eller Utforskande tester (UT) kan vara ett bra komplement till din testning och dessutom kan denna typ av tester vara en mycket effektiv metod för att hitta de där retsamma buggarna som annars brukar slinka igenom - om dessa tester görs på rätt sätt vill säga! Det är en allmän uppfattning att UT hittar fler kritiska buggar än traditionell testfallsbaserad testning eftersom testaren kan reagera och undersöka mjukvaran utifrån dess beteende istället för att strikt följa ett testfall. Frågan är bara hur man ska göra för att lyckas med sina utforskande tester och undvika riskerna?

Mycket är sagt och skrivet om detta ämne och många hävdar att UT kräver erfarna och kunniga testare för att lyckas. Det ska sedan en lång tid tillbaka sitta i ryggmärgen hos testaren att kunna använda sig av alla olika teststrategier och tekniker för att garantera mjukvarans kvalitet. Jag tycker att man med en metod som kallas Tour testing slår hål på den myten till viss del eftersom testerna här kan anpassas till testarens erfarenhet och systemkännedom. Min uppfattning är att UT framförallt kräver styrning, mål och dokumentation för att vara effektiv och inte erfarenhet. Även fast erfarenhet i de allra flesta fall är något som bidrar positivt till dina testaktiviteter. Tour testing är en enkel och rolig metod som jag tycker synliggör möjliga angreppssätt och ”taktiker” vid test och dessutom kan fungera som karta och kompass både när du planerar och utför UT eller för den delen som komplement till dina testfallbaserade tester. Metoden belyser var testet ska utföras och vad fokus och målet med testet är på ett väldigt lättförståeligt och tilltalande sätt.

Innan vi går in på själva Tour testing tänkte jag som bakgrund belysa några av de risker som lätt kan uppstå i samband med UT och även med manuella testfall.


Utforskande tester

I linje med det agila tänket så utgår UT från att man inte vet allting i början av processen utan litar istället på att testaren utifrån dennes erfarenheter, kreativitet och egna beslutsförmåga kan komma fram till det bästa testet utifrån en testidé.
Den testrelaterade inlärningen är central och testaren tar hela tiden med sig sina nya erfarenheter för att skapa nya tester och utvärdera kvalitén på mjukvaran. Under tiden dokumenteras testförfarandet. Detta för att det ska gå att återupprepa scenariot vid avvikelser, följa upp testet samt återupprepa testet senare.



Turistproblematiken

James A. Whittaker beskriver i boken Exploratory software testing riskerna med traditionell UT och manuell testfallsbaserad testning utifrån ett turistperspektiv. Den metaforen har fastnat på mig.

Utforskande testning

För att belysa riskerna med UT kan man dra en parallell mellan testaren och en turist som ska åka till London för första gången utan att göra någon som helst research om staden innan. För att upptäcka staden vandrar turisten planlöst omkring på gatorna i hopp om att stöta på roliga och intressanta saker. Troligtvis kommer turisten att stöta på en och annan intressant sak, men utan någon förkunskap blir det svårt att förstå vad det är och betydelsen av upptäckterna som gjorts. Det här gör inte upplevelsen speciellt rik eller kvalitativ och framförallt är risken stor att turisten missar massa intressanta sevärdheter eftersom tiden rinner iväg när denne planlöst går omkring. Turisten vet inte heller hur stor staden är så det blir svårt att veta hur mycket som finns att utforska. Om detta översätts till test av mjukvara så förstår vi snart att stora risker uppstår. Visst kommer turisten ändå uppleva delar av London och troligt är att denne hittar några bakgator och genuina ställen som man annars kanske inte hade stött på.

Manuell testfallsbaserad testning

Riskerna med manuella testfallsbaserade tester kan istället likställas med en väl förberedd turist som innan resan till London läser alla möjliga guideböcker och antecknar vad man vill se och göra under sin vistelse. Turisten kollar upp kartan, valuta, restauranger, transportmedel, väder, evenemang, ja allt man kan tänka sig och gör sedan en detaljerad tidsplan för hela vistelsen. Den här turisten kommer antagligen se mer av de stora sevärdheterna eftersom den har förkunskap om dem och vet vart de ligger och hur de ser ut, men frågan är hur mycket annat turisten kommer se? Kommer den hitta de små bakgatorna och pittoreska kvarteren som är det genuina London? Risken finns att dessa points of interest förblir oupptäckta.

Andra risker med Utforskande tester

Nedan tänkte jag prata om några av de risker som jag själv stött på när jag jobbat med utforskande tester.

Endast positiva tester

En stor risk med UT är att fokus endast hamnar på positiva, funktionella tester då testarna inte får någon styrning. Man utgår ifrån det man vet, vilket brukar vara krav eller sina egna erfarenheter om hur mjukvaran ska fungera och vad den ska klara av. Detta är vanligt bland juniora och ovana testare och dessa positiva tester kan i mångt och mycket likställas med ”checking”. Genom Tour testing kan man på ett tydligare sätt få juniora testare att hitta infallsvinklar och angreppssätt samtidigt som man hela tiden bygger på kompetensen och utökar verktygslådan.

Låg testtäckning

En väldigt stor risk med UT som växer med komplexiteten på mjukvaran är att man får en relativt låg test-täckning (coverage) mot vad man borde kunna få med UT. Eftersom människan i sin natur är snäll och gärna vill hitta vägar runt problem så finns risk att testare går runt komplexa delar med knepiga funktioner och testar i de områden/programflöden där de känner sig hemma. Det kan också vara av ren vana som i att ”Jag sparar alltid mina värden genom att använda Arkiv-menyn” istället för att använda de snabbkommandon eller andra mekanismer som finns för spara i applikationen.

Bristande struktur

Det kan vara väldigt lätt att grotta ned sig i en viss del av en applikation om man hittar något som verkar avvikande eller helt enkelt drar uppmärksamhet till sig. När man kombinerar sessionsbaserad testning med UT och 80 % av tiden ägnas till denna ”intressanta del” så säger det sig själv att resterande delar inte kommer få lika mycket uppmärksamhet. Hade testledaren avsikten att applikationen skulle testas igenom på en mer övergripande nivå eller med annat fokus kan testet bli missvisande om inte tiden rapporteras på en väldigt låg detaljnivå.

Kanske känner du igen dig i några av de här påståendena om risker och skulle vilja veta vad man kan göra åt dem? ”Keep calm and keep reading”.

Tour testing

Som en lösning på problematiken med riskerna inom UT och manuella testfallsbaserade tester finns metoden Tour testing som utnyttjar fördelarna i de båda metoderna. Med UT hittas generellt fler kritiska avvikelser och lite udda saker, medan man i de manuella testerna minimerar riskerna att missa viktiga områden och centrala funktioner.

Metodens grundpelare är ”Districts” och ”Tours”. Det går ut på att man delar upp resmålet i Districts (områden i mjukvaran som kan behandlas eller testas på ett likartat sätt) som till exempel:

  • Business District - där kärnverksamheten i mjukvaran finns,
  • Historical district - där gammal lagrad information finns eller
  • Tourist District - dit ovana användare ofta drar sig.

Sedan åker man på olika Tours (testsessioner med en teststrategi) i områdena för att utforska dem. Exempel på tours kan vara:

  • Guide book tour där man följer manualen till punkt och pricka,
  • Super model tour där man bara tittar på det yttre, det vill säga allt som har med GUI att göra,
  • FedEx tour som innebär att man följer ett värde eller ett objekt genom hela systemet för att se hur det transporteras och förändras för att slutligen nå mottagaren.

Det går att likställa tours med att man sätter på sig en viss sorts glasögon som hjälper en att se det man vill och ska fokusera på. Det hjälper testaren att ta beslut i både vilka vägar den ska gå men också vilken input som denne ska mata mjukvaran med. På det här sättet kan man tvinga testaren bort från ensidiga positiva tester.

Jag upplever att man med hjälp av metoden gör det enkelt att sätta fokus på en sak åt gången eftersom det är uttalat att en viss tour ska köras i ett visst område eller för ett visst testfall. Strukturen infinner sig och det kan öka kvalitén på testet i sig själv. Går det att hitta tourer som kan kombineras kan man öka effektiviteten ytterligare. Även då ett uttalat fokus finns, så finns det så klart inget som hindrar att man undersöker och testar och rapporterar avvikelser som ligger utanför tourens ramar när man stöter på dem, för det kommer man att göra (man är ju nyfiken!), så länge man kommer tillbaka till tourens fokus i slutändan.

En förutsättning för att lyckas med metoden är att testaren har koll på vilka Districts som finns i systemet och deras ”gränser”. Är det inte självklart i mjukvaran, vilket det oftast inte är, bör man innan testerna påbörjas definiera dessa så att alla vet exakt vilket område de ska testa när de sedan åker på en tour. På det här sättet får man också en bra överblick av systemet och kan se till att ingen del glöms bort. Vilka områden ett District ”gränsar” till kan också vara bra att definiera. Ett bra sätt att göra detta på är att rita en grafisk modell av systemet där de olika områdena är uppritade med funktioner eller delsystem under sig. Då kan man också på ett enkelt sätt se gränserna och vilka delar som ska testas ihop som ett District.

De olika tourerna, eller utflykterna om man vill använda det svenska begreppet, är också bra att definiera i förväg. Några vedertagna utflykter finns redan men här är ett utmärkt tillfälle att låta fantasin flöda och hitta på egna som passar just er verksamhet och mjukvara. Att sätta upp ett korsreferensschema med vilka tours som passar i vilka District kan också vara en förberedande aktivitet som gör det enkelt för testare att bara gå in och välja en färdigpaketerad utflykt. Har man en enskild funktion eller ett delsystem så kan man så klart kombinera det med möjliga Tours också.

Nedan är ett exempel på några district och tours och dess betydelser men som sagt är det upp till dig att bestämma hur du vill applicera begreppen i dina tester.

DISTRICTS TOUR
Business district
Här finns de viktigaste och grundläggande funktionerna i systemet.
Guide book tour
Turista slaviskt efter manualen och se till att den stämmer överens med systemet.
Entertainment district
I detta District brukar ”Nice to have”-features samlas.
Landmark tour
Besök alla de stora besöksmålen i ett District.
Historical district
All historisk information som finns lagrad i systemet, eller har systemet kanske gammal kod som testas sällan?
Taxicab tour
En taxichaufför kan alla gator i systemet och här gäller det att testa alla vägar fram till samma mål. Att spara med CTRL + S, spara-knappen eller via Arkiv-menyn är ett exempel.
Hotel district
Vilande data måste också testas. Vad händer i systemet när det vilar?
FedEx tour
Följ ett värde genom systemet från avsändare till leverans.
Seedy district (Skumraskkvarteren)
Alla system har dem. Udda funktioner eller delsystem dit endast ett fåtal användare går och kanske gör de förbjudna saker där?
Saboteur tour
Ha sönder saker är alltid roligt! Gör saker i fel ordning, ange ogiltiga värden eller varför inte rycka nätverkssladden mitt i en transaktion.
Tourist district
Hit drar sig nya användare av systemet. Det handlar om enkla och lättillgängliga funktioner som kan besökas snabbt.
Couch potato tour
Gör så lite som möjligt! Fyll inte i formulären innan de skickas, gör inte de nödvändiga stegen utan bara de sista, peka inte ut sökvägar eller filer. Var en lat användare!
Forbidden district
Vilka kvarter är det man inte får besöka utan speciellt tillstånd?
All-nighter tour
Lämna systemet igång över natten. Kör en lång operation eller bara låt det stå. Vad händer?
Supermodel tour
Yta blir allt viktigare. Testa allt som har med GUI att göra.
Three hour tour
Åk på en tretimmars-utflykt och sätt ett mål med utflykten.
Anti-social tour
Gör allt tvärsom mot vad det är tänkt. Ska fältet ta emot siffror - försök med bokstäver. Ska man börja uppifrån - Starta nedifrån.

Positiva följdeffekter

Tour testing är inte bara roligt och kunskapsbyggande, jag har också märkt att den drar med sig en hel del positiva följdeffekter!

  • Det går snabbt att förklara metoden eftersom metaforerna har väldigt hög igenkänningsfaktor. Detta gör att testarna snabbt förstår och kan sätta sig in i metoden och dessutom kommer ihåg och tycker det är kul att använda den!
  • Den går snabbt att komma igång med. Många tourer finns beskrivna här i artikeln och i boken Exploratory Software Testing och din mjukvara hoppas jag du som testare känner till!
  • Metoden bidrar till att höja kompetensnivån över tid, framförallt på ovana eller juniora testare eftersom de blir uppmärksammade på nya infallsvinklar i hur man kan testa mjukvara.
  • Den hjälper också testaren att ta beslut i alla de hundratals små val som en testare ställs inför dagligen. Val som i vanliga fall lämnas helt till testaren och ofta därför ofta blir slumpartade.
  • I de fall när man vill använda slutanvändare eller andra ovana testare så kan Tour testing vara en värdefull metod. Med relativt lite förarbete kan man sätta ovana testare i jobb eftersom man kan anpassa svårighetsgraden och ge dem de ”lätta” tourerna.
  • Har man väl tagit fram en lista med olika tourer är den väldigt användbar som en påminnelse om olika typer av tester som kan användas när som helst.
  • Tour testing är ett kraftfullt redskap för testledaren när denne ska planera tester och vill ha en stor coverage och variation på testerna. Samma tour kan utföras av olika testare för att ytterligare få variation.
  • Tillsammans med sessionsbaserad testning är metoden ett riktigt kraftfullt instrument för att planera och genomföra utforskande tester.
  • Metoden skapar intresse och det dröjer inte länge innan andra avdelningar sticker in huvudet och frågar "Vad håller ni på med för utflykter här inne på Test då?".
  • Att den konkretiserar UT så utomstående förstår vad man gör är även det en positiv sidoeffekt.
  • Över tid bildas också ett gemensamt språk som gör att man inte bara säger att man ska testa utan också HUR man ska testa när man pratar om tours.

Sammanfattning

Det absolut mest värdefulla Tour testing bidrar med är ett lättförståeligt sätt att konkretisera och prata om de utforskande tester som rutinerade och duktiga testare utför på daglig basis. Den belyser alla olika sätt en mjukvara kan testas på och leder testaren in på vägar som den annars kanske inte skulle ha testat. Utflykterna har olika svårighetsgrader och inriktning och kan anpassas till testarens nivå och olika produkter. För juniora testare så är metoden en ögonöppnare och verktygslåda. Dessutom kan de olika tourerna/testidéerna användas som utgångspunkt när man skriver manuella skriptade testfall eller läggas på som en extra dimension när man exekverar testfall.

Med Tour testing kan man styra tester på en övergripande nivå i planering och strategi men också på den lägsta nivån i de val en testare gör under en testsession. Som testledare upplever jag att man lättare kan planera och på ett enkelt sätt säkerställa att en viss typ av test utförs inom ett visst område i mjukvaran i kombination med de fördelar som utforskande tester ger. Dessutom kan man se till att testernas coverage ökar om man varierar utflykterna. ”How great is that?”

Så mitt råd till dig är att hitta och ringa in dina Districts i mjukvaran, definiera dem och hitta utflykter som passar. Lek med metoden och prova dig fram och glöm inte bort att ha roligt på vägen!

Nästa steg

För att lära dig mer om agilt testarbete rekommenderar vi vår utbildning Agil test.

Läs mer om utforskande tester i vår Faktabank:

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

 

Dela artikeln