Testdata, ofta underskattat

Relevant testdata är en förutsättning för bra tester under en systemlösnings hela livscykel. Ofullständig eller felaktig testdata får till följd att testerna tar lång tid, testernas kvalité minskar och att felaktigheter ej upptäcks. Testdatahantering är en viktig del av testarbetet men tyvärr underskattas ofta svårigheterna med att ta fram bra testdata. Mycket tid läggs i regel på att förstå kravspecifikationen och att ta fram relevanta testfall utifrån denna. Det är mer ovanligt att testare ingående studerar datamodellen och informationsflöden, vilket kunde ge bra underlag till krav på testdata.

Kraven på testdata skiljer sig mellan olika faser. I tidiga faser efterfrågas väldigt specifik data kopplade till kravuppfyllnad, såsom randvillkor, olika datatyper, särfall, kombinatoriska villkor o.s.v. Det är också viktigt med testdata för att representera olika felfall för negativ testning och felhantering. Ofta automatiseras tester i tidiga faser. Detta ställer särskilda krav på testdata.

I senare faser finns ofta behov av att använda så produktionslik data som möjligt. Systemlösningen kanske ska kopplas ihop med angränsande system som förutsätter produktionslik data och det kan också vara så att testmiljön i sig kräver produktionslik data. Ytterligare en orsak är att användare som testar i senare testfaser ska kunna känna igen sig i lösningen och reagera på oförutsedda händelser. Deras arbete underlättas om det finns ett visst mått av igenkännande till att börja med.

En del tester förbrukar testdata. Det är då viktigt att ny testdata kan genereras eller att testdata snabbt läsas tillbaka. Vid sådana förstörande tester går det ofta åt stora mängder och i regel underskattas behovet initialt.

Komponenttest

Komponenttest, modultest eller unit test är tester som i regel görs av utvecklare i samband med implementationsarbetet. Komponenttester sker på mycket låg nivå för kontroll av specifika algoritmer, transformationer, I/O-hantering och andra isolerade delar av koden. Komponenttesterna automatiseras ofta och körs i samband med kodbyggen. Det är därför viktigt att testdata som används är väldefinierad och kan nyttjas med ett minimum av manuell hantering. Eftersom testerna upprepas ofta så bör dessa vara av icke-förstörande art och testdata kan i regel återanvändas. Testdata för komponenttester hanteras ofta som en del av utvecklingsmiljön, eller kanske t.o.m. som en del av testautomatiseringen. Det finns sällan ett behov att administrera testdata över flera systemlösningar utanför utvecklingsteamet.

Systemtest

Tester som sker som en del av systemutvecklingen med fokus på ett isolerat system och med syfte att kontrollera kravuppfyllnad, kallas för systemtest. Systemtest utför i regel av testare i en dedikerad systemtestmiljö. Vid systemtester används olika former av testtekniker (t.ex. ekvivalensvärden, gränsvärden, negativ testning) vilket ställer krav på speciellt framtagen och noga designad testdata. Testdataset hålls ofta relativt små och lätthanterade, men testdatat är i regel noga strukturerar och uttänkt för att kunna motionera systemet på djupet. Eftersom fokus är på ett specifikt system så är det en fördel att begränsa antalet kopplingar till angränsande system, eller i alla fall hålla integrationerna så väldefinierade som möjligt. Testdata för omkringliggande system kan därför hållas enkel. Systemtester kan med fördel automatiseras och det ställer ytterligare krav på väldefinierade dataset. Känt start- och slutläge, spårbarhet o.s.v. är en förutsättning för en automatiserad testimplementation. Automatiseringen blir då lättare att underhålla.

Systemintegrationstest

Vikten av välordnad testdata kan ej underskattas när det gäller systemintegrationstest. Syftet med systemintegrationstesterna är att testa kommunikation, integration och funktionalitet som sträcker sig över flera olika system. Gemensam testdata som är synkroniserad mellan alla systemen är en nödvändighet. En utmaning är att hålla data synkroniserad över tiden. Allteftersom testerna pågår kommer data att förändras och kanske förstöras. Det är därför viktigt att kunna återställa data effektivt, alternativt generera ny data. Till sin natur påminner testdatat, som används, mycket om data under systemtest, med den skillnaden att testdata dessutom ska hänga ihop mellan alla inblandade system.

Acceptanstest

