Ledelse innen testing: Dokumentasjon

Redaktørens merknad: Velkommen til serien Ledelse innen testing fra programvaretestingsguru og -konsulent Paul Gerrard. Serien er laget for å hjelpe testere med noen års erfaring – særlig de som jobber i smidige team – med å lykkes i rollene som testledere og ledere.

I den forrige artikkelen beskrev vi et risikomanifest for å hjelpe ledere. I denne artikkelen skal vi stille det klassiske spørsmålet «Hvor mye testing er nok?». Avsløring: Det er opp til interessentene.

Meld deg på nyhetsbrevet til The QA Lead for å få beskjed når nye deler av serien publiseres. Disse innleggene er utdrag fra Pauls kurs i ledelse innen testing, som vi på det varmeste anbefaler for å få en dypere gjennomgang av dette og andre emner. Hvis du gjør det, bruk vår eksklusive kupongkode QALEADOFFER for å få $60 i avslag på ordinær kurspris!

Uansett hvilket prosjekt, hvilken organisasjon eller hvilken fremgangsmåte det er snakk om, finnes det alltid en plass for dokumentasjon. God dokumentasjon er en gave, fordi den gir en nyttig oversikt over fremgangsmåte, omfang, planer, design og resultatene av analyse-, utviklings- og testaktiviteter.

I denne artikkelen skal jeg ta for meg:

Verdien av dokumentasjon
Farene ved maler og kopiering/liming
Typer testdokumentasjon
Råd for utforming av dokumentasjon

La oss sette i gang.

Verdien av dokumentasjon

I strukturerte prosjekter regnes dokumenter vanligvis som leveranser i seg selv. I smidige eller kontinuerlige arbeidsformer kan dokumentasjon bli produsert som et biprodukt med mer eller mindre verdi.

Dokumentskriving kan være hovedaktiviteten til profesjonelle tekniske skribenter, men for de fleste som arbeider med dette, er det et ork – uansett hvor nyttig det måtte være. Selv om dokumentskriving kan være kjedelig for noen, er det egentlige problemet med dokumentasjon at det i mange sammenhenger ganske enkelt er bortkastet tid. Den har liten verdi, er utdatert, unøyaktig – eller alt dette på én gang.

Alle testledere har skrevet teststrategier som folk ikke leste eller sluttet seg til. Testere skriver side opp og side ned med testplaner, testskript og rapporter, og det eneste innholdet som har verdi for interessentene, er sammendragene på én side i begynnelsen eller slutten.

Vi har alle skrevet dokumenter som vi vet har liten verdi, og som ingen kommer til å lese.

Dette skyldes vanlige problemer med dokumentasjon som vi møter i både store og små prosjekter. For hvert dokument vi skriver, er det flere spørsmål vi må ta stilling til:

Hvilken type dokument er det? En policy eller strategi, en fremgangsmåte eller plan, et design eller en implementering, eller et resultat og en tolkning?
Hva er formålet med dokumentet?
Hvilket innhold kreves for å oppfylle dette formålet?
Hvilke kunnskapskilder kreves for å utarbeide innholdet?
Hvis dokumentet må endres over tid, hvordan skal det vedlikeholdes?
Hvilket detaljnivå kreves?

Som testleder eller team må du finne ut hvilke typer og formater for dokumentasjon som er hensiktsmessige, og hvis de skal være nøyaktige arkiv eller såkalte levende dokumenter, hvordan de skal vedlikeholdes.

Get Free Access

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

Have an account? Log In

Farene ved maler og kopiering/liming

Hvis prosjektet ditt fastslår at et bestemt dokument er nødvendig, for eksempel en systemtestplan eller et risikoregister, kan det være fristende å finne en ferdig mal for dette (og mange andre dokumenttyper) på internett.

Noen maler kan hevde at de følger en standard eller konvensjon, og at de er lastet ned og brukt tusenvis av ganger. Noen ganger kan en mal se ut til å passe nøyaktig til formålet ditt. Men som vi skal se, kan den skape problemer selv om innholdsfortegnelsen ser omfattende ut.

Det kan også hende at du eller andre i virksomheten din har utarbeidet et lignende dokument for tidligere prosjekter. Du kan bli fristet til å kopiere og gi dette dokumentet et nytt navn, endre referansene til det gamle prosjektet og redigere innholdet slik at det passer.

Advarsel: Etter min erfaring som uavhengig fagfellevurderer er dette svært vanlig og ofte et reelt problem.

