En stor del af diskussionen om QA har en tendens til at involvere store koncepter og emner. Masser af jargon, hvidbøger og TED-foredrag. Det kan hurtigt blive ret abstrakt. Og lad os se det i øjnene: ofte ikke særlig relevant for de praktiske forhindringer, som QA-teams møder i deres daglige arbejde.
Så nogle gange er det nyttigt at sænke tempoet og fokusere på nogle af disciplinens mere ydmyge aspekter. I dette tilfælde testdokumentation. Det virker umiddelbart som et enkelt emne, men som med alt, der har at gøre med softwareudvikling, lurer der monstre under gulvbrædderne.
Spørgsmålet om, hvordan og hvor meget testdokumentation man skal skrive, bringer næsten øjeblikkeligt QA i et Catch-22. For lidt, og det er svært at vide, hvor man står i forhold til den samlede indsats. Og det bliver endnu sværere at omfordele testopgaver til forskellige ressourcer, når behovet tilsiger det, og samtidig bevare en ensartet testning. Men for meget, og — nå ja. Der findes vel aldrig for meget testdokumentation, gør der?
Eller gør der?
Jeg har ofte set QA-teams på samvittighedsfuld og ihærdig vis påtage sig den heroiske opgave at dokumentere deres tests fuldstændigt. Til én version. Og derefter har dokumentationen en tendens til at blive forsømt. Den samler digitalt støv et sted på et netværk. Og ikke fordi QA-teamet er holdt op med at tro på dens betydning. De er bare fuldstændig udmattede af den indsats, der kræves for at opdatere den til den næste større version.
For i deres iver skrev QA-teamet utroligt detaljerede testbeskrivelser, hvor tingene blev brudt ned til et manisk mikroskopisk niveau af hyperpræcision. De oprettede separat testdokumentation for hver eneste facet eller egenskab ved en enkelt funktion eller brugerinteraktion. De genererede dusinvis af individuelle testbeskrivelser og opgaver for det, der grundlæggende er én enkelt testopgave. Det er som den person, man havner bag i køen i supermarkedet, og som insisterer på at betale for dagligvarer til $80 med småmønter.
Resultatet af denne atomiserende fanatisme er genereringen af hundredvis, nogle gange tusindvis, af testbeskrivelser for den pågældende version. QA er uforvarende endt med at skrive en Dickens-roman. En fortælling om ti tusind byer. Har du nogensinde faktisk læst en af dem? Heller ikke mig.
Konsekvensen er, at ingen har tid eller tålmodighed til at opdatere disse tusindvis af individuelle testbeskrivelser. For prioriteten vil altid være at teste den næste iteration af softwaren i stedet, eftersom det i sidste ende skaber omsætning, mens opdatering af testdokumentation ikke gør.
Men også fordi applikationer til testdokumentation på ingen måde gør det nemt at udføre masseopdateringer af testdokumentationsposter. Det kan være besværligt og uintuitivt at foretage globale ændringer i testklasser i de fleste applikationer (det gælder også mange apps til fejlsporing — selv i dag). Det øger den tid og mentale belastning, der er forbundet med at gøre det.
Som følge heraf ender al denne omhyggelige testdokumentation med at blive opgivet. Og al den tid, der blev brugt på at skabe den, er i sidste ende spildt. Fordi den ikke kan genbruges. Det er en døgnflue. Det er softwaretestens "I Melt With You". Alligevel er testdokumentation en absolut nødvendighed for en gentagelig, systematisk testindsats. Og dermed Catch-22-situationen.
Der er en vej ud af dette dilemma. Og selvom det smerter mig at indrømme det, bør vi se til ingeniørarbejdet efter løsningen. Eller i det mindste efter inspirationen til den. Ingeniører stod over for et lignende problem i de første år med kommerciel softwareudvikling. På grund af begrænsningerne i datidens programmeringssprog var de nødt til at omskrive kode for de samme grundlæggende attributter, handlinger og sikkerhedsforanstaltninger for hver funktion. Igen og igen. Hukommelseshåndtering/affaldsindsamling var et godt (og farligt) eksempel på dette problem.
Som følge heraf genererede ingeniørerne enorme mængder redundant kode og spildte enorme mængder tid (ikke at ingeniører nødvendigvis har noget imod det sidste. Ebay eksisterer stadig af en grund.). Så fandt en kvik person på objektorienteret programmering, hvor der kunne oprettes kodeobjekter, som i kraft af deres natur arvede standardattributter. Den samme kode behøvede ikke at blive skrevet (eller klippet og klistret ind) hver gang. Det betød, at kvaliteten ikke længere afhang af en bestemt ingeniørs hukommelse eller skrivefærdigheder. Noget QA er evigt taknemmelig for.
Dette er en meget nyttig vision for QA, når afdelingen kæmper med testdokumentationens blindgyde. Konceptet med objektorientering, som det findes inden for ingeniørarbejde, kan ikke anvendes direkte på dette problem, men som metafor har det meget at byde på. Opfindsomhed tilpasser sig pr. definition nemt til nye situationer.
Mange gange i min karriere har jeg stået over for problemet med, hvordan man skaber testdokumentation, der er omfattende, men kortfattet, kan anvendes her og nu, men også nemt genbruges til fremtidige versioner. Og den løsning, jeg til sidst fandt frem til, er at anvende idéen om et "objekt" på selve testdokumentationen.
Her taler jeg om langt mere end en skabelon til testdokumentation. De er naturligvis meget nyttige som standardiseringsværktøj, men irrelevante for det aktuelle problem. Jeg udviklede idéen om, at tests kunne dokumenteres på en måde, der i ét dokumentationsstykke indeholdt alle dens forskellige tilstande, vendepunkter, arbejdsgange og særlige betingelser. Da denne pære tændtes i mit dunkle hoved, virkede svaret pludselig meget enkelt. Og meget gennemførligt.
Lad os gå i gang med det.
At tage den røde pille
Svaret er at se enhver individuel test, og dermed også dens dokumentationsartefakt, ikke som en påstand eller beskrivelse af testning op mod et enkelt datapunkt eller en isoleret betingelse. Men som en beskrivelse af hele den matrix (se, hvad jeg gjorde?) af betingelser, som funktionen eller kapaciteten skal valideres under.
Dette indebærer en holistisk tilgang til definitionen af individuelle tests. En sammenhængende, enkeltstående testopgave kan ikke på meningsfuld vis opdeles i dusinvis af uafhængige "tests" uden paradoksalt nok at udviske specificiteten i testningen af funktionen som helhed. Man kan ikke se skoven for bare træer.
Her er det nyttigt at gennemgå begrebet en testkontekst. For hvis du effektivt vil implementere idéen om et testobjekt, skal du først kunne adskille den uforanderlige kerne i en funktionalitet fra dens sekundære anvendelses- og driftskontekster. Det er et spørgsmål, som den atomare stil inden for testdokumentation undgår, og derfor lærer testere aldrig, hvordan de udfører denne analyse systematisk og bevidst. Endnu en ulempe ved atomisering.
Sagt enkelt er testkontekster for en funktion eller et system det sæt af betingelser, miljøer, arbejdsgange eller tilstande, der kan variere uafhængigt af hinanden inden for selve funktionens grænser. Operativsystemer og OS-versioner er et tydeligt eksempel på dette. Fremmedsprog er et andet. Systemtilstande er endnu et (f.eks. i forbindelse med en webserver: hukommelsescaching slået til eller fra). Når du først forstår denne sondring, kan du nemt komme i tanke om mange andre, der er relevante for de produkttyper, du tester.
Når du har afsluttet denne analyse (som under alle omstændigheder bør være grundlaget for al professionel testplanlægning), har du mulighed for at oprette kompakte former for testdokumentation, der indarbejder denne sondring. I det system, jeg beskriver, vil et enkelt testdokumentationsartefakt bestå af:
- En beskrivelse af den kernefunktion eller -kapacitet, der testes.
- En liste over alle de kontekster, som kernefunktionaliteten skal valideres i.
- Alt andet, som du normalt alligevel ville have inkluderet (forudsætninger for at testen er gyldig, systemressourcer og nødvendige privilegier til at køre testen, et link til de relevante produktkrav osv.). Intet af dette erstattes af det, jeg foreslår.
På dette tidspunkt tænker du måske: "Hey, det kan da være mange kontekster!" Jo, bestemt. Men se på det på denne måde. At gøre det sådan skaber ikke mere arbejde for dig. Faktisk reducerer det arbejdet. Det bliver lettere at udarbejde omfattende testplaner med vores kuraterede liste over softwaretestværktøjer til dokumentation. Denne metode vil nemlig *i høj grad* reducere antallet af individuelle tests, du skal bruge tid på at oprette, og som du skal vedligeholde (eller lade være med at vedligeholde) i fremtiden. I det atomare system skulle du derimod oprette et individuelt testdokumentationsartefakt for hver enkelt af dem. Det fører til det Catch-22-paradoks, der blev beskrevet i begyndelsen af denne artikel.
Denne metode til testdokumentation har ganske vist visse procesmæssige konsekvenser, som måske først kan virke besværlige. Eller endda foruroligende. Og det gælder ikke kun QA, men også andre projektinteressenter. Men hvis alle involverede tager sig tid til at forstå dem, vil de se, at der i virkeligheden er tale om forbedringer. For alle.
Den vigtigste konsekvens er, at når man samler matricen af funktionskontekster i selve hovedtesten, betyder det logisk, at hvis den enkelte test mislykkes i blot én af disse kontekster, er hele testen mislykket. Også selvom det kun er én. Jeg kan forestille mig, at dette vil skabe panik blandt ingeniørerne. For det kan se ud, som om du rigger spillet imod dem og hæver barren til et umuligt niveau, før en test kan tælle som "bestået". Men denne frygt er let at håndtere. Påpeg blot to ting over for dem og en tredje over for dig selv:
- Denne metode vil faktisk reducere antallet af fejl, der genereres mod deres arbejde gennem testning. Med den atomare metode ville fejl i en hvilken som helst af disse kontekster nemlig have resulteret i sin egen separate fejlrapport. Dermed ville det samlede antal fejl for den enkelte funktion være steget. Det bør få ingeniørerne til at smile. Og projektlederne.
- For det andet giver testning ved hjælp af denne metodologi automatisk kontekst for det funktionelle svigts faktiske omfang. For hvad er det første spørgsmål, som den ingeniør, der får tildelt opgaven med at rette fejlen, altid vil stille dig? "Øh, sker det overalt? Eller kun i kontekst X?" Og i stedet for at skulle skynde dig tilbage til dit skrivebord og køre testen igen i kontekst X (fordi du måske glemte at gøre det i den oprindelige test?), har du allerede svaret, og ingeniøren fratages en undskyldning for at undgå at arbejde på det (det, QA giver i form af færre fejl, tager QA tilbage senere).
- For det tredje sikrer kontekstanalysen til testdokumentationen, at du faktisk har tænkt over alle relevante kontekster, da du dokumenterede testen i første omgang. Det betyder, at du har mindre risiko for at opleve de panikøjeblikke — tre dage før eller, endnu værre, efter lanceringen — hvor du opdager, at du har glemt at teste i nogle meget vigtige kontekster. En QA-indsats baseret på panik er ikke særlig effektiv. Og heller ikke nogen særligt behagelig oplevelse psykisk.
I maskinen
Denne objektinspirerede metode til testdokumentation vil drastisk reducere mængden af dokumentationsartefakter, du skal producere, og dermed gøre det mere sandsynligt, at du faktisk både kan og vil opdatere dem løbende til kommende udgivelser.
Den eneste malurt i bægeret er, at få applikationer til testdokumentation er opsat til at dokumentere tests på denne måde fra starten. De antager typisk den atomare dokumentationsmodel, eftersom den desværre er normen, og har derfor ingen indbygget funktionalitet, der nemt kan understøtte den objektmodel, jeg har beskrevet her.
Det er derfor, jeg ofte har tyet til langt mindre sofistikerede programløsninger — som Excel — der faktisk til dette formål er langt mere fleksible og nemme at tilpasse, fordi de er beregnet til generelle formål. Ulempen ved den strategi er, at det bliver besværligt at integrere dem med Jira osv. Men måske er integration overvurderet.
Under alle omstændigheder er det stadig sådan, at mange applikationer til test og fejldokumentation gør det djævelsk vanskeligt at udføre masseopdateringer af individuelle poster. Uanset hvilke protokoller du vælger at bruge til at oprette dem. Men det er sandt, uanset hvordan du vælger at skrive din testdokumentation. Én problemstilling ad gangen, folkens.
Jeg beklager på forhånd (eller i dit tilfælde bagudrettet), at jeg ikke giver dig en skabelon til testobjekter. Det har været min erfaring, at det som regel er en dårlig idé at levere skabeloner, fordi folk bare begynder at bruge din skabelon. Tilgængeligheden af færdige, generiske skabeloner har en tendens til at foregribe og kortslutte selve teamets kreativitet, når det skal udarbejde en skabelon, der passer til deres faktiske behov, processer og værktøjer i praksis. Så ingen sure miner.
Jeg er altid åben over for dine spørgsmål og forslag. Du skal bare skrive dem som et opslag eller sende dem til mig på LinkedIn.
Og som altid: held og lykke.