Tester som genomförs av beställarorganisationen/verksamheten kallas för acceptanstest. Detta sker ofta i produktionsliknande miljöer och med produktionslik testdata. Anledningen till detta är att testresurser med stor verksamhetskunskap ska känna ett visst mått av igenkännande och kunna göra rimlighetsbedömningar. Fokus brukar ligga på tester av hela verksamhetsflöden och ofta med flera integrerade system. Testdata ska återspegla verkligheten och är sällan konstruerat från grunden utifrån specifika testfall, såsom ofta är fallet vid systemtest.

Prestandatester

Prestandatester är ett område med behov av stora datamängder. För relevanta presetandatester behövs i regel en datamängd i samma storleksordning som produktionssituationen. Det kan vara svårt att framställa nödvändig data i högkvalitativ form men kanske det är möjligt att använda multipla kopior på dataset med minimala skillnader. Under prestandatest är det oftast kvantitativa egenskaper hos testdata som efterfrågas.

För att undersöka hur systemet fungerar över en längre tid används lågintensiva prestandatester med lång körtid. Minnesläckage och eller begränsade resurser kan göra att fel uppstår efter en längre tids nyttjande. Detta område kräver ofta stora mängder testdata, alternativt oförstörbart data, då tester ibland pågår under flera dagar.

Testdataverktyg

Det finns speciella verktyg för att hantera testdata. Testdataverktyg består av en testdatamotor som hanterar testdata utifrån givna specifikationer, samt en lagringsyta där färdighanterad testdata kan hämtas. Testdataverktyg gör i princip tre olika saker. Generering av ny testdata, avidentifiering av produktionsdata och indelning av testdata i olika delmängder.  Dessa uppgifter kan köras i sekvens och automatiseras. Huvudsyftet är att hålla testdata synkroniserat under hela processen så att data sen kan flyttas till testmiljöer och användas för tester av ett eller flera system.

Kommentar angående en generell teststandard

Det här är en kommentar angående arbetet att ta fram en generell och heltäckande standard för mjukvarutestning. Detta pågår verkligen (!) under beteckningen ISO 29119 och kommenteras ytterligare på http://www.testzonen.se/?p=4959.

Jag tror försöken att standardisera, certifiera och på andra sätt styra testarbete med generella och mer eller mindre heltäckande pappersprodukter, beror på en vanlig missuppfattning. Många tror fortfarande att mjukvaruutveckling sker enligt en löpandebandprincip med ett antal efter varandra följande utvecklingssteg och ordnande överlämningar däremellan. Så ser naturligtvis inte verkligheten ut. Allt utvecklingsarbete, inklusive test, är en halvt kaotiskt, utforskande, intellektuellt stimulerande och därmed svårdefinierbar verksamhet som inte låter sig beskrivas i processform. Därför försöker ingen heller att ta fram generella standarder för t.ex. producerandet av kod.

Varför sker då sådana initiativ inom testområdet? Kan det bero på den ingrodda ovanan att skilja på utveckling och test? Att man ser på testarbetet som en avstämning av färdiga leveranser? Att man ser på testare som revisorer med uppgift att kontrollera utvecklingsarbetet i efterhand? Detta är isåfall ett begränsande sätt att se på test som förminskar nyttan av vår profession. Jag menar att test är en del av utveckling och sker innan under och efter programmeringsstegen i samarbete med utvecklare, kravanalytiker, arkitekter och alla andra. En generell standard för mjukvarutestning riskerar att ytterligare driva in kilar mellan utvecklingsarbete och testarbete. En tråkig utveckling tycker jag.

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.

Sprintfokus på burk

På fjället eller i skärgården åker ofta burkmaten fram. Burkmat är praktiskt såtillvida att den ger snabb bukfylla och kräver minimal ansträngning. Nackdelen är att man tröttnar ganska snabbt och börjar längta efter mer vällagad föda. Lite på samma sätt är det med detta blogginlägg om sprintfokus på burk. Här samlar jag ett par enkla tips som är ganska lätta att komma igång med och brukar ge bra resultat. Det är vad jag brukar börja med i utvecklingsteam som jag har arbetat med. Min sprintfokus på burk räcker på bara en bit på vägen och rätt snart är det dags att börja med mer anpassade och genomarbetade åtgärder, men då har teamet säkert hunnit igång med retrospektiv och egna förbättringsförslag.

