Ledelse inden for test: Dokumentation

Redaktørens note: Velkommen til serien Ledelse inden for test fra softwaretestguru og -konsulent Paul Gerrard. Serien er designet til at hjælpe testere med et par års erfaring – især dem på agile teams – med at udmærke sig i roller som testledere og ledere.

I den forrige artikel beskrev vi et risikomanifest, der kan hjælpe ledere. I denne artikel stiller vi det ældgamle spørgsmål “Hvor meget test er nok?”. Afsløring: Det afhænger af interessenterne.

Tilmeld dig nyhedsbrevet fra QA-lederen for at få besked, når nye dele af serien udkommer. Disse indlæg er uddrag fra Pauls kursus i testledelse, som vi varmt anbefaler, hvis du vil gå mere i dybden med dette og andre emner. Hvis du gør det, kan du bruge vores eksklusive kuponkode QALEADOFFER til at få $60 i rabat på den fulde kursuspris!

Uanset projekt, organisation eller tilgang er der altid brug for dokumentation. God dokumentation er en gave, fordi den giver en nyttig oversigt over tilgang, omfang, planer, design samt resultaterne af analyse-, udviklings- og testaktiviteter.

I denne artikel gennemgår jeg:

Værdien af dokumentation
Farerne ved skabeloner og kopiering/indsættelse
Typer af testdokumentation
Råd til design af dokumentation

Lad os komme i gang.

Værdien af dokumentation

I strukturerede projekter betragtes dokumenter normalt som leverancer i sig selv. I agile eller kontinuerlige miljøer kan dokumentation blive produceret som et biprodukt med større eller mindre værdi.

Dokumentskrivning kan være den primære aktivitet for professionelle tekniske skribenter, men for de fleste fagfolk er det en pligt – uanset hvor nyttig den måtte være. Selvom dokumentskrivning kan være kedelig for nogle mennesker, er det egentlige problem med dokumentation, at det i mange sammenhænge ganske enkelt er spild af tid. Den har kun ringe værdi, er forældet, unøjagtig – eller alt dette på én gang.

Alle testledere har skrevet teststrategier, som folk ikke læste eller bakkede op om. Testere skriver lange testplaner, testskripter og rapporter, og det eneste indhold, der har værdi for interessenterne, er de korte opsummeringer på én side i begyndelsen eller slutningen.

Vi har alle skrevet dokumenter, som vi ved har ringe værdi, og som ingen vil læse.

Det skyldes almindelige problemer med dokumentation, som vi møder i både store og små projekter. For hvert dokument, vi skriver, er der flere spørgsmål, vi skal tage stilling til:

Hvilken type dokument er det? En politik eller strategi, en tilgang eller plan, et design eller en implementering eller et resultat og en fortolkning?
Hvad er formålet med dokumentet?
Hvilket indhold er nødvendigt for at opfylde dette formål?
Hvilke videnskilder er nødvendige for at skabe indholdet?
Hvis dokumentet skal ændre sig over tid, hvordan bliver det så vedligeholdt?
Hvilket detaljeringsniveau er nødvendigt?

Som testleder eller som team skal I finde ud af, hvilke typer og formater af dokumentation der er passende, og hvis de skal være nøjagtige optegnelser eller såkaldte levende dokumenter, hvordan de vedligeholdes.

Get Free Access

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

Have an account? Log In

Farerne ved skabeloner og kopiering/indsættelse

Hvis dit projekt fastslår, at der er behov for et bestemt dokument, f.eks. en systemtestplan eller et risikoregister, kan det være fristende at finde en færdig skabelon til disse og mange andre dokumenttyper på internettet.

Nogle skabeloner hævder måske, at de følger en bestemt standard eller konvention, og at de er blevet downloadet og brugt tusindvis af gange. Nogle gange kan en skabelon se ud til at passe præcis til dit formål. Men som vi skal se, kan den give problemer, selv hvis indholdsfortegnelsen ser omfattende ud.

Det kan også være, at du eller andre i din virksomhed har udarbejdet et lignende dokument til tidligere projekter. Du kan blive fristet til at kopiere og omdøbe dette dokument, ændre henvisningerne til det gamle projekt og redigere indholdet, så det passer.

Advarsel: Efter min erfaring som uafhængig kontrollør er dette meget almindeligt og ofte et reelt problem.