For det første er det som regel åpenbart at en kopiering/redigering har blitt gjort. Språket som brukes i teksten, virker ofte frakoblet fra prosjektet, og det finnes mangler og overflødig tekst overalt. Hvorfor er det slik?

Bruk av en ferdig utformet mal eller et eksisterende dokument som kilde medfører flere risikoer:

Det ser omfattende ut, men kan inneholde temaer som er upassende, og utelate andre som er avgjørende.
Det inneholder overskrifter for et dokument, men gir absolutt ingen veiledning om hvilket innhold som passer til hver overskrift.
Det kan inneholde tekst som ser gjenbrukbar ut og er kopiert uendret fra et tidligere, urelatert prosjekt, men teksten kan gi et feilaktig inntrykk eller være unøyaktig eller ufullstendig.

Det kan være nyttig å bruke maler for å få overskrifter og en grunnleggende formateringsstruktur, men hovedproblemet med maler er dette:

*Bruk av en mal kan spare litt tid; risikoen er at du ikke legger nok omtanke i skrivingen.*

Fristelsen ved å bruke maler er å stole for mye på dem og deretter skrive svada i de ulike delene. Du tenker kanskje at dokumentet bare fullfører en «avkrysningsboks», og at ingen kommer til å lese det uansett. Risikoen ved maler er at du slutter å tenke og skriver et dokument som har liten verdi.

Typer testdokumentasjon

I denne delen skal vi se på de ulike formene for testdokumentasjon og diskutere noen hensyn i strukturerte eller smidige/kontinuerlige prosjekter sammenlignet med tradisjonelle fossefallsprosjekter.

Det grunnleggende settet med testdokumenter faller vanligvis inn i følgende kategorier:

Retningslinjer og strategi (noen ganger kjent som overordnet testplan)
Testdefinisjon (også kalt spesifikasjon eller testplaner, forvirrende nok)
Testutforming
Testtilfeller
Testprosedyrer eller skript
Testgjennomføring
Tidsplan
Logg
Testrapport

Utvalget av dokumenttyper ovenfor dekker definisjonen av testprosessen, viktige aktiviteter innen definisjon og gjennomføring samt rapportering.

Det finnes flere andre testrelaterte dokumenter som i mer byråkratiske miljøer ville omfatte definisjoner av testmiljøer og administrasjonsprosesser, akseptanseprosedyrer, prosesser for hendelseshåndtering og så videre (vi skal dekke hendelseshåndtering i en fremtidig artikkel).

En annen åpenbar utelatelse ovenfor ville være en overordnet plan eller tidsplan for testaktiviteter. En tidsplan er egentlig ikke et testdokument, men en delmengde av en overordnet prosjektplan for et strukturert prosjekt (vi skal også dekke planlegging av tidsplaner i en fremtidig artikkel, så følg med!).

Retningslinjer, strategi, overordnet testplan

*Formål*	En policy dekker vanligvis en organisasjon og omfatter et utvalg emner som gjelder for alle prosjekter. En strategi gjelder vanligvis ett enkelt prosjekt (eller én applikasjon) Overordnet sett angir strategien beslutninger om logistiske spørsmål knyttet til fremgangsmåte, overleveringer, ansvar, miljøer og så videre. Noen av disse beslutningene kan tas på forhånd og dokumenteres i strategien Noen beslutninger kan ikke tas nå, men strategien kan dokumentere prosessen, metoden eller informasjonen som gjør det mulig å ta beslutningene (i prosjektet) For usikre situasjoner eller uplanlagte hendelser der det må tas beslutninger, vil strategien dokumentere de generelle prinsippene (eller prosessen) som skal følges.
*Innhold*	Interessenter, mål og sentrale risikoområder Testprinsipper/-tilnærming som skal benyttes, for eksempel en risikobasert testtilnærming Testprosess (testfaser): mål og omfang akseptansekriterier metoder og teknikker leveranser (dokumenter) ansvar Ikke-funksjonelle/tekniske testaktiviteter Policy for håndtering av testleverandører Prosess for hendelseshåndtering Kilder til testdata Testmiljøer Strategi for verktøy og automatisering Dokumentasjonsformater/-maler
*Kilder*	Interessenter, brukere, forretningsanalytikere, utviklere og driftsansvarlige
*Vedlikehold*	Vanligvis et engangsdokument som er definert for et prosjekt eller program
*Smidige-/kontinuerlige hensyn* Teststrategien for smidige prosjekter som bruker Scrum, vil for eksempel sannsynligvis være ganske kort og bare bestå av noen få sider (hvis den i det hele tatt er dokumentert). Testprosessen har kanskje ikke faser, men det vil sannsynligvis finnes en definisjon av testing på ulike nivåer. For eksempel: Testing i en sprint eller iterasjon Testing for en utgivelse Systemintegrasjonstesting (med andre systemer eller grensesnitt) Brukertesting (i sprinten og/eller akseptans på utgivelsesnivå). Hvordan verktøy brukes i utviklertesting (og bruk av for eksempel BDD eller TDD), vil sannsynligvis ikke bli dokumentert, men utviklingsteamene forventes å videreutvikle en fremgangsmåte og samarbeide med andre teammedlemmer når de legger inn ny kode. Testerens rolle kan være å teste funksjoner interaktivt når de blir levert av utviklerne, eller å fungere som testveileder for resten av teamet. På samme måte som bruken av verktøy og/eller TDD vil arbeidsmåten utvikle seg over tid og kanskje aldri bli formelt dokumentert.