Fokustavla och fokusmöte
Jag brukar alltid starta med att bygga en fokustavla och det finns bra skäl för detta. Att använda en fokustavla är enkelt att införa och ger ofta bra resultat. Tavlan används för visualisering, kommunikation och självorganisering. Även utan andra förändringar så gör fokustavlan att gruppen för en enad bild över leverans och kvalité. Fokustavlan kompletteras gärna med ett dagligt fokusmöte för att ytterligare hålla ihop gruppen.

Grundarbete inför sprint
Grundarbetet, som görs innan utvecklingsarbetet tar vid, utgör hela skillnaden mellan en lyckad sprintstart och en mindre bra inledning. En prioriterad produktbehovslista med ett tiotal sprintredo krav är det bästa sättet att starta en sprint på och här kan en kravanalytiker, i sammarbete med produktägare och utvecklingsteam, genomföra storverk. Kravjobbet är ett fotarbete och ett iterativt hamsterhjul av möten med beställare, produktägare, utvecklare, arkitekter, testare o.s.v. En engagerad kravanalytiker som faciliterar produktbehovsprioriteringssessioner och detaljerar kraven är en verklig tillgång för utvecklingsteamet.

Sprintplanering
Återigen är det grundarbetet som gör hela skillnaden. Se till att (hela/delar av) teamet har fått tagit del av kraven i förväg så att de har haft möjlighet att tänka till. Produktägare och kravanalytiker ska vara pålästa så att de kan svara på frågor. Krav ska vara så pass väldefinierade att ev. frågeställningar bara rör detaljer. Låt hela teamet komma till tals, låt hela teamet bestämma sprintens omfattning. En väl genomförd sprintplanering ger en positiv känsla inför och en bra start på sprinten!

Färdigkriterier
Teamet kommer överens om vad som gäller för att en aktivitet ska vara färdig (incheckad, automattestad, färdigtestad, dokumenterad o.s.v.). Färdigkriterierna gäller utan undantag. En aktivitet är antingen oklar eller helt klar (och detta ska ha genomslag i burndown och leveranser). Det är viktigare att göra klart påbörjade aktiviteter än att starta nya. Ifall det finns oklara aktiviteter, fråga alltid vad du kan hjälpa till med för att få klart dessa, innan du tar på dig nya arbetsuppgifter.

Sprintpuls
Utvecklingsaktiviteter ska göras klart löpande under hela sprinten eftersom vi strävar efter att minimera risker. Varje gång vi sitter med utcheckad kod och filar på nya funktioner så finns det en risk att vi bygger fel funktioner, introducerar buggar, att vår kod divergerar mot övrig kodbas o.s.v.. Genom att hela tiden utveckla mindre delar minskar riskdeltat och vi undvikar ”merge”-problem i slutet av sprinten. Vi har också möjligheten att verifiera kvalité och leverans under hela sprinten, hela tiden. Sträva efter små väldefinierade användarberättelser, tillräcklig nedbrytning av utvecklingsaktiviteter som är testbara, täta incheckningar och kontinuerlig integration.

Aktivt deltagande
Aktivt deltagande av alla i teamet och ett gemensamt ansvar för leverans och kvalité. Alla ska känna delaktighet och hjälpa varandra utifrån kompetens och förmåga. Alla kan förstås inte göra allt, men alla kan hjälpa och stödja den som kan göra jobbet. Rekommenderar att även verksamheten deltar aktivt i utvecklingsarbetet under sprint. Ofta krävs det en eller annan krissituation innan teamet är helt sammansvetsat. En tuff deadline eller kritiska kvalitétsproblem är alltså inte enbart av ondo.

Tillåt teamet att fokusera
Kompetenta människor klarar sig alldeles utmärkt utan ledning och kan organisera sig själva. En ledares viktigaste uppgift är att låta teamet fokusera på sina uppgifter genom att skydda teamet från allt ovidkommande och att undanröja hinder. I ett team finns det utförare och möjliggörare. Som möjliggörare kanske man inte levererar konkreta arbetsresultat men genom att du låter andra fokusera på utförandet så är du mycket viktigt i din roll.

En introduktion till mjukvarutestning

Tänk ett tag på påståendet ovan. För mig innefattar detta den centrala meningen med mjukvarutestning. Till synes en enkel uppgift men så svår att utföra i praktiken. Testning handlar om kommunikation, information och att ställa frågor. Testning befinner sig i gränslandet mellan krav, utveckling och de verkliga behoven. Testning är den hubb där informationen från dessa tre världar möts och det ger testområdet en särställning inom systemutveckling.