For det første er det som regel åbenlyst, at der er blevet kopieret og redigeret. Det sprog, der bruges i teksten, virker ofte løsrevet fra projektet, og der er huller og overflødig tekst overalt. Hvorfor er det sådan?

Brug af en foruddefineret skabelon eller et eksisterende dokument som kilde indebærer flere risici:

Det ser omfattende ud, men det kan indeholde emner, der er irrelevante, og udelukke andre, som er afgørende.
Det indeholder overskrifter til et dokument, men giver absolut ingen vejledning om, hvilket indhold der er passende for hver overskrift.
Det kan indeholde tekst, der ser genanvendelig ud og er kopieret uændret fra et tidligere, ikke-relateret projekt, men teksten kan give et forkert indtryk eller være unøjagtig eller ufuldstændig.

Det kan være nyttigt at bruge skabeloner til at få overskrifter og en grundlæggende layoutstruktur, men skabelonernes største problem er dette:

*Brug af en skabelon kan spare tid; risikoen er, at du ikke tænker tilstrækkeligt over teksten.*

Fristelsen ved skabeloner er at stole for meget på dem og derefter skrive tom snak til de forskellige afsnit. Du tænker måske, at dokumentet blot afkrydser et punkt, og at ingen alligevel vil læse det. Risikoen ved skabeloner er, at du holder op med at tænke og skriver et dokument, der har ringe værdi.

Typer af testdokumentation

I dette afsnit ser vi på de forskellige former for testdokumentation og drøfter nogle overvejelser i strukturerede eller agile/kontinuerlige projekter sammenlignet med traditionelle vandfaldsprojekter.

Det grundlæggende sæt af testdokumenter falder typisk ind under følgende kategorier:

Politik og strategi (undertiden kendt som overordnet testplan)
Testdefinition (også kaldet specifikation eller testplaner, hvilket er forvirrende)
Testdesign
Testcases
Testprocedurer eller -scripts
Testudførelse
Tidsplan
Log
Testrapport

Ovenstående udvalg af dokumenttyper dækker definitionen af testprocessen, de vigtigste aktiviteter inden for definition og udførelse samt rapportering.

Der findes flere andre testrelaterede dokumenter, som i mere bureaukratiske miljøer ville omfatte definitioner af testmiljøer og administrationsprocesser, acceptprocedurer, processer for hændelseshåndtering og så videre (vi kommer ind på hændelseshåndtering i en kommende artikel).

En anden åbenlys udeladelse ovenfor ville være en overordnet plan eller tidsplan for testaktiviteter. En tidsplan er egentlig ikke et testdokument, men en delmængde af en overordnet projektplan for et struktureret projekt (vi kommer også ind på planlægning af tidsplaner i en kommende artikel, så følg med!).

Politik, strategi, overordnet testplan

*Formål*	En politik dækker normalt en organisation og omfatter et udvalg af emner, der dækker alle projekter. En strategi dækker normalt et enkelt projekt (eller en applikation) Overordnet set indeholder strategien beslutninger om logistiske spørgsmål vedrørende tilgang, overdragelser, ansvar, miljøer osv. Nogle af disse beslutninger kan træffes på forhånd og dokumenteres i strategien Nogle beslutninger kan ikke træffes nu, men strategien kan dokumentere den proces, metode eller information, der gør det muligt at træffe beslutningerne (i projektet) I usikre situationer eller ved uplanlagte hændelser, hvor der skal træffes beslutninger, dokumenterer strategien de generelle principper (eller den proces), der skal følges.
*Indhold*	Interessenter, mål, væsentlige risici Testprincipper/-tilgang, der skal anvendes, f.eks. en risikobaseret test-tilgang Testproces (testfaser): mål og omfang acceptkriterier metoder, teknikker leverancer (dokumenter) ansvar Ikke-funktionelle/tekniske testaktiviteter politik for styring af (test)leverandører proces for hændelseshåndtering kilder til testdata testmiljøer strategi for værktøjer/automatisering Dokumentationsformater/-skabeloner
*Kilder*	Interessenter, brugere, BA'er, udviklere, drift
*Vedligeholdelse*	Normalt et enkeltstående dokument, der er udarbejdet for et projekt eller et program
*Overvejelser ved agil/kontinuerlig udvikling* Teststrategien for agile projekter, der f.eks. bruger Scrum, er sandsynligvis ret kortfattet og består kun af få sider (hvis den overhovedet dokumenteres). Testprocessen har måske ikke faser, men der vil sandsynligvis være en definition af test på forskellige niveauer. For eksempel: Test i et sprint eller en iteration Test af en udgivelse Systemintegrationstest (med andre systemer eller grænseflader) Brugertest (i sprintet og/eller accept på udgivelsesniveau). Hvordan værktøjer anvendes i udviklertest (og f.eks. ved brug af BDD eller TDD) vil sandsynligvis ikke blive dokumenteret, men udviklingsteams forventes at udvikle en tilgang og koordinere med andre teammedlemmer, når de implementerer ny kode. Testerens rolle kan være at teste funktioner interaktivt, når de udgives af udviklerne, eller at fungere som testcoach for resten af teamet. Ligesom brugen af værktøjer og/eller TDD vil arbejdsformen udvikle sig over tid og måske aldrig blive formelt dokumenteret.

