Ledarskap inom testning: Dokumentation

Värdet av dokumentation

I strukturerade projekt betraktas dokument vanligtvis som leverabler i sin egen rätt. I agila eller kontinuerliga arbetssätt kan dokumentation produceras som en biprodukt med större eller mindre värde.

Att skriva dokument kan vara den huvudsakliga aktiviteten för professionella tekniska skribenter, men för de flesta yrkesverksamma är det ett besvär – oavsett hur användbart det kan vara. Även om dokumentskrivande kan vara tråkigt för vissa är det verkliga problemet med dokumentation att den i många sammanhang helt enkelt är slöseri med tid. Den har litet värde, är inaktuell, felaktig – eller allt detta på en gång.

Alla testansvariga har skrivit teststrategier som ingen läste eller ställde sig bakom. Testare skriver mängder av testplaner, testskript och rapporter, och det enda innehåll som är värdefullt för intressenterna är de ensidiga sammanfattningarna i början eller slutet.

Detta beror på vanliga problem med dokumentation som vi stöter på i både stora och små projekt. För varje dokument vi skriver finns det flera frågor som vi behöver besvara:

• Vilken typ av dokument? En policy eller strategi, ett arbetssätt eller en plan, en utformning eller implementering, eller ett resultat och en tolkning?
• Vad är syftet med dokumentet?
• Vilket innehåll krävs för att uppfylla syftet?
• Vilka kunskapskällor krävs för att skapa innehållet?
• Om dokumentet måste förändras över tid, hur ska det underhållas?
• Vilken detaljnivå krävs?

Get Free Access

Get regular tech leadership wisdom for delivering better software and systems.

Create Free Account

Have an account? Log In

Nackdelarna med mallar och kopiera/klistra in

Om ditt projekt fastställer att ett visst dokument krävs, till exempel en systemtestplan eller ett riskregister, är det frestande att hitta en färdig mall för detta (och många andra dokumenttyper) på internet.

Vissa mallar kan hävda att de följer någon standard eller konvention och att de har laddats ner och använts tusentals gånger. Ibland kan en mall verka passa exakt för ditt ändamål. Men som vi ska se kan den ställa till problem för dig även om innehållsförteckningen ser heltäckande ut.

Det kan också vara så att du eller andra på företaget har tagit fram ett liknande dokument för tidigare projekt. Du kan frestas att kopiera och byta namn på dokumentet, ändra hänvisningarna till det gamla projektet och redigera innehållet så att det passar.

Varning: Enligt min erfarenhet som oberoende granskare är detta mycket vanligt och ofta ett verkligt problem. 

För det första är det vanligtvis uppenbart att en kopiering/redigering har gjorts. Språket som används i texten verkar ofta sakna koppling till projektet och det finns luckor och överflödig text överallt. Varför är det så?

Att använda en färdig mall eller ett befintligt dokument som källa medför flera risker:

• Det ser heltäckande ut, men kan innehålla ämnen som är olämpliga och utesluta andra som är nödvändiga.
• Det innehåller rubriker för ett dokument, men absolut ingen vägledning om vilket innehåll som är lämpligt för varje rubrik.
• Det kan innehålla text som ser återanvändbar ut och som har kopierats oförändrad från ett tidigare, orelaterat projekt, men den texten kan ge ett felaktigt intryck eller vara felaktig eller ofullständig.

Att använda mallar för att få rubriker och en grundläggande formateringslayout kan vara användbart, men det största problemet med mallar är detta:

Frestelsen med mallar är att lita för mycket på dem och sedan skriva utfyllnad för de olika avsnitten. Du kanske trots allt tänker att dokumentet bara uppfyller en ‘kryssruta’ och att ingen ändå kommer att läsa det. Risken med mallar är att du slutar tänka och skriver ett dokument som har begränsat värde.

Typer av testdokumentation

I det här avsnittet tittar vi på de olika formerna av testdokumentation och diskuterar vissa överväganden i strukturerade eller agila/kontinuerliga projekt jämfört med traditionell vattenfallsutveckling. 

Den centrala uppsättningen testdokument brukar delas in i följande kategorier:

• Policy och strategi (ibland kallad övergripande testplan)
• Testdefinition (även kallad specifikation eller testplaner, förvirrande nog)
• Testutformning
• Testfall
• Testprocedurer eller skript
• Testgenomförande
• Tidsplan
• Logg
• Testrapport

Ovanstående utbud av dokumenttyper täcker definitionen av testprocessen, centrala aktiviteter för definition och genomförande samt rapportering. 