…att jämföra med förväntat resultat

Testning handlar om att jämföra, men hur vet man vad man ska jämföra med och vad som är rätt beteende? Vilka informationskällor finns det att luta sig emot och hur värderar man dessa källor? Kravspecifikationen är förstås en given informationskälla och ett bra och ofta lättillgängligt sätt att ta del av förväntningarna på systemlösningen. Den ofta favoriserade kravspecifikationen är dock inte den enda informationskällan och den är sällan heltäckande. Krav kan vara felaktiga, krav kan ha ändrats, krav kan vara otydliga, krav kan ha glömts bort, krav kan ha kommit till. Som testare måste man ifrågasätta kravställningen och göra egna bedömningar utifrån all tillgänglig information. Förutom kravspecifikationen finns mycket information att hämta i den verklighet där systemlösningen används. Prata med folk, gör studiebesök eller låt användarna vara med i testerna. Var vetgirig och ställ frågor.

Ytterligare en källa till information är hur systemlösningen är utformad. Vilka tekniska val har gjorts? Vilka möjligheter och begräsningar medför de tekniska valen? Finns det områden som behöver testas extra noga? Vilka är de angränsande systement och hur ser integrationerna ut? De icke-funktionella kraven, såsom prestanda, säkerhet, användbarhet o.s.v. är områden som ofta är eftersatta i kravspecifikationen. Vad verkar rimligt, finns det luckor? Egen erfarenhet och intuition är ytterligare ett viktigt redskap. Hur borde systemlösningen fungera? Ger systemlösningen ett ostabilt intryck eller en skev känsla? Vad som utgör en bugg ligger i betraktarens öga. ”A bug is something that bugs me”, tycker jag är en bra utgångspunkt.

…för kreativa utmaningar…

Under själva testandet utgår man ofta från ett testfall, testscenario eller någon annan beskrivning för att fokusera testandet på den aktuella funktionen. I vissa fall kan det finnas skäl till att använda en väldigt detaljerad beskrivning och vid andra tillfällen kanske man helt enkelt improviserar fram tester. Ofta befinner man sig någonstans mittemellan, struktur för att testa effektivt men med möjlighet att släppa ledstången för kreativa infall. Även vid uttrycklig uppmaning att följa testprotokollet så finns det skäl att pröva infall vid sidan av. Testning är ett kreativt arbete och en detaljerad testspecifikation säger inte allt. Uppslag till nya tester kan ske under arbetets gång och buggar kan finnas i områden som ingen hittills förutsätt. Vilka erfarenheter har du själv av vad som kan gå fel? Svenska tecken, division med noll, olika webbläsare, köade transaktioner? Använd ditt eget omdöme och kunskap om systemlösningen både ur tekniskt perspektiv och i produktionssituationen. Vid en misstänkt bugg är det ofta till hjälp att zooma in runt det specifika området. Uteslut parametrar, börja testa från ett känt läge och förenkla testfallen. När man tvärtom vill undersöka förekomsten av buggar kan det hjälpa att zooma ut och köra långa komplicerade testsekvenser med utmanande uppgifter.

En annan dimension är skalan tekniknära respektive användarcentrerade tester. Vi har alla olika kunskap och fallenhet. En del är experter på verksamheten och hur systemlösningen fungerar i produktionssituationer medan andra har omfattande teknisk kunskap och nyttjar detta för riktigt utmanande tester. Båda aspekterna är nödvändiga men välj din personliga infallsvinkel utifrån var du befinner dig på skalan.

...att utsätta en systemlösning…

Det finns mängder av tester att utsätta systemlösningen för. Det kanske vanligaste är enkla funktionella tester i någon form av gränssnitt men det är synd att bara begränsa sig till detta. Populera databasen med inkonsekvent data, läs in korrupta filer, stäng ner batchkörningar vid oväntade tillfällen, ställ om systemklockor och ryck nätverkssladdar! Simulera samtidigt användande, omfattande last, intrång och systemkrascher. Testning är ett kreativt och en smula destruktivt arbete. Ifall du anar något oväntat, fortsätt att provocera systemet ytterligare.