Testdefinition (design, testtilfælde, procedurer)

*Formål*	At demonstrere flowet eller sporbarheden mellem videnskilder og de test, der skal udføres At dokumentere dækningen (i forhold til flere modeller) af aspekter af kravene, systemfunktionerne eller brugeradfærden At gøre det muligt for interessenter at gennemgå omfanget, tilgangen, dækningen og de valg, der er truffet ved oprettelsen af de test, der skal anvendes At give instruktioner til udførelse af test på et aftalt detaljeringsniveau.
*Indhold*	Testens omfang – både på et højt niveau, f.eks. funktioner, og på et lavere niveau, f.eks. adfærdsmodeller Testdækning i forhold til elementer i omfanget (f.eks. en kravdækningsmatrix eller en anden testmodel) Testtilfælde, der identificerer funktioner, forudsætninger, input og efterbetingelser (herunder forventede resultater) Testprocedurer, der kan genbruges til at udføre udvalgte testtilfælde.
*Kilder*	Interessenter, brugere, krav, design og specifikationer
*Vedligeholdelse*	I princippet bør der ved faste krav være én aftalt version af disse dokumenter Hvis der sker ændringer i krav eller omfang, skal testere justere dokumenterne, vedligeholde dokumentationens sporbare aspekter og føre en konfigurationsstyrings- eller ændringslog.
*Overvejelser ved agil/kontinuerlig udvikling* Området for testdefinition er det sted, hvor tilgangen til agil udvikling adskiller sig mest markant fra strukturerede projekter. Potentielt opretter testere, der fokuserer på funktioner, efterhånden som de leveres, slet ingen dokumentation. Dette er passende, hvis der f.eks. findes en systemdækkende politik eller et charter for funktionstest. Mere sandsynligt vil der være et kort charter for test af hver funktion i en eksplorativ testsession. Et charter er som en plan for en kort udforskningsperiode. Et charter vil typisk identificere: Testsessionens omfang – de funktioner, der skal dækkes, og/eller en bestemt funktionalitet eller adfærd i systemet Sessionens mål – at udforske bestemte aspekter af adfærd, fokusere på en risiko eller fejltilstand eller anvende bestemte scenarier Sessionens varighed er typisk 45-120 minutter. Sessionen er nødvendigvis begrænset i omfang, men testere kan frit udforske uden for omfanget, hvis de vurderer, at det er værdifuldt Et charter kan have til formål at fokusere på udforskning – at lære, hvad en funktion gør, identificere specifik adfærd, der er værd at teste, vurdere hvor meget testning/hvor mange sessioner der kræves for at teste en stor eller kompleks funktion, forstå hvilke testdata der kan være nødvendige for at teste den osv. Et charter kan fokusere specifikt på test af en funktion, men kan fremhæve nogle områder, der kræver mere opmærksomhed end andre. BDD-værktøjer og historier i et valgt format, f.eks. historier og scenarier formateret med Cucumber eller Gherkin, kan levere den sporbarhed og det indhold, som testdesign og procedurer gør. Hvert scenarie med »givet/når/så«-klausuler identificerer forudsætninger, input og efterbetingelser. De henviser til en enkelt funktion, så de udgør et minimalt testtilfælde/en minimal procedure og kan som minimum spores til funktioner. Test, der er skrevet som scripts til at blive kørt af værktøjer, har muligvis mellemliggende dokumentation, men det er ikke sikkert. Teams er i højere grad afhængige af observation af automatiserede test og tabeller med testdata, der anvendes af automatiserede scripts, end af dokumenterede testdesign.