Testdefinisjon (utforming, testtilfeller, prosedyrer)

*Formål*	Å vise flyten eller sporbarheten mellom kunnskapskilder og testene som skal gjennomføres Å dokumentere dekningen (mot flere modeller) av aspekter ved kravene, systemfunksjonene eller brukeradferden Å gjøre det mulig for interessenter å gjennomgå omfanget, fremgangsmåten, dekningen og valgene som er gjort ved utformingen av testene som skal benyttes Å gi instruksjoner for gjennomføring av tester på et avtalt detaljnivå.
*Innhold*	Testomfang – både på et høyt nivå, for eksempel funksjoner, og på et lavere nivå, for eksempel atferdsmodeller Testdekning mot elementer i omfanget (for eksempel en matrise for kravdekning eller en annen testmodell) Testtilfeller som identifiserer funksjoner, forhåndsbetingelser, inndata og etterbetingelser (inkludert forventede resultater) Testprosedyrer som kan gjenbrukes for å gjennomføre utvalgte testtilfeller.
*Kilder*	Interessenter, brukere, krav, utforminger og spesifikasjoner
*Vedlikehold*	I prinsippet bør det, når kravene er faste, finnes én avtalt versjon av disse dokumentene Når krav eller omfang endres, må testere justere dokumentene, opprettholde de sporbare delene av dokumentasjonen og føre en konfigurasjonsstyrings- eller endringslogg.
*Smidige-/kontinuerlige hensyn* Testdefinisjon er området der den smidige tilnærmingen skiller seg tydeligst fra strukturerte prosjekter. Testere som fokuserer på funksjoner etter hvert som de leveres, oppretter kanskje ingen dokumentasjon i det hele tatt. Dette er hensiktsmessig hvis det for eksempel finnes en policy eller et styringsdokument for funksjonstesting på systemnivå. Mer sannsynlig er det at det finnes et kort styringsdokument for testing av hver funksjon i en utforskende testøkt. Et styringsdokument er som en plan for en kort utforskningsperiode. Styringsdokumentet vil vanligvis identifisere: Testøktens omfang – funksjonen(e) som skal dekkes og/eller noe spesifisert av systemets funksjonalitet eller atferd Formålet med økten – å utforske bestemte aspekter ved atferden, fokusere på en risiko eller feilmodus eller benytte utvalgte scenarier Økten varer vanligvis i 45–120 minutter. Økten har nødvendigvis et begrenset omfang, men testere står fritt til å utforske utenfor omfanget hvis de mener det er verdifullt Et styringsdokument kan ha som mål å fokusere på utforskning – å lære hva en funksjon gjør, identifisere spesifikk atferd som er verdt å teste, vurdere hvor mye testing/hvor mange økter som kreves for å teste en stor eller kompleks funksjon, forstå hvilke testdata som kan være nødvendige for å teste den, og så videre Et styringsdokument kan fokusere spesifikt på testing av en funksjon, men samtidig fremheve enkelte områder som trenger mer oppmerksomhet enn andre. BDD-verktøy og brukerhistorier i et valgt format, for eksempel brukerhistorier og scenarier formatert med Cucumber eller Gherkin, kan gi den sporbarheten og det innholdet som testutforminger og prosedyrer ellers gir. Hvert scenario med «gitt/når/så»-klausuler identifiserer forhåndsbetingelser, inndata og etterbetingelser. De refererer til én enkelt funksjon, og gir derfor et minimalt testtilfelle/en minimal prosedyre og er i det minste sporbare til funksjoner. Tester som er skriptet for å kjøres av verktøy, kan ha mellomliggende dokumentasjon, men trenger ikke å ha det. Teamene stoler i større grad på observasjon av automatiserte tester og tabeller med testdata som brukes av automatiserte skript, enn på dokumenterte testutforminger.