Man behöver inte begränsa sig till testning vid enstaka faser eller leveranstillfällen, utan tester kan göras löpande under hela utvecklingsperioden. Sätt upp en egen utvecklingsmiljö för att kunna köra kodbyggena allteftersom de blir klara eller sitt tillsammans med en utvecklare för att få en inblick i hur systemlösningen växer fram. Ju tidigare som problem upptäcks, desto enklare är det i regel att åtgärda dessa. Ifall tester sker tillräckligt tidigt i samband med utveckling kan man tala om att tester hjälper till och driver utveckling, istället för att passivt mäta kvalité i efterhand. Då blir testning en integrerad del av utvecklingsarbetet och ger maximal nytta under systemlösningens hela framväxt.

Efter traditionell test - en framtidsspaning

I början av 00-talet använde jag uteslutande Windows med Internet Explorer, samt ibland en iMac, för att testa webbapplikationer. För att täcka in webbläsare och operativsystem, var det i allt väsentligt det som behövdes. Ett par år senare dök Firefox upp och följdes snart av Chrome. Livet som testare blev mer komplicerat. Idag måste man som testare, förutom flera olika webbläsare och operativ på vanliga datorer, ta hänsyn till ett väldigt antal olika smartphones och surfplattor (ett år gammal data från maj 2012 visar på närmare 4000 olika kombinationer av Android-OS på olika hårdvaror!). I framtiden kommer detta att eskalera ytterligare. Vi kommer att ha betydligt fler surfbara enheter, t.ex. medialösningar, smarta TV-apparater, spelkonsoler och underhållningssystem i bilar. Våra webbapplikationer vill vi ha tillgängliga och användbara överallt. Som traditionell manuell testare blir det förstås omöjligt att testa mot alla dessa olika plattformar. En tuff utmaning för alla testorganisationer därute!

Samtidigt under dessa år har de agila utvecklingsmetoderna vuxit fram, vunnit allt mer mark och blivit allmänt vedertagna. Gemensamt för de agila metoderna är att man ser förändring och omprioritering som en normal del av utvecklingsprocessen, istället för särfall att hantera i en separat changeprocess. Traditionella teststrategier, med långa startsträckor och dedikerade testfaser fungerar dåligt i kombination med agil utveckling. Allt fler integrationer, ökad komplexitet och kortare utvecklingscykler med täta releaser är andra trender som kommer att förändra testområdet i grunden. Det blir allt svårare, att till rimliga resurser och rimlig tidplan, genomföra bra tester med traditionella testmetoder. Återigen en tuff utmaning!

Inom testvärlden har det börjat viskas om att ”traditionell test är död” och många teknikdrivna företag sätter sin tilltro till testautomatisering. Vad betyder det för testarskrået? Har traditionell test ett ”bäst före”-datum? Vad kommer då istället?

Generella tester med syfte att kontrollera uppfyllnad av funktionella krav, det som de flesta testare ägnar sig åt idag, kommer i framtiden att göras med olika tillvägagångssätt av flera olika personer på olika nivåer. Kravställare börjar exemplifiera med acceptanskriterier som utvecklarna kan luta sig mot. Utvecklarna kommer att behöva testa mera själva och även lösa en stor del av testarbetet med testautomatisering. Manuella tester kommer att göras av produktägare, kravställare, verksamhetsrepresentanter och initierade användare i alfa- och betareleaser. Utökad övervakning och loggning kommer då att vara en viktig del av felrapporteringen och insamling av fel sker till stor del automatiskt. Vanliga funktionella tester och vanlig felrapportering kommer inte att göras av heltidstestare. De personer som kallar sig ”testare”, och testar på heltid, är i framtiden betydligt mer specialiserade än idag. De ägnar sig åt olika områden där det krävs speciell erfarenhet och är ett extra stöd till utvecklingsteamen i kvalitetsarbetet. Det kan röra sig om kvalificerad testning av prestanda, säkerhet, komplexa integrationer och andra icke-funktionella områden. Det kan även röra sig om kontextdrivna utforskande tester som ett komplement till de mer generella funktionella testerna.

