Tio tusen städer — Testobjektifiering och dokumentation

Eller gör det?

Jag har ofta sett QA-team ta sig an den heroiska uppgiften att fullständigt dokumentera sina tester på ett samvetsgrant och ihärdigt sätt. För en version. Och sedan tenderar dokumentationen att falla i glömska. Den samlar digitalt damm någonstans i ett nätverk. Och det beror inte på att QA-teamet har slutat tro på dess betydelse. De är helt enkelt utmattade av den insats som krävs för att uppdatera den inför nästa större version. 

Det beror på att QA-teamet i sin iver skrev otroligt detaljerade testbeskrivningar och bröt ner saker till en maniskt mikroskopisk nivå av hyperspecificitet. De skapade separat testdokumentation för varje aspekt eller egenskap hos en enda funktion eller användarinteraktion. De genererade dussintals individuella testbeskrivningar och uppgifter för något som i grunden är en enda testuppgift. Det är som personen framför dig i kön i mataffären som insisterar på att betala för matvaror för 80 dollar med småmynt.

Resultatet av denna atomiserande nit blir att hundratals, ibland tusentals, testbeskrivningar skapas för den aktuella versionen. QA har omedvetet slutat med att skriva en Dickensroman. En berättelse om tiotusen städer. Har du faktiskt läst någon av dem? Inte jag heller.

Slutsatsen är att ingen har tid eller tålamod att uppdatera dessa tusentals individuella testbeskrivningar. Prioriteten kommer alltid att vara att testa nästa iteration av programvaran i stället, eftersom det i slutändan genererar intäkter medan uppdatering av testdokumentation inte gör det. 

Men också för att applikationer för testdokumentation inte gör det särskilt enkelt att massuppdatera poster i testdokumentationen. Att göra globala ändringar i testklasser kan vara mödosamt och ointuitivt i de flesta applikationer (detta gäller även många applikationer för defektspårning — även i dag). Det ökar tidsåtgången och den mentala belastningen som arbetet med detta medför.

Som ett resultat överges all denna noggranna testdokumentation. Och all tid som lades på att skapa den är i slutändan bortkastad. Eftersom den inte kan återanvändas. Den är en engångsframgång. Den är programvarutestningens ”Jag smälter med dig”. Ändå är testdokumentation en absolut nödvändighet för ett repeterbart, systematiskt testarbete. Där har vi moment 22.

Det finns en väg ut ur detta dilemma. Och även om det smärtar mig att erkänna det bör vi vända oss till ingenjörskonsten för att hitta lösningen. Eller åtminstone inspirationen till den. Ingenjörer stod inför ett liknande problem under de tidiga åren av kommersiell mjukvaruutveckling. På grund av begränsningarna hos den tidens programmeringsspråk var de tvungna att skriva om kod för samma grundläggande attribut, åtgärder och skydd för varje funktion. Om och om igen. Minneshantering och skräpsamling var ett bra (och farligt) exempel på detta problem.

Som ett resultat genererade ingenjörer enorma mängder överflödig kod och slösade bort enorma mängder tid (inte för att ingenjörer nödvändigtvis har något emot det senare. Ebay finns fortfarande av en anledning). Sedan kom någon klipsk person på objektorienterad programmering, där kodobjekt kunde skapas och ärva standardattribut genom sin natur. Samma kod behövde inte skrivas (eller klippas ut och klistras in) varje gång. Det innebar att kvaliteten inte längre var beroende av någon enskild ingenjörs minne eller skrivförmåga. Något QA är evigt tacksamt för.

Detta är en mycket användbar vision för QA när man försöker hantera testdokumentationens återvändsgränd. Begreppet objektorientering som det används inom ingenjörskonsten kan inte tillämpas direkt på det här problemet, men som metafor har det mycket att erbjuda. Klipskhet anpassar sig per definition lätt till nya situationer.

Många gånger under min karriär har jag ställts inför problemet att skapa testdokumentation som är omfattande men koncis, användbar i stunden men också lätt att återanvända för framtida versioner. Lösningen jag till slut fastnade för är att tillämpa idén om ett ”objekt” på själva testdokumentationen. 