Testgjennomføring (plan, logg)

*Formål*	Å angi rekkefølgen testene skal kjøres i Å registrere testenes status – kjørt/ikke kjørt og status Å oppgi resultatene fra testgjennomføringen for rapportering
*Innhold*	Testidentifikator, tester, dato/klokkeslett for kjøring, status For tester som ser ut til å vise avvikende atferd (valgfritt): Detaljer om testen slik den ble kjørt, der detaljene avviker fra skriptet Faktiske kontra forventede resultater Andre observasjoner, tolkning Teststatus (defekt, oppsetts- eller miljøavvik osv.) Observasjons- eller feilrapport-ID (der det er relevant)
*Kilder*	Oversikt over testtilfeller/-prosedyrer, testere
*Vedlikehold*	Planen vil endres i takt med testomfanget og prosedyrer som endres, fjernes eller legges til i planen. Tester vil sannsynligvis bli kjørt flere ganger, enten som omtester eller regresjonstester. Loggen bør inneholde en fullstendig historikk for alle tester som omfattes.
*Hensyn ved smidig/kontinuerlig utvikling* Hvis smidige/kontinuerlige prosjekter ikke forplikter seg til testdefinisjonsdokumenter, kompenserer de til en viss grad ved å oppmuntre testere til å føre bedre logger over testgjennomføringen. Når testing utføres i økter basert på testoppdrag, forventes det at testeren fører gode notater om testene som kjøres. Det finnes få dedikerte verktøy for testregistrering som er mer enn notatbøker, så mange testere bruker enkle tekstredigeringsprogrammer, notatverktøy eller papirnotatbøker. Logger brukes vanligvis til å registrere all vesentlig aktivitet og alle observasjoner i øktene mens de gjennomføres. En typisk logg for utforskende testing vil inneholde elementer som: Strukturen til funksjonene som utforskes (et kart over området) Observasjoner og spørsmål knyttet til funksjonene som utforskes i økten Modeller, lister og tabeller over testelementer og testidéer Tester som er kjørt, dokumentert med tilstrekkelige detaljer til å kunne gjentas Avvik som er funnet – feil, tvilsom atferd, trege svar, dårlig brukeropplevelse og så videre Tid brukt på utforskning, testoppsett, testing, undersøkelser, feilregistrering, omtesting, regresjonstesting og ikke-produktiv tid Dato/klokkeslett for registrering Når testere logger øktaktiviteten sin i notatverktøy eller andre verktøy, bruker de en form for oppmerking eller et annet domenespesifikt språk for å strukturere notatene. Disse kan tolkes av enkle interne verktøy for å gi sammendrag av aktiviteten til bruk i testrapporten. Tester som kjøres av verktøy (enten proprietære verktøy eller åpen kildekode-verktøy), logger automatisk. Vanligvis kan disse loggene søkes i ved hjelp av verktøyet eller prosedyrer skrevet av brukeren.

Testrapport