Testudførelse (plan, log)

*Formål*	At angive rækkefølgen for kørsel af test At registrere testenes status – kørt/ikke kørt og status At levere resultaterne af testudførelsen til rapportering
*Indhold*	Testidentifikator, tester, dato/klokkeslæt for kørsel, status For test, der ser ud til at udvise afvigende adfærd (valgfrit): Detaljer om testen, som den blev kørt, hvor detaljer afviger fra scriptet Faktiske resultater kontra forventede resultater Andre observationer, fortolkning Teststatus (fejl, opsætnings- eller miljøafvigelse osv.) Observations- eller fejlrapport-id (hvor det er relevant)
*Kilder*	Inventar over testcases/-procedurer, testere
*Vedligeholdelse*	Planen vil blive ændret i takt med testomfanget og procedurer, der ændres, fjernes eller tilføjes i planen. Test vil sandsynligvis blive kørt flere gange, enten som gentest eller regressionstest. Loggen bør indeholde en komplet historik for alle test inden for omfanget.
*Overvejelser vedrørende agil/fortløbende udvikling* Hvis agile/fortløbende projekter ikke forpligter sig til dokumenter med testdefinitioner, kompenserer de til en vis grad ved at opfordre testere til at føre bedre log over testudførelsen. Når test udføres i sessioner ud fra testcharterer, forventes testeren at føre gode noter over de test, vedkommende kører. Der findes kun få dedikerede værktøjer til testlogning, som er mere end notesbøger, så mange testere bruger simple tekstredigeringsprogrammer, noteprogrammer eller fysiske notesbøger. Logge bruges typisk til at registrere al væsentlig aktivitet og alle observationer i sessioner, mens de udføres. En typisk log over eksplorativ testning vil indeholde aspekter som: Strukturen af de udforskede funktioner (et kort over området) Observationer og spørgsmål vedrørende de funktioner, der blev udforsket i sessionen Modeller, lister og tabeller over testelementer og testidéer Kørte test, dokumenteret med tilstrækkelige detaljer til at kunne gentage dem Fundne afvigelser – fejl, tvivlsom adfærd, langsomme svar, dårlig brugeroplevelse osv. Tid brugt på udforskning, testopsætning, testning, undersøgelse, fejlregistrering, gentest, regressionstest og ikke-produktiv tid Dato/klokkeslæt for registreringen Når testere registrerer deres sessionsaktivitet i noteprogrammer eller andre værktøjer, bruger de en form for opmærkning eller et andet domænespecifikt sprog til at strukturere deres noter. Disse kan analyseres af simple interne værktøjer for at levere aktivitetsoversigter til brug i testrapporten. Test, der udføres af værktøjer (uanset om de er proprietære eller open source), gemmer automatisk logge. Typisk kan der forespørges i disse logge via værktøjet eller brugerskrevne procedurer.

Testrapport