Den traditionella testledaren kommer att ha allt mindre betydelse i framtiden. När det inte finns några egentliga testfaser eller testresurser, finns det egentligen ingenting som testledare har att administrera. Framtidens testledare är mer av en testarkitekt som möjliggör effektiv testning genom att se över hantering av testmiljöer, testdata, testverktyg och teststrategi. Testarkitekten är också en mentor som utbildar och coachar inom test på alla nivåer. Det kan röra sig om att kvalitetssäkra krav, utvärdera risker, hjälpa utvecklare med TDD och continuous integration, stödja verksamhetsrepresentanter vid funktionella tester och kartlägga behov av testspecialister. Traditionell testledning kommer främst ha ett syfte vid omfattande systemintegrationstester med många inblandade system. I sådana sammanhang kommer nämligen de administrativa egenskaperna helt till sin rätt i arbetet att koordinera testdata, releaser och testfall.

Dreyfus - vad datorer inte kan

I ett samtal med min mentor kom vi in på ämnet lärande och hur man arbetar som coach utifrån den erfarenhetsnivå som adepten har. Min mentor tog upp Dreyfus ”What computers can’t do” som en bra modell att utgå ifrån. Dreyfus skrev sitt arbete början av 70-talet i en tid då AI var på frammarsch och många trodde att datorer snart skulle kunna ersätta det mänskliga medvetandet. Idag vet vi att vår hjärna är betydligt mer komplex än att kunna simuleras med datorkraft (trots att vi nu har tillgång till datorkraft som man på 70-talet bara kunde drömma). Det mänskliga lärandet är helt enkelt av en helt annan art än vad vi med datorer kan konstruera och efterlikna.

När jag läste in mig på Dreyfus arbete kunde jag inte undgå att dra paralleller till test. De tidiga erfarenhetsnivåerna, där man gärna följer regler, kan liknas vid att upprepa fördefinierade testfall. Senare nivåer kan liknas vid riskbaserad eller utforskande testning, där man instinktivt känner vad som är rätt och hur systemet borde agera. Eftersom datorer inte kan utrustas med intellekt, instinkt och systemtänkande så kan man ej heller med automatiserad testning hitta lika många fel som en skicklig manuell testare, även om datorer spöar en oerfaren testare blott genom mängden testfall som utförs med högre hastighet.

Jag vill tacka Lotta på Arbetsförmedlingen IT för beskrivningen av Dreyfus arbete nedan (som jag stulit och fritt översatt från hennes bok)…

Inom epistemologin (d.v.s. den del inom filosofin som handlar om mänskligt vetande) har boken ”What computers can’t do”, av Hubert L. Dreyfus 1972, spelat en stor roll. Dreyfus presenterar fem kunskapsnivåer som vanligtvis passeras när vi lär oss nya saker. Dessa fem nivåer är novis, nybörjare, kompetent, erfaren och expert.

Novisen känner bara till enkla förhållanden eller fakta och behöver tydliga regler för att avgöra vilka åtgärder och steg som bör tas. Dreyfus ger exemplet om någon som övningskör och avgör fordonets hastighet genom att titta på hastighetsmätaren. Övningsföraren använder sig sen av regler och kanske bedömer när det är dags att växla genom att hastighetsmätaren passerar 10 km/h. Att bara följa enkla regler kan ha sina nackdelar. Övningsföraren kommer förmodligen att få motorstopp om hen växlar för snabbt i ett motlut eller med tung last.

Förutom enkla fakta börjar nybörjaren att ha bättre förståelse om kontexten. Efter att ha upplevt tillräckligt många exempel så börjar nybörjaren att förstå sammanhang. Dreyfus liknar detta med bilföraren som lyssnar på motorljudet för att avgöra när det är dags att växla. Nybörjaren följer fortfarande givna regler men lär sig genom återkommande händelser och ökar sin erfarenhet. Eftersom både novisen och nybörjaren bara blint följer regler, känner de liten egen skuld vid ett misslyckande och upplever ofta att det är reglerna som är felaktigt utformade.

En kompetent person tar fram en plan och väljer en utgångspunkt för att kunna hantera den oftast överväldigande informationen som hen har lärt sig att identifiera. Planen, som härstammar ur egen erfarenhet eller instruktioner, hjälper den kompetente att skilja mellan viktiga och mindre viktiga aspekter och underlättar beslutsfattandet. Dreyfus menar att vid den här nivån följer bilföraren inte enbart regler. Bilföraren har ett mål i sikte och ifall den kompetente råkar i en nödsituation kanske hen bara fokuserar på att nå fram utan att bry sig om passagerarnas komfort eller trafiklagen. Dreyfus poängterar att det i de allra flesta fall är omöjligt att enbart förlita sig på regler. Inom varje område kan det uppstå flera olika situationer och det är omöjligt att täcka in dem alla. Den kompetente personen inser det och måste därför själv sin utgångspunkt. Man kan inte veta vad som är det rätta valet i förväg och det kan uppfattas som skrämmande. Den kompetende känner ett stort eget ansvar eftersom resultatet verkligen beror på deras val. Det finns en emotionell investering i varje val och människor blir naturligtvis skrämda, upplyfta, besvikna eller håglösa beroende på resultatet.