*Formål*	Å kommunisere resultatet av en testfase, utvalgte tester eller en testøkt Kan også gjelde tekniske krav eller ikke-funksjonelle testaktiviteter, og i så fall vil innholdet være annerledes for å samsvare med testmålet Å delvis informere interessenter slik at de kan ta en beslutning om godkjenning eller utgivelse av et system eller delsystem.
*Innhold*	Start- og sluttidspunkt for testen samt varighet Testmiljø Programvare- og systemversjon(er) som testes Mål og omfang for testingen (fra teststrategi, testdefinisjon) Fortellende oppsummering av resultater Funksjoner som anses å fungere som påkrevd Risikoer som anses å være håndtert Gjenstående tester av betydning (mislykkede eller blokkerte) Funksjoner som er delvis testet eller ikke testet Risikoer som er delvis eller ikke håndtert. Detaljer om testresultater med utdata fra testlogger osv. Status for omgåelser av gjenstående avvik Testanalyser Testfremdrift og status over tid Hendelsesstatistikk
*Kilder*	Teststrategi, testdefinisjoner, testlogg, hendelsesrapporter Mye av innholdet i en testrapport vil komme fra verktøyene som brukes til å registrere testdefinisjon(er), testloggen og hendelses- eller feilloggen.
*Vedlikehold*	Dette er et øyeblikksbilde for en testgjennomføringsfase og vedlikeholdes ikke.
*Smidige og kontinuerlige hensyn* Formålet med en testrapport i et smidig prosjekt kan omfatte én enkelt iterasjon eller sprint, testing for en utgivelse eller en testfase på høyere nivå, for eksempel integrasjon eller overordnet systemgodkjenning. Uansett er formålet uendret. Mye av innholdet i en testrapport vil komme fra verktøy eller notater fra testere. Den fortellende oppsummeringen av resultatene skrives av en testleder eller testeren for en mindre omfattende testfase. Som vanlig vil rapporten sannsynligvis være mindre formell, og det vil trolig være mindre rådata som kan danne grunnlag for avanserte analyser. Under iterasjonen(e) kan fremdriften gjennom iterasjonen, målt i funksjoner eller brukerhistorier som er levert, testet og godkjent av brukerne, for eksempel registreres i et verktøy eller på et offentlig Kanban-brett. På denne måten holdes interessentene informert om fremdriften gjennom hele iterasjonen, og det er mindre behov for en formell rapport ved slutten av en testperiode. Synlighet rundt fremdrift er en viktig bekymring for smidige team. Med regelmessige, kanskje daglige, standup-møter rundt et Scrum-brett deler teammedlemmene for eksempel sin forståelse av fremdriften, stiller spørsmål til hverandre og blir hele tiden enige om en posisjon (og neste steg). På denne måten kan det hende at en formell testrapport aldri blir nødvendig, fordi teamet alltid er informert og oppdatert. Hvis testerne fører skriftlige notater om aktivitetene i øktene sine, finnes det ingen analyserbare data tilgjengelig for å presentere automatiserte rapporter, så rapportering av økter og fremdrift kan presenteres på en offentlig og visuell måte. Dette krever høy grad av disiplin og gode kommunikasjonsevner hos testerne. Testlederen eller testansvarlig må utarbeide en tilsvarende informativ rapport til interessentene basert på muntlige rapporter.

Slik bruker du DevOps-måltall til å skalere virksomheten din

Noen råd

Dokumentasjon i prosjekter er et følsomt tema for testere så vel som andre prosjektmedlemmer.

De fleste oppfatter det å skrive dokumentasjon som et ork.

Her er noen ting du bør ha i tankene når du utformer dokumentasjonen.

Dokumentasjonen må ha et tydelig definert formål og en tydelig målgruppe. Hvis målgruppen din ikke trenger dokumentasjonen, kommer de ikke til å lese den. Hvis den ikke samsvarer med deres egne mål, kommer de ikke til å slutte opp om den.
Det er vanligvis bedre å registrere dokumentasjonen av en aktivitet før eller mens du utfører den. TDD registrerer for eksempel tester før koden skrives. Logger fra testøkter bør registreres under økten og ikke skrives i etterkant.
De nødvendige dataene for å registrere et aspekt ved testingen kan være minimale. En test som er skrevet inn i en notatbok, kan for eksempel være tilstrekkelig for testeren, men kan ikke enkelt analyseres. Kanskje en enkel tekstlogg med noe oppmerking ville vært like rask å opprette, men samtidig kunne analyseres av et spesialtilpasset verktøy.
Testprosedyrer er kanskje ikke nødvendige i det hele tatt hvis testerne kjenner systemet som testes godt. Kanskje det bare er nødvendig med et testmål eller et testmandat. Forberedte testtilfeller kan dokumenteres minimalt i et regneark.

Til slutt

Nødvendighet er dokumentasjonens mor.

Hvis du utarbeider omfattende dokumentasjon for interessentene dine og de ikke leser den, er det fordi de ikke ser verdien i den.

Det er bedre å gi en interessent et blankt ark og sammen legge til temaene de trenger å se i et dokument, og arbeide videre derfra. Det kan hende at de ber om mengder av innhold, men det de faktisk trenger, er ganske enkelt. Fortsett å spørre: «Hvorfor ønsker de dette?»

Takk for at du leste. Bli med oss neste gang når vi bretter opp ermene og begynner med litt testplanlegging.

Meld deg på nyhetsbrevet til The QA Lead for å få beskjed når nye deler av serien publiseres. Disse innleggene er utdrag fra Pauls kurs i ledelse innen testing, som vi på det sterkeste anbefaler hvis du ønsker å gå dypere inn i dette og andre emner. Hvis du gjør det, kan du bruke vår eksklusive kupongkode QALEADOFFER og få $60 i rabatt på ordinær kurspris!