Mye av diskusjonen om QA har en tendens til å dreie seg om store konsepter og temaer. Masse sjargong, fagartikler og TED-foredrag. Det kan bli ganske abstrakt ganske raskt. Og la oss innse det: ofte er det ikke særlig relevant for de praktiske hindringene QA-team i arbeid møter hver dag.
Derfor kan det noen ganger være nyttig å roe ned litt og fokusere på noen av de mer beskjedne aspektene ved fagområdet. I dette tilfellet testdokumentasjon. Et tilsynelatende enkelt tema, men som med alt som har med programvareutvikling å gjøre, lurer monstre under gulvplankene.
Spørsmålet om hvordan og hvor mye testdokumentasjon man skal skrive, involverer nesten umiddelbart QA i et Catch-22. For lite, og det er vanskelig å vite hvor man står med hensyn til arbeidet som helhet. Og enda vanskeligere blir det å omfordele testoppgaver til ulike ressurser etter behov og samtidig bevare konsistent testing. Men for mye og — vent litt. Det finnes vel aldri for mye testdokumentasjon?
Eller gjør det?
Jeg har ofte sett QA-team samvittighetsfullt og iherdig begi seg ut på den heroiske oppgaven det er å dokumentere testene sine fullstendig. For én lansering. Og så har denne dokumentasjonen en tendens til å bli forsømt. Den samler digitalt støv et eller annet sted på et nettverk. Og ikke fordi QA-teamet har sluttet å tro på hvor viktig den er. De er bare fullstendig utmattet av innsatsen som kreves for å oppdatere den til neste større lansering.
For i sin iver skrev QA-teamet utrolig detaljerte testbeskrivelser, der de brøt ting ned til et manisk mikroskopisk nivå av overdrevet spesifisitet. De opprettet separat testdokumentasjon for hvert aspekt eller hver egenskap ved én enkelt funksjon eller brukerinteraksjon. De genererte dusinvis av individuelle testbeskrivelser og oppgaver for det som i bunn og grunn er én enkelt testoppgave. Det er som personen du havner bak i køen i dagligvarebutikken, som insisterer på å betale for dagligvarer til 80 dollar med småmynter.
Resultatet av denne atomiserende fanatismen er at det genereres hundrevis, noen ganger tusenvis, av testbeskrivelser for den aktuelle lanseringen. QA har uvitende endt opp med å skrive en Dickens-roman. En fortelling om ti tusen byer. Har du faktisk lest en slik? Ikke jeg heller.
Konsekvensen er at ingen har tid eller tålmodighet til å oppdatere disse tusenvis av individuelle testbeskrivelsene. For prioriteten vil alltid være å teste neste versjon av programvaren i stedet, siden det til syvende og sist genererer inntekter, mens oppdatering av testdokumentasjon ikke gjør det.
Men også fordi applikasjoner for testdokumentasjon ikke gjør det enkelt å masseoppdatere poster med testdokumentasjon. Å gjøre globale endringer i testklasser kan være tungvint og lite intuitivt i de fleste applikasjoner (dette gjelder også mange apper for feilsporing — selv i dag). Det øker kostnadene i form av tid og mental helse ved å gjøre det.
Som et resultat ender all denne omhyggelige testdokumentasjonen opp med å bli forlatt. Og all tiden som ble brukt på å opprette den, er til syvende og sist bortkastet. Fordi den ikke kan gjenbrukes. Den er et engangsfenomen. Den er «I Melt With You» innen programvaretesting. Likevel er testdokumentasjon helt nødvendig for en repeterbar og systematisk testinnsats. Der har vi Catch-22-situasjonen.
Det finnes en vei ut av dette dilemmaet. Og selv om det smerter meg å innrømme det, bør vi se til ingeniørfaget etter løsningen. Eller i det minste etter inspirasjon. Ingeniører møtte et lignende problem i de første årene med kommersiell programvareutvikling. På grunn av begrensningene i datidens programmeringsspråk måtte de skrive om kode for de samme grunnleggende egenskapene, handlingene og sikkerhetstiltakene for hver funksjon. Om og om igjen. Minnehåndtering/søppeltømming var et godt (og farlig) eksempel på dette problemet.
Som et resultat genererte ingeniørene enorme mengder overflødig kode og kastet bort enorme mengder tid (ikke at ingeniører nødvendigvis har noe imot det siste. Ebay eksisterer fortsatt av en grunn.). Så kom en smarting på objektorientert programmering, der det kunne opprettes kodeobjekter som arvet standardegenskaper i kraft av sin natur. Den samme koden måtte ikke skrives (eller klippes ut og limes inn) hver gang. Det betydde at kvalitet ikke lenger var avhengig av en bestemt ingeniørs hukommelse eller skriveferdigheter. Noe QA er evig takknemlig for.
Dette er en svært nyttig visjon for QA når fagområdet forsøker å komme seg ut av testdokumentasjonens blindvei. Konseptet med objektorientering slik det finnes i ingeniørfaget, kan ikke brukes direkte på dette problemet, men som metafor har det mye å tilby. Kløkt tilpasser seg per definisjon lett til nye situasjoner.
Flere ganger i løpet av karrieren har jeg møtt problemet med hvordan man kan opprette testdokumentasjon som er omfattende, men kortfattet, som kan brukes der og da, men som også enkelt kan gjenbrukes for fremtidige lanseringer. Løsningen jeg til slutt landet på, er å bruke ideen om et «objekt» på selve testdokumentasjonen.
Her snakker jeg om langt mer enn en mal for testdokumentasjon. Slike maler er naturligvis svært nyttige som et standardiseringsverktøy, men irrelevante for problemet vi står overfor. Jeg utviklet ideen om at tester kunne dokumenteres på en måte som inkluderte alle de ulike modusene, vendepunktene, arbeidsflytene og spesialbetingelsene i ett og samme dokumentasjonsstykke. Da denne lyspæren endelig lyste i det dunkle hodet mitt, virket svaret plutselig svært enkelt. Og svært gjennomførbart.
La oss se nærmere på det.
Å ta den røde pillen
Svaret er å se på enhver individuell test, og dermed også dokumentasjonsartefakten til testen, ikke som en påstand eller beskrivelse av testing mot ett enkelt datapunkt eller en isolert betingelse. Men som en beskrivelse av hele matrisen (ser du hva jeg gjorde?) av betingelser der funksjonen eller egenskapen må valideres.
Dette innebærer en helhetlig tilnærming til definisjonen av individuelle tester. En sammenhengende, enkeltstående testoppgave kan ikke på en hensiktsmessig måte splittes opp i dusinvis av uavhengige «tester» uten paradoksalt nok å viske ut spesifisiteten i testingen av funksjonen som helhet. Det er en situasjon der man ikke ser skogen for bare trær.
Her er det nyttig å se nærmere på konseptet testkontekst. For å kunne implementere ideen om et testobjekt på en effektiv måte, må du først kunne skille den uforanderlige kjernen i en funksjonalitet fra de sekundære kontekstene den anvendes og opererer i. Dette er et spørsmål som den atomistiske stilen for testdokumentasjon unngår, og derfor lærer testere aldri hvordan de skal utføre denne analysen systematisk og bevisst. Enda en ulempe ved atomistisk kraft.
Enkelt sagt er testkontekster for en funksjon eller et system settet med betingelser, miljøer, arbeidsflyter eller tilstander som kan variere uavhengig av hverandre innenfor selve funksjonens grenser. Operativsystemer og OS-versjoner er et tydelig eksempel på dette. Fremmedspråk er et annet. Systemtilstander er enda et eksempel (for eksempel når det gjelder en webserver: minnebufring på eller av). Når du først forstår dette skillet, kan du enkelt tenke på mange andre som er relevante for de produkttypene du tester.
Når du har fullført denne analysen (som uansett bør være grunnlaget for all profesjonell testplanlegging), har du mulighet til å lage kompakte former for testdokumentasjon som inneholder dette skillet. I systemet jeg beskriver, vil ett enkelt testdokument bestå av:
- En beskrivelse av kjernefunksjonen eller -egenskapen som testes.
- En liste over alle kontekstene der kjernefunksjonaliteten må valideres.
- Alt annet du normalt ville ha tatt med uansett (forutsetninger for at testen skal være gyldig, systemressurser og privilegier som er nødvendige for å kjøre testen, en lenke til de relevante produktkravene osv.). Ingenting av dette erstattes av det jeg foreslår.
Nå tenker du kanskje: «Hei, det kan bli mange kontekster!» Jo, absolutt. Men se på det på denne måten. Å gjøre det slik skaper ikke mer arbeid for deg. Faktisk reduserer det arbeidet. Det blir enklere å utarbeide omfattende testplaner med vår kuraterte liste over verktøy for programvaretesting og dokumentasjon. Denne metoden vil nemlig *kraftig* redusere antallet individuelle tester du må bruke tid på å opprette, og som du må vedlikeholde (eller la være å vedlikeholde) i fremtiden. I det atomistiske systemet måtte du derimot opprette et eget testdokument for hver av dem. Dette fører til Catch-22-situasjonen som ble beskrevet i begynnelsen av denne artikkelen.
Denne metoden for testdokumentasjon har visse prosessmessige konsekvenser som i første omgang kan virke upraktiske. Eller til og med urovekkende. Og ikke bare for QA, men også for andre prosjektinteressenter. Men hvis alle involverte tar seg tid til å forstå dem, vil de se at dette i realiteten er forbedringer. For alle.
Den viktigste konsekvensen er at når matrisen av funksjonskontekster bygges inn i selve hovedtesten, betyr dette logisk nok at hvis den ene testen mislykkes i én av disse kontekstene, har hele testen mislyktes. Selv om det bare gjelder én. Jeg kan se for meg at dette kan skape panikk blant ingeniørene. Det kan virke som om du legger kortene mot dem og hever terskelen til et umulig nivå for at en test skal regnes som «bestått». Men denne frykten er enkel å håndtere. Bare påpek to ting overfor dem, og en tredje for deg selv:
- Denne metoden vil faktisk redusere antallet feil som testingen registrerer i arbeidet deres. Med den atomistiske metoden ville nemlig en feil i én av disse kontekstene ha ført til sin egen separate feilrapport. Dermed ville det samlede antallet feil for den ene funksjonen ha økt. Dette bør få både ingeniører og prosjektledere til å smile.
- For det andre gir testing med denne metodikken automatisk kontekst for det faktiske omfanget av funksjonsfeilen. For hva er det første spørsmålet ingeniøren som får i oppgave å rette feilen, alltid kommer til å stille? «Eh, skjer det overalt? Eller bare i kontekst X?» I stedet for å måtte skynde deg tilbake til skrivebordet og kjøre testen på nytt i kontekst X (fordi du kanskje glemte å gjøre det i den opprinnelige testingen), har du allerede svaret, og ingeniøren blir fratatt en unnskyldning for å unngå å jobbe med saken (det QA gir i form av færre feil, tar QA senere tilbake).
- For det tredje sikrer kontekstanalysen for testdokumentasjonen at du faktisk tenkte gjennom alle relevante kontekster da du dokumenterte testen i utgangspunktet. Det betyr at det er mindre sannsynlig at du får de paniske øyeblikkene – tre dager før eller, enda verre, etter lansering – der du innser at du glemte å teste i noen svært viktige kontekster. En QA-innsats basert på panikk er ikke særlig effektiv. Den er heller ikke spesielt behagelig psykisk.
I maskinen
Denne objektinspirerte metoden for testdokumentasjon vil drastisk redusere mengden dokumentasjon du må produsere, og dermed gjøre det mer sannsynlig at du faktisk både er i stand til og villig til å oppdatere den kontinuerlig for senere utgivelser.
Den eneste malurten i begeret er at få applikasjoner for testdokumentasjon er satt opp for å dokumentere tester på denne måten fra starten av. De antar gjerne den atomistiske dokumentasjonsmodellen, siden den dessverre er normen, og har derfor ingen innebygd funksjonalitet som enkelt kan håndtere objektmodellen jeg har beskrevet her.
Det er derfor jeg ofte har tydd til langt mindre avanserte programvareløsninger – som Excel – som faktisk er langt mer fleksible og enklere å tilpasse til dette formålet, fordi de er laget for generell bruk. Ulempen med denne strategien er at det blir tungvint å integrere dem med Jira og lignende. Men kanskje integrasjon er overvurdert.
Uansett gjenstår det faktum at mange applikasjoner for testing og dokumentasjon av feil gjør det djevelsk vanskelig å utføre masseoppdateringer av individuelle poster. Uavhengig av hvilke protokoller du velger å bruke når du oppretter dem. Men det gjelder uansett hvordan du velger å skrive testdokumentasjonen din. Én ting om gangen, folkens.
Jeg beklager på forhånd (eller i ditt tilfelle, i ettertid) at jeg ikke gir deg en mal for testobjekter. Min erfaring er at det som regel er en dårlig idé å tilby maler, fordi folk ganske enkelt begynner å bruke malen din. Tilgjengeligheten av ferdiglagde, generiske maler har en tendens til å foregripe og kortslutte kreativiteten i selve teamet når det skal utarbeide en mal som er tilpasset deres faktiske behov, prosesser og verktøy i praksis. Så ingen sure miner.
Jeg er alltid åpen for spørsmål og forslag fra deg. Bare legg dem ut eller send dem til meg på LinkedIn.
Og som alltid: lykke til.