Det finns flera andra testrelaterade dokument som i mer byråkratiska miljöer skulle omfatta definitioner av testmiljöer och hanteringsprocesser, acceptansprocedurer, processer för incidenthantering och så vidare (vi kommer att behandla incidenthantering i en framtida artikel).

En annan uppenbar utelämning ovan är en övergripande plan eller tidsplan för testaktiviteter. En tidsplan är egentligen inte ett testdokument, utan en delmängd av en övergripande projektplan för ett strukturerat projekt (vi kommer också att behandla planering av tidsplaner i en framtida artikel, så håll utkik!).

Policy, strategi och övergripande testplan

Testkörning (schema, logg)

Syfte	Att ange i vilken ordning testerna ska köras Att registrera testernas status – körda/inte körda och status Att tillhandahålla resultaten från testkörningen för rapportering
Innehåll	Testidentifierare, testare, datum/tid för körning, status För tester som verkar uppvisa avvikande beteende (valfritt): Detaljer om testet så som det kördes där detaljerna skiljer sig från skriptet Faktiska resultat jämfört med förväntade resultat Andra observationer, tolkning Teststatus (defekt, avvikelse i konfiguration eller miljö etc.) Observations- eller defektrapportens id (i förekommande fall)
Källor	Inventering av testfall/testprocedurer, testare
Underhåll	Schemat skulle ändras i takt med testningens omfattning och procedurer som ändras, tas bort eller läggs till i planen. Tester kommer sannolikt att köras flera gånger, antingen som omtester eller regressionstester. Loggen bör innehålla en fullständig historik för alla tester som ingår i omfattningen.
Överväganden för agilt/kontinuerligt arbete Om agila/kontinuerliga projekt inte förbinder sig till dokument för testdefinition kompenserar de till viss del genom att uppmuntra testare att föra bättre loggar över testkörningen. När testning utförs i sessioner mot testcharter förväntas testaren föra bra anteckningar om de tester som körs. Det finns få särskilda verktyg för testloggning som är mer än anteckningsböcker, så många testare använder enkla textredigerare, anteckningsverktyg eller anteckningsböcker i pappersform. Loggar används vanligtvis för att registrera all betydande aktivitet och alla observationer under sessionerna medan de genomförs. En typisk logg för utforskande testning skulle innehålla aspekter som: Strukturen hos de utforskade funktionerna (en karta över området) Observationer och frågor relaterade till de funktioner som utforskades under sessionen Modeller, listor och tabeller över testobjekt och testidéer Körda tester, dokumenterade med tillräckliga detaljer för att kunna återupprepa dem Avvikelser som hittats – fel, tveksamt beteende, långsamma svar, bristande användarupplevelse och så vidare Tid som lagts på utforskning, testkonfiguration, testning, undersökning, felrapportering, omtestning, regressionstestning och icke-produktiv tid Datum/tid för registreringen När testare loggar sin sessionsaktivitet i anteckningsverktyg eller andra verktyg använder de någon form av markering eller annat domänspecifikt språk för att strukturera sina anteckningar. Dessa kan analyseras av enkla interna verktyg för att ge sammanfattningar av aktiviteten som kan användas i testrapporten. Tester som körs av verktyg (oavsett om de är proprietära eller har öppen källkod) loggas automatiskt. Vanligtvis kan dessa loggar sökas i via verktyget eller användarskrivna procedurer.

Testrapport

