Fyra saker det kämpats med för länge inom test, och hur långt utvecklingen faktiskt har kommit

Det egentliga problemet

Testautomation hamnar i förvaltningsläge första gången den exekveras, men oftast tittar man ändå bara på nuläge när automation initieras. Bra testautomatisering innebär för en del testfall att man testar så små delar av systemet som möjligt, men för andra testfall att man testar så mycket system som möjligt så att man ser att hela systemet verkligen fungerar.

Det kommer att dröja ännu något decennium innan maskiner kan mäta sig med människor i kreativitet, serendipitet (förmågan att uppmärksamma sådant man egentligen inte letade efter) och slutledningsförmåga.

De allra flesta tester utförs för att säkra förtroendet för att systemet, givet införda förändringar, ännu kommer att leverera nytta. Om förtroendet för testautomationens förmåga är låg kommer därför dess värde att vara lågt. Testautomationen bygger ofta på samma tolkningar av förväntningarna på systemet som själva utvecklingen, och den tenderar därför att missa de stora felen, men behöva pysslas om vid små insignifikanta ändringar.

Det är mycket mer än bara applikationskoden som kan göra att systemet inte fungerar

Vad vi egentligen borde koncentrera oss på

Verktygsstödda tester samt klok automation av masstester. Mycket av de förberedelser, dataanalyser och jämförelser som testare sitter med manuellt idag kan finna gott stöd i verktyg.

Det egentliga problemet

Vad som är viktigt att beskriva skiljer sig åt från situation till situation. Inget verktygsstöd idag kan heller visa på det man vet om framtida händelser. Om man t.ex. vet att det kommer en leverans av ett stort sidosystem om en månad, och man sover dåligt för det, så syns inte det i graferna. Mätdata kommer därför alltid att behöva analyseras och diskuteras, hur tydliga graferna än kan verka vid första anblicken. I de mest välmätta projekten jag deltagit i har det funnits ett sammanfattande mätetal för "testledarens förtroende för att klara deadline", "testledarens förtroende för utvecklingen" och för "testledarens förtroende för QA-bemanningen" tillsammans med ett kort fritextfält för två förklarande meningar. Det har räckt bra. Alla andra grafer används då endast för att besvara frågor kring denna magkänsla.

Dessutom handlar testning ytterst om att säkra alla intressenternas nöjdhet, för det är först då som man kan tala om succé och kvalitet. Det är ledtider på att få in mätetal för nöjdhetsgrad, så de mätningarna släpar lika mycket efter som t.ex. DDP.

Mmmmm.... Pajdiagram är alltid lockande...

Vad vi egentligen borde koncentrera oss på

Vi borde koncentrera oss på att få styrgruppernas och ledningsgruppernas förtroende så att det är naturligt för dem att söka vårt uttalande om nuvarande magkänsla, eftersom de litar på den. Ett led i detta är naturligtvis att nogsamt arbeta fram bra mätetal tillsammans med de som ska ta emot informationen - och rakt ut fråga dem vad de vill ha presenterat och på vilket format.

Ett undantag är naturligtvis då regulatoriska krav eller annan compliance tvingar oss till vissa mätetal, men då är det naturligt att använda dessa som komplement.

Det egentliga problemet

Data är komplext för att relationen mellan information är komplex. Det finns en hel flora av yrken som bara jobbar med att strukturera data (begreppsmodellering, DBA:er osv)

Många av de buggar vi finner beror på att det finns oomhändertagna datavariationer som inte koden är förberedd för. Ofta beror detta på att man inte visste om att den variationen/kombinationen/formatet alls kunde uppstå. För att nå dessa specialfall krävs det produktionsdata, men migrering av data sker ofta sent under utvecklingen. Dessutom är produktionsdata så volymkrävande att det kan vara svårt att hitta buggar bara för att man liksom letar efter en nål i en höstack. Stora datavolymer är också svåra att underhålla, de är alltid inaktuella för att det finns ledtider inblandade och de är svåra att hantera i automationssammanhang eftersom återställningsrutiner blir komplexa och svårhanterade.

Vad vi egentligen borde koncentrera oss på

De-coupling av system. Detta möjliggör det bästa av alla världar, i vart fall som vi känner till idag. Om vi kan testa system och komponenter fristående slipper vi ledtiden för att vänta in något gyllene läge då data måste vara i synk, och vi kan testa mot systemets externa gränsytor under enhets- och systemtesterna (testerna för att utvecklingsteamet ska få behålla sin stolthet och heder), vilket kan öka tryggheten tidigt och minimera hur ofta vi behöver testa mot stora sammanhängande datarymder. Vi kan också lättare testa mot konstruerat och genererat data, samt faktiskt genomföra systemintegrationstester på ett bättre sätt.

Det egentliga problemet

Det är svårt att konkretisera vad test tillför för värde. Det är dessutom närmast omöjligt att beskriva hur ett bra testarbete genomförs eftersom testyrket måste vara följsamt omgivningen för att ske effektivt. Denna schizofrena inställning till vårt eget arbete gör det svårt att beskriva vad vi gör vilket gör att det verkar flummigt.

Vad vi egentligen borde koncentrera oss på

Medvetet fila bort de tråkiga delarna av testarbetet, belysa de kreativa och kunskaps-/erfarenhetsbaserade bitarna av arbetet. Lära oss av utvecklare, arkitekter och projektledare så att vi behärskar deras ord och uttryck så att vi smidigt kan kommunicera med dem så att de känner att vi tillför värde och förstår produkt, verksamhet och process.