*Formål*	At kommunikere resultatet af en testfase, udvalgte test eller en testsession Kan også anvendes på tekniske krav eller ikke-funktionelle testaktiviteter, hvor indholdet i så fald vil variere, så det passer til testmålet At informere interessenter delvist, så de kan træffe en beslutning om accept eller frigivelse af et system eller et delsystem.
*Indhold*	Start- og sluttidspunkter samt varighed for testen Testmiljø Software- og systemversion(er) under test Mål og omfang for testen (fra teststrategien, testdefinitionen) Fortællende opsummering af resultaterne Funktioner, der vurderes at fungere som krævet Risici, der vurderes at være håndteret Udestående væsentlige test (mislykkede eller blokerede) Funktioner, der er delvist testet eller ikke testet Risici, der er delvist håndteret eller ikke håndteret. Detaljer om testresultater med resultater fra testlogge osv. Status for midlertidige løsninger på udestående anomalier Testanalyser Testfremdrift og status over tid Hændelsesstatistik
*Kilder*	Teststrategi, testdefinitioner, testlog, hændelsesrapporter En stor del af indholdet i en testrapport vil komme fra de værktøjer, der bruges til at registrere testdefinition(er), testloggen og hændelses- eller fejlloggen.
*Vedligeholdelse*	Dette er et øjebliksbillede af en testudførelsesfase og vedligeholdes ikke.
*Overvejelser ved agil udvikling/kontinuerlig udvikling* Formålet med en testrapport i et agilt projekt kan omfatte en enkelt iteration eller sprint, test af en udgivelse eller en testfase på højere niveau såsom integration eller overordnet systemaccept. Uanset hvad er formålet uændret. En stor del af indholdet i en testrapport vil komme fra værktøjer eller noter fra testere. Den fortællende opsummering af resultaterne skrives af en testleder eller testeren ved en testfase af mindre omfang. Som sædvanlig vil rapporten sandsynligvis være mindre formel, og der vil formentlig være færre rådata, som kan danne grundlag for avancerede analyser. Under iterationen eller iterationerne kan fremdriften gennem iterationen med hensyn til funktioner eller brugerhistorier, der er leveret, testet og godkendt af brugerne, bestemt blive registreret i et værktøj eller på en offentlig Kanban-tavle. På denne måde holdes interessenterne informeret om fremdriften gennem hele iterationen, og der er mindre behov for en formel rapport ved afslutningen af en testperiode. Synlighed omkring fremdriften er en vigtig bekymring for agile teams. Med regelmæssige, måske daglige statusmøder omkring en Scrum-tavle deler teammedlemmerne for eksempel deres forståelse af fremdriften, stiller spørgsmål til hinanden og aftaler løbende en position (og de næste skridt). På denne måde er en formel testrapport måske aldrig nødvendig, fordi teamet altid er informeret og opdateret. Hvis testerne fører skriftlige noter over deres sessionsaktiviteter, er der ingen analyserbare data til rådighed til at præsentere automatiserede rapporter, så sessions- og fremdriftsrapportering kan præsenteres på en offentlig, visuel måde. Dette kræver en høj grad af disciplin og gode kommunikationsevner fra testernes side. Testlederen eller -chefen skal tilsvarende levere en informativ rapport til interessenterne baseret på mundtlige rapporter.

Nogle råd

Dokumentation i projekter er et følsomt emne for testere såvel som andre projektmedlemmer.

De fleste betragter det som en pligt at skrive dokumentation.

Her er nogle ting, du bør have in mente, når du udformer din dokumentation.

Dokumentation skal have et klart defineret formål og en klart defineret målgruppe. Hvis din målgruppe ikke har brug for dokumentationen, vil de ikke læse den. Hvis den ikke relaterer sig til deres egne mål, vil de ikke tage den til sig.
Det er generelt bedre at registrere dokumentationen for en aktivitet, før eller mens du udfører den. TDD registrerer for eksempel test, før koden skrives. Testsessionslogge bør registreres under sessionen og ikke skrives bagefter.
De nødvendige data til at registrere et aspekt af testningen kan være minimale. En test, der er skrevet ned i en notesbog, kan for eksempel være tilstrækkelig for testeren, men kan ikke nemt analyseres. Måske vil en simpel tekstlog med lidt opmærkning være lige så hurtig at registrere, men samtidig kunne analyseres af et specialtilpasset værktøj.
Testprocedurer er måske slet ikke nødvendige, hvis testerne kender systemet under test godt. Måske er kun et testmål eller et testcharter nødvendigt. Forberedte testtilfælde kan dokumenteres minimalt i et regneark.

Til sidst

Nødvendighed er dokumentationens moder.

Hvis du udarbejder omfattende dokumentation til dine interessenter, og de ikke læser den, er det, fordi de ikke kan se værdien i den.

Det er bedre at give en interessent et blankt stykke papir og sammen tilføje de emner, som vedkommende har brug for at se i et dokument, og arbejde videre derfra. Det kan være, at de beder om enorme mængder indhold, men det, de faktisk har brug for, er ret enkelt. Bliv ved med at spørge: ‘hvorfor ønsker de dette?’

Tak, fordi du læste med. Slut dig til os næste gang, når vi smøger ærmerne op og går i gang med noget testplanlægning.

Tilmeld dig nyhedsbrevet fra The QA Lead for at få besked, når nye dele af serien udkommer. Disse indlæg er uddrag fra Pauls kursus i testledelse, som vi varmt anbefaler, hvis du vil dykke dybere ned i dette og andre emner. Hvis du gør det, kan du bruge vores eksklusive kuponkode QALEADOFFER og få $60 i rabat på kursets fulde pris!