Syfte	Att kommunicera resultatet av en testfas, utvalda tester eller en testsession Kan även gälla tekniska krav eller icke-funktionella testaktiviteter, och i så fall skulle innehållet anpassas efter testmålet Att delvis informera intressenter så att de kan fatta beslut om godkännande eller lansering av ett system eller delsystem.
Innehåll	Testets start- och sluttider samt varaktighet Testmiljö Programvaru- och systemversion(er) som testas Testningens mål och omfattning (från teststrategin, testdefinitionen) Berättande sammanfattning av resultaten Funktioner som bedöms fungera enligt kraven Risker som bedöms ha hanterats Kvarstående tester av betydelse (misslyckade eller blockerade) Funktioner som testats delvis eller inte alls Risker som hanterats delvis eller inte alls. Detaljer om testresultat med utdata från testloggar osv. Status för kringgående lösningar för kvarstående avvikelser Testanalyser Testernas framsteg och status över tid Incidentstatistik
Källor	Teststrategi, testdefinitioner, testlogg, incidentrapporter En stor del av innehållet i en testrapport kommer från de verktyg som används för att registrera testdefinition(er), testloggen samt incident- eller defektloggen.
Underhåll	Detta är en ögonblicksbild av en testkörningsfas och underhålls inte.
Överväganden för agilt/kontinuerligt arbete Syftet med en testrapport i ett agilt projekt kan omfatta en enskild iteration eller sprint, testning inför en lansering eller en testfas på högre nivå, såsom integration eller övergripande systemgodkännande. Oavsett vilket är syftet oförändrat. En stor del av innehållet i en testrapport kommer från verktyg eller anteckningar från testare. Den berättande sammanfattningen av resultaten skrivs av en testledare eller testaren för en mindre omfattande testfas. Som vanligt är rapporten sannolikt mindre formell, och det skulle förmodligen finnas mindre rådata som kan ligga till grund för avancerade analyser. Under iterationen eller iterationerna kan framstegen genom iterationen, i form av funktioner eller berättelser som levererats, testats och godkänts av användarna, mycket väl registreras i ett verktyg eller på en offentlig KanBan-tavla. På så sätt hålls intressenterna informerade om framstegen under hela iterationen, och behovet av en formell rapport i slutet av en testperiod minskar. Synlighet kring framstegen är en viktig fråga för agila team. Med regelbundna, kanske dagliga, ståmöten kring exempelvis en Scrum-tavla delar teammedlemmarna sin förståelse av framstegen, ställer frågor till varandra och kommer hela tiden överens om en ståndpunkt (och nästa steg). På så sätt kanske en formell testrapport aldrig behövs, eftersom teamet alltid är informerat och uppdaterat. Om testarna för skriftliga anteckningar över sina sessionsaktiviteter finns det inga analyserbara data tillgängliga för att presentera automatiserade rapporter, så sessions- och framstegsrapporteringen kan behöva presenteras på ett offentligt och visuellt sätt. Detta kräver hög disciplin och god kommunikationsförmåga hos testarna. Testledaren eller testansvarig måste då tillhandahålla en motsvarande informativ rapport till intressenterna baserad på muntliga rapporter.

More Articles

• Så använder du DevOps-mätvärden för att skala upp ditt företag

Några råd

Dokumentation i projekt är ett känsligt ämne för testare såväl som för andra projektmedlemmar.

Här är några saker att tänka på när du utformar din dokumentation.

1. Dokumentationen måste ha ett väldefinierat syfte och en tydligt definierad målgrupp. Om målgruppen inte behöver dokumentationen kommer de inte att läsa den. Om den inte knyter an till deras egna mål kommer de inte att ställa sig bakom den.
2. Det är vanligtvis bättre att dokumentera en aktivitet före eller medan du utför den. TDD dokumenterar exempelvis tester innan koden skrivs. Loggar från testsessioner bör dokumenteras under sessionen och inte skrivas i efterhand.
3. De nödvändiga uppgifterna för att dokumentera en aspekt av testningen kan vara minimala. En testanteckning i en anteckningsbok kan till exempel vara tillräcklig för testaren men kan inte enkelt analyseras. Kanske skulle en enkel textlogg med viss uppmärkning gå lika snabbt att skapa, men även kunna analyseras av ett anpassat verktyg.
4. Testprocedurer kanske inte behövs alls om testarna känner till systemet som testas väl. Kanske behövs endast ett testmål eller en testplan. Förberedda testfall kan dokumenteras minimalt i ett kalkylblad.

Avslutningsvis

Om du tar fram omfattande dokumentation för dina intressenter och de inte läser den beror det på att de inte ser något värde i den.

Det är bättre att ge en intressent ett tomt papper och tillsammans lägga till de ämnen som de behöver se i ett dokument och utgå därifrån. Det kan hända att de ber om mängder av innehåll, men det de faktiskt behöver är ganska enkelt. Fortsätt fråga: ”varför vill de ha detta?”

Tack för att du läste. Följ med oss nästa gång när vi kavlar upp ärmarna och börjar med testplanering.

Anmäl dig till The QA Leads nyhetsbrev för att få ett meddelande när nya delar av serien publiceras. Dessa inlägg är utdrag ur Pauls kursen Ledarskap inom test, som vi varmt rekommenderar om du vill fördjupa dig i detta och andra ämnen. Om du gör det kan du använda vår exklusiva kupongkod QALEADOFFER för att få $60 rabatt på kursens fullständiga pris!