En erfaren person kan ofta känna sig uppfylld av sin egen skicklighet, d.v.s. befinner sig ”in the flow”. Hen ser vad som borde göras men behöver kanske lite tid för att bestämma sig hur det ska genomföras. Minnen av liknande erfarenheter i det förflutna leder till planer baserat på vad som har fungerat förut.

Experten ser inte enbart vad som borde göras utan vet intuitivt hur det ska genomföras. Experten har en utvecklad och genomarbetad förståelse och kan omedelbart genomföra vad som krävs. I normalfallet är det ofta tillräckligt och expertens arbete leder därför allra oftast till ett gott resultat.

Pratar på NFI Testforum

Jag har blivit inbjuden att prata på NFI Testforum den 16 april. Ni som deltar kommer att få lyssna på min presentation "från backlog till produktion på två veckor". Presentationen handlar om agil testning i ett Scrumteam med integrationstester och produktionssättning inom sprinten.

>>Väl mött!

Roller - ett arv från medeltidens skråväsende och den romerska armén

Den gamla romerska armén var bland de första att använda sig av olika roller som noga definierade ansvar och befogenheter . Den romerska armén hade en noggrant fastställd befälsordning som användes för att kommunicera och verkställa order samt att få alla legionärer att inrätta sig efter givna regler och påbud. Brott mot befälsordningen straffades mycket hårt t.ex. med stening eller genom att stoppas i en säck med ormar och kastas i en sjö. Den romerska armén var känd för sin effektivitet och disciplin. Systemet har därför kopierats av alla försvarsmakter sedan dess.

Genom historien har det också funnits gott om roller utanför de millitära sammanhangen. I medeltidens ståndssamhälle inrättades folket efter social status.  Det var sällan som människor umgicks över ståndsgränserna och att gifta sig utanför sitt stånd var inte ens att tänka på. Poängen var givetvis att kontrollera den stora massan människor, t.ex. torpare, statare, fattighjon och landstrykare, som var utan ståndstillhörighet och därmed inte hade något att göra med samhällets beskaffande. Skråväsendet från samma tid, där man för första gången delar in människor efter yrke, är en annan typ av rollkonstruktion som skapades för att minska rörligheten på arbetsmarknaden. Ifall alla fick bli skomakare skulle skopriset rasa och lönerna gå ner.

Det moderna rolltänkandet har sitt ursprung i industrialismens fabriker. Industrialismens grundtes är att genomtänkta processer och extrem specialisering ger möjlighet till massproduktion och jämn kvalité. Tillverkningsprocessen delas in i små steg och arbetsuppgifter tilldelas enligt olika roller. De hierarkiska konstruktionerna finns kvar för att styra de många arbetarna. De industriella metoderna fungerar utmärkt ifall processens alla steg är kända, kan planeras i förväg och kommer att se exakt likadana ut under överblickbar tid.

Den yrkesmässiga rollen är ett sentida arv från det rigida medeltida skråväsendet. Personer definierar sig t.ex. som arkitekter, testare eller utvecklare trots att gränsen mellan olika utvecklingsaktiviteter är synnerligen flytande. Inom företagsvärlden används fortfarande roller för att definiera ansvar och befogenheter.  Jag känner till en organisation vars systemutvecklingsmodell definierar nästan trettio roller, hur har man tänkt då? De flesta arbetsplatser skiljer sig lyckligtvis ifrån livet i den romerska armén och blind lydnad verkar snarare hämmande på ett företags utveckling. De flesta företag skiljer sig även ifrån de gamla bruksindustrierna. Din projektledare har troligen en ganska luddig föreställning om dina dagliga arbetsuppgifter och har inte en möjlighet att ge tydliga och genomtänkta direktiv i en föränderlig omgivning. Ifall man reflekterar över att roller historiskt används för att uppnå blind lydnad i krig, upprätthålla hierarkier och stävja dynamik på arbetsmarknaden, varför använder vi begreppet fortfarande idag?