Här talar jag om mycket mer än en mall för testdokumentation. Sådana mallar är naturligtvis mycket användbara som standardiseringsverktyg, men de är irrelevanta för det aktuella problemet. Jag utvecklade idén att tester kunde dokumenteras på ett sätt som inkluderade alla deras olika lägen, vändpunkter, arbetsflöden och särskilda villkor i ett enda dokument. När denna lampa tändes i mitt dunkla huvud verkade svaret plötsligt mycket enkelt. Och mycket genomförbart.

Låt oss gå in på det.

Att ta det röda pillret

Svaret är att se varje enskilt test, och därmed även dess dokumentationsartefakt, inte som ett påstående eller en beskrivning av testning mot en enda datapunkt eller ett isolerat villkor. Utan som en beskrivning av hela matrisen (ser ni vad jag gjorde?) av villkor där funktionen eller förmågan behöver valideras. 

Detta innebär ett holistiskt förhållningssätt till definitionen av individuella tester. En sammanhängande, enskild testuppgift kan inte på ett meningsfullt sätt delas upp i dussintals oberoende ”tester” utan att man paradoxalt nog suddar ut specificiteten genom att testa funktionen som helhet. Det är en situation där man inte ser skogen för alla träd.

Här är det användbart att granska begreppet testkontext. För att effektivt kunna implementera idén om ett testobjekt måste du först kunna skilja funktionalitetens oföränderliga kärna från dess sekundära användnings- och driftkontexter. Detta är en fråga som den atomära stilen för testdokumentation undviker, och därför lär sig testare aldrig hur man genomför denna analys systematiskt och medvetet. Ännu en nackdel med den atomära modellen.

Enkelt uttryckt är testkontexter för en funktion eller ett system den uppsättning villkor, miljöer, arbetsflöden eller tillstånd som kan variera oberoende av varandra inom funktionens egna gränser. Operativsystem och versioner av operativsystem är ett tydligt exempel på detta. Främmande språk är ett annat. Systemtillstånd är ytterligare ett (det vill säga, när det gäller en webbserver, om minnescache är aktiverad eller inaktiverad). När du väl har förstått denna åtskillnad kan du enkelt komma på många andra som är relevanta för de typer av produkter du testar.

När du har slutfört denna analys (som ändå bör vara grunden för all professionell testplanering) har du möjlighet att skapa kompakta former av testdokumentation som införlivar denna åtskillnad. I det system jag beskriver kommer ett enskilt testdokumentationsartefakt att bestå av:

1. En beskrivning av den centrala funktion eller kapacitet som testas.
2. En lista över alla kontexter där kärnfunktionaliteten måste valideras.
3. Allt annat som du normalt ändå skulle ha inkluderat (förutsättningar för att testet ska vara giltigt, systemresurser och behörigheter som krävs för att köra testet, en länk till relevanta produktkrav och så vidare). Inget av detta ersätts av det jag föreslår.

Nu kanske du tänker: ”Oj, det kan vara många kontexter!” Ja, absolut. Men se det så här. Att göra på det här sättet skapar inte mer arbete för dig. Faktum är att det minskar det. Det blir enklare att utarbeta heltäckande testplaner med vår kuraterade lista över verktyg för programvarutestning och dokumentation. Den här metoden kommer nämligen att *kraftigt* minska antalet individuella tester som du behöver lägga tid på att skapa och som du kommer att behöva underhålla (eller låta bli att underhålla) i framtiden. I den atomära modellen skulle du däremot behöva skapa ett separat testdokumentationsartefakt för var och en av dem. Det leder till det moment 22 som beskrevs i början av den här artikeln.

Den här metoden för testdokumentation får vissa konsekvenser för processen som till en början kan verka besvärliga. Eller till och med oroande. Och inte bara för QA, utan även för andra projektintressenter. Men om alla berörda tar sig tid att förstå dem kommer de att se att det egentligen handlar om förbättringar. För alla.

