Just-in-time testing

Det finns många teststrategier inom den inriktning och det område som kallas kontextdriven testning. En enkel och praktisk strategi, som jag har fastnat för, är ”Just-in-time testing” som har utvecklats av Rob Sabourin. Första gången jag kom i kontakt med Just-in-time testing var på en workshop som Rob höll på Let’s Test-konferensen 2012. Sedan dess har jag använt mig av denna strategi vid acceptanstester i två olika projekt. Just-in-time testing försöker lösa paradoxen att det alltid finns så mycket att testa, så lite tid och dessutom att krav, lösningar, planer et.c. flyter in i det sista. En annan aspekt är att inte stirra sig blind på kravspecifikationen och använda andra källor till information och inspiration för bra tester.

Rob skiljer på aktiviteter som ska göras så tidigt som möjligt i projektet och de som kan vänta till i sista stund. Tidiga aktiviteter är teststrategi och insamling av testidéer. De sena aktiviteterna innefattar konkretisering av testidéer till testfall samt själva testgenomförandet. På så sätt finns det mycket tid för att samla relevant information och vi undviker att låsa fast oss i detaljer kring testexekveringen, förrän det finns ett konkret testobjekt att utgå ifrån. Jämför med att när man ska ge sig ut på en längre bilfärd kanske man kontrollerar bilen lite extra, tittar på väderrapporteringen, vilken väg man ska ta och om det finns vägarbeten eller olyckor. Väl iväg anpassar man sig efter de verkliga förhållandena och löser den praktiska uppgiften att framföra bilen allt eftersom. Lika dumt som att detaljplanera en bilfärd är det att skriva detaljerade testfall långt i förväg, menar Rob. Det finns för många osäkra parametrar för att det ska ge någon verklig nytta.

Det vi istället gör är att ta reda på systemlösningens kontext. Kontexten påverkas t.ex. av den faktiska affären eller verksamheten som ska stödjas, tekniska lösningar samt organisationens möjligheter och begränsningar. Inom Just-in-time kallas dessa aspekter för ”context drivers”. Utifrån kontext skriver vi ner, sorterar och prioriterar våra testidéer. Detta sker löpande så att vi alltid har de viktigaste testidéerna på toppen av stacken, redo att utföras. De prioriterade testidéerna fördelas mellan testarna och när de faktiska testerna närmar sig omvandlas testidéerna till testfall eller sessioner med utforskande testning.

Fördelen med Just-In-Time testing är att man fokuserar på det väsentliga vid varje givet tillfället och undviker slöseri i form av tidigt skrivna testfall som kanske inte håller ända fram. Istället prioriteras testidéer löpande under hela utvecklingscykeln enligt följande form:

1. Hitta dina context drivers, d.v.s. aspekter som påverkar systemlösningens kontext. Genom att aktivt övervaka context drivers kommer du att upptäcka hur kontexten förändras, vilket hjälper dig att planera och prioritera testarbetet.
2. Skapa testidéer utifrån context drivers och prioritera dessa utifrån:
1. Test, viktig att genomföra just nu
2. Test som kan vänta till senare
3. Test som görs ifall tid finns
4. Test som kan vara av intresse i en senare release/fas
5. Test som kan vara av intresse i omarbetad form
6. Test som aldrig kommer att vara intressant
3. Räkna med att ny information från dina context drivers kommer att få dig att ändra prioriteringen och ge uppslag till nya testidéer. Detta är ett iterativt arbete som pågår under hela utvecklingsperioden.

Inom Just-in-time har Rob skapat ett system för att kategorisera testidéer. Kategorierna är till hjälp för att hålla ordning på den ökade mängden idéer. De olika kategorierna ger också uppslag och inspiration till nya testidéer. När dina testidéer delas upp i kategorier kanske du märker att någon kategori är tunnare än de andra och det kanske finns ett värde i att fylla på med fler idéer under dessa kategorier.

1. Den första kategorin kallas för ”capabilities”. Hit hör alla testidéer som rör systemlösningens funktionella krav från kravspecar och användarberättelser, men också införstådda eller icke utryckta krav av denna typ.
2. Den andra kategorin är ”failure mode” och innehåller negativa testfall utifrån vad som kan fallera eller gå sönder. Hur reagerar systemlösningen på felaktiga inmatningar, hur fungerar systemlösningen i en begränsad miljö med t.ex. trasiga integrationer eller lite diskutrymme? Även lasttester eller ”recover”-tester räknas hit.
3. Den tredje kategorin ”usage scenarios” utgår ifrån olika användarscenarios. Vi tittar då på systemflödet i sin helhet och försöker hitta typiska användarfall och grupper av användare som kan genomföra dessa.
4. ”Creative approaches” handlar om alla de kreativa och kluriga testidéer som kan vara av intresse. Här ser vi sådant som såpoperatestning, ”monkey testing”, ”lateral thinking” o.s.v.
5. Den femte kategorin är ”state model” och här placerar vi de idéer som vi hittar genom att titta på applikationens olika tillstånd utifrån en tillståndsgraf.
6. Genom att undersöka datamodeller, flödet av data genom systemlösningen, utbyte av data i integrationer et.c. så samlar vi testidéer under en sjätte kategori som helt enkelt kallas för ”data”.
7. Den tänkta målmiljön för systemlösningen ger upphov till ytterligare testidéer genom aspekter som hårdvara/mjukvara, operativsystem, programversioner, nationella inställningar, webbläsare och klienter. Detta kallar vi för ”environment”.
8. ”White box” är givetvis kategorin för testidéer som uppkommer genom att särskåda den tekniska lösningen. Vad medför arkitekturen för möjligheter och begränsningar, hur är systemlösningen implementerad på kodnivå, vilka tekniska moduler består lösningen av?
9. Den nionde och sista kategorin är ”bug taxonomies”. Det finns register sammanställda över olika typer av buggar och problem som har uppstått i systemlösningar. Dessa finns givetvis tillgängliga på nätet och här kan man få mycket inspiration till olika testidéer.

Agil kompetensöverföring

Det här är en idé för kompetensöverföring som jag har lånat utav min tidigare projektkollega Janne och använt mig av ett par gånger under det senaste året. Det jag försöker uppnå är att, i slutet av ett uppdrag, slippa ändlöst skriftligt dokumenterande. Istället vill jag flytta över ansvaret där det bör ligga – nämligen hos den nya personen.

På en bunt indexkort skriver jag rubrikerna för områden som den nya kollegan måste ha koll på (t.ex. testmiljö, kontaktpersoner, processer/rutiner, testområden o.s.v.). Personen får sedan i uppgift att gå igenom kortleken och prioritera utefter vad hen redan kan och vilket behov som finns i den närmaste framtiden. Det är upp till kollegan själv att ta reda på (och ev. dokumentera) allt väsentligt om de områdena som rubriceras. Personen är fri att fråga vem som helst, men är själv ansvarig för att hitta svar på frågorna och lära sig om det som står på korten.