Den främsta av dessa är att när man samlar matrisen av funktionskontexter i själva huvudtestet innebär det logiskt sett att om det enskilda testet misslyckas i någon av dessa kontexter, har hela testet misslyckats. Även om det bara gäller en enda. Jag kan föreställa mig att detta skapar panik inom utvecklingsteamen. Det kan verka som om man riggar spelet mot dem och höjer ribban till en omöjlig nivå för att ett test ska räknas som ”godkänt”. Men den rädslan är lätt att hantera. Påpeka bara två saker för dem och en tredje för dig själv:

1. Den här metoden kommer faktiskt att minska antalet buggar som genereras i deras arbete genom testning. Med den atomära metoden skulle ett fel i någon av dessa kontexter ha lett till en separat bugg. Det skulle därmed öka det totala antalet buggar för den enskilda funktionen. Det borde få ingenjörerna att le. Och projektledarna också.
2. För det andra ger testning med denna metodik automatiskt kontext för den funktionella störningens faktiska omfattning. För vilken är den första frågan som ingenjören som fått i uppgift att åtgärda buggen alltid kommer att ställa? ”Eh, händer det överallt? Eller bara i kontext X?” Och i stället för att behöva skynda tillbaka till skrivbordet och köra om testet i kontext X (för kanske glömde du att göra det i den ursprungliga testningen?) har du redan svaret, och ingenjören berövas en ursäkt för att slippa arbeta med det (det QA ger genom färre buggar tar det senare tillbaka).
3. För det tredje säkerställer kontextanalysen för testdokumentationen att du faktiskt tänkte igenom alla relevanta kontexter när du dokumenterade testet från början. Det innebär att du löper mindre risk att hamna i de där panikartade ögonblicken – tre dagar före eller, ännu värre, efter lanseringen – när du inser att du glömde att testa i några mycket viktiga kontexter. Ett QA-arbete som bygger på panik är inte särskilt effektivt. Inte heller är det någon särskilt lycklig psykologisk upplevelse.

I maskinen

Denna objektinspirerade metod för testdokumentation kommer drastiskt att minska mängden dokumentationsartefakter som du måste ta fram och därmed göra det mer sannolikt att du faktiskt kommer att kunna och vilja uppdatera dem löpande inför framtida lanseringar.

Det enda problemet är att få applikationer för testdokumentation är konfigurerade för att dokumentera tester på det här sättet från början. De utgår från den atomära dokumentationsmodellen, eftersom den tyvärr är standard, och saknar därför inbyggd funktionalitet för att enkelt hantera den objektmodell som jag har beskrivit här. 

Det är därför jag ofta har valt mycket mindre avancerade programlösningar – som Excel – som faktiskt, för detta ändamål, är betydligt mer flexibla och lättare att anpassa, eftersom de är allmänna verktyg. Nackdelen med den strategin är att det blir omständligt att integrera dem med Jira med flera. Men kanske är integration överskattad.

Oavsett vilket kvarstår faktumet att många program för testning och dokumentation av defekter gör det oförklarligt svårt att utföra batchuppdateringar av enskilda poster. Oavsett vilka protokoll du väljer att använda när du skapar dem. Men det gäller oavsett hur du väljer att skriva din testdokumentation. Ett problem i taget, gott folk.

Jag ber om ursäkt på förhand (eller i ditt fall, i efterhand) för att jag inte ger dig en mall för testobjekt. Min erfarenhet är att det vanligtvis är en dålig idé att tillhandahålla mallar eftersom människor helt enkelt börjar använda din mall. Tillgången till färdiga, generiska mallar tenderar att föregripa och kortsluta själva teamets kreativitet när det gäller att utforma en mall som överensstämmer med deras faktiska behov, processer och verktyg i praktiken. Så ta det inte personligt.

Jag är alltid öppen för dina frågor och förslag. Lägg bara upp dem eller skicka dem till mig på LinkedIn.

Och som alltid, lycka till.