Lederskap innen testing: Testplanlegging

Hva er egentlig en plan?

En prosjektplan kombinerer prosjektoppgavene, beregnede varigheter, avhengigheter og leveranser til en planlagt modell av virkeligheten.

Hvis du ser på planen som en forutsigelse av fremtiden, ville du vært svært forsiktig med å stole på den, men det er vanligvis det vi gjør.

Du har kanskje møtt prosjektledere som behandler planen sin som sin personlige virkelighet – sin egen vrangforestillingsverden. Men vi bør ikke være så harde mot prosjektledere – de er ofte motivert til å lage en plan og levere i henhold til den, uansett hva som skjer.

Planen er ikke virkeligheten; den er en modell av virkeligheten som krever kontinuerlig endring.

I denne artikkelen skal jeg dekke alle stadier av testplanlegging, inkludert:

• Leveranser
• Hvordan
• Ressurser
• Støttenettverket ditt
• Estimater
• Avhengigheter, risikoer og antakelser
• Kommunikasjon, forpliktelser og fremdriftsrapportering

Men først bør vi få en klar forståelse av hvor nyttig en plan er. 

Hvorfor planlegge?

Formålet med planlegging er vanligvis å utarbeide en omforent fremgangsmåte, et sett med forpliktelser, avhengigheter, kostnader og en tidsplan for å levere et prosjekt. Planen er en forståelse mellom prosjektets interessenter, leverandører og deltakere som vanligvis beskriver følgende:

• Hvilke ressurser som kreves, og når
• Når oppgavene må starte og avsluttes, og hvem som skal utføre dem
• Hvilke ferdigheter som kreves for å fullføre oppgavene
• Verktøyene og teknologiene som støtter planen
• Leveransene, og når de skal leveres
• Kostnadene for innsatsen og ressursene som kreves
• Prosessen for å føre prosjektet eller prosessen gjennom de ulike stadiene
• Risikoene som truer leveransen.

Noen av disse aspektene kan være spesifisert i en strategi eller allerede være på plass. Det kan for eksempel være kjent hvilke leverandører som er involvert, og hva de skal gjøre for prosjektet. Verktøyene og teknologien som skal brukes, kan allerede være kjent og på plass. Personene, testmiljøene og dataene kan være klare. Det kan også finnes en strategi som definerer prosessen, fremgangsmåten eller teknikkene som skal brukes.

Mens strategien beskriver prinsippene eller teorien, beskriver planen imidlertid det praktiske eller den logistiske gjennomføringen av hvordan prosjektet skal leveres i virkeligheten.

En strategi beskriver hvordan et prosjekt i prinsippet skal gjennomføres, mens planen definerer og bekrefter hvordan prosjektet skal gjennomføres i praksis.

For mange prosjektledere ligger planen i programvare som Microsoft Project, men en gjennomførbar plan avhenger av at alle prosjektdeltakerne vet hva de skal gjøre, og hvordan de skal gjøre det. For å oppnå dette må planen og kunnskapen om hvordan ting skal gjøres, kommuniseres til og forplikte alle involverte.

Planlegging er en reise, ikke en oppgave

For å sitere USAs tidligere president Dwight D. Eisenhower: «planlegging er alt. Planen er ingenting.» Dette utsagnet er så viktig at det fortjener å gjentas i nesten alle arbeidssammenhenger i systemprosjekter. Men hva betyr det å si at planen er ingenting? Hva er poenget med planlegging hvis resultatet er en verdiløs plan? 

Planen du ender opp med, er aldri verdiløs, men Eisenhowers utsagn handler om selve planleggingen og verdien av den sammenlignet med planen. La oss raskt sammenligne hvordan planlegging fungerer i henholdsvis lengre, strukturerte prosjekter og smidige/kontinuerlige prosjekter.

Strukturert planlegging kontra smidig planlegging

I et langsiktig prosjekt må virksomheten din, leverandørene dine og det interne IT-personellet vite hvilken forpliktelse som kreves av dem, slik at de kan planlegge tilgjengeligheten av personer og fysiske ressurser.

Det tar verdifull tid å samle inn informasjonen som kreves for å lage en plan. Med alle avhengighetene til ressurser og personer, samt leverandørenes og de interne medarbeidernes forpliktelser og prestasjoner, kan mye gå galt. Noe vil gå galt. Derfor er planen, som en forutsigelse av fremtiden, beheftet med store utfordringer.

Dagen etter at en plan er publisert, og hver dag deretter, kommer ny informasjon frem, og det blir nødvendig med enkelte justeringer. Krav forkastes, leverandører leverer for sent, og miljøer, testdata eller verktøy er ikke klare i tide. Listen fortsetter. Planlegging er aldri en engangsoppgave, men en kontinuerlig – nesten daglig – aktivitet.

Uplanlagte hendelser blir ofte behandlet som støy og får ikke særlig mye oppmerksomhet. Men senere utvikler noen av disse mindre problemene seg til store problemer. En av utfordringene med fossefallsprosjekter er at denne kontinuerlige justeringen kan være belastende, fordi alle endringer oppfattes som unødvendig tukling. Prosjekter fortsetter ofte ufortrødent, i håp om at ting skal «ordne seg på kvelden». Men dette er sjelden tilfelle, og det har blitt sagt mange ganger:

Hvordan blir et prosjekt ett år forsinket? Én dag om gangen.

Den smidige tilnærmingen er delvis en reaksjon på frustrasjonen over faste eller ufleksible planer. Smidighet er det utprøvde alternativet til tregheten i tungvinte, trinnvise tilnærminger. Men betyr dette at smidige prosjekter ikke planlegger? Nei. 

Selv i smidige prosjekter er noe planlegging på forhånd nødvendig for å strukturere arbeidet, samle ressurser og planlegge – i det minste på et overordnet nivå – lanseringsprosessen for de kommende månedene. Men for hver iterasjon, og ofte fra dag til dag, justeres den overordnede planen kontinuerlig for å ta hensyn til hendelser og ny informasjon som kommer frem.

Planlegging er en kontinuerlig læringsreise, ikke en oppgave med en leveranse.

Testplanlegging

Så langt har vi sett på prosjektplanlegging i sin helhet og antydet at det i høyeste grad er en kontinuerlig aktivitet. Nå skal vi fokusere spesifikt på planlegging av testing i prosjekter. 

Testplanlegging ligner svært mye på prosjektplanlegging – det er egentlig bare en plan i mindre skala. Testplanen må naturligvis også integreres med den større prosjektplanen, fordi den er avhengig av andre prosjektaktiviteter og leveranser (og andre oppgaver er avhengige av testingen). Testplaner blir ofte forstyrret fordi disse avhengighetene ikke blir oppfylt.

Testplaner er relativt enkle på oversiktsnivå. Det kan være flere aktiviteter som er avhengige av hovedprosjektet. Dette er ofte det som vises som oppgaver i den større prosjektplanen. Men disse aktivitetene fordeles i et team, som kanskje har en stor beholdning av testelementer det skal planlegges og gjennomføres tester for. 

Dette detaljnivået er ikke like relevant for prosjektlederens tidsplan og defineres og administreres vanligvis på lokalt nivå i testteamet.

La oss se på noen av kjerneelementene i testplanen din.

Leveranser

Hva er leveransene fra testingen?

For et spørsmål! Det er vel testspesifikasjonene, testene, resultatene og rapportene? Leveransene finnes i hovedsak i dokumentasjonen, så alt vi trenger å bekymre oss for, er å få papirarbeidet ut og krysse av noen bokser. 

Men denne tilnærmingen, selv om den er vanlig, er delvis skyld i at testing (og testere) har fått et rykte for å være dyre, tungrodde byråkrater med liten verdi. For hvem leser egentlig disse omfattende dokumentene?

Anta at det ikke finnes noen intensjon om å produsere testdokumentasjon i et smidig prosjekt. Dette er svært sannsynlig, så hva leverer testingen egentlig i slike situasjoner? Hvilken verdi har testing i det hele tatt? Det er vel litt sent å stille disse spørsmålene, er det ikke?

Når en komponent, et delsystem eller hele systemet testes, er resultatet bevis på hvordan systemet oppfører seg i en bestemt situasjon eller kontekst. Bevis på systemets oppførsel samles inn og sammenstilles for å presenteres for interessenter (utviklere, brukere, ledere osv.), slik at de kan ta en beslutning: rette feil, integrere en komponent, godta eller avvise funksjonalitet, eller lansere eller distribuere et delsystem eller systemet som helhet.

Leveransen fra testing er bevis på systemets oppførsel som interessenter bruker til å ta en beslutning.

Nå er det i noen prosjekter nødvendig å utarbeide testdokumentasjon for å registrere hvordan en test ble avgrenset, utformet, implementert og gjennomført. Men det er dokumentasjonen av systemets atferd som til syvende og sist er det verdifulle leveranseproduktet for interessentene.

Verdien av testing er graden av tillit interessentene har til å ta beslutninger basert på testdokumentasjon.

Denne dokumentasjonen kan samles inn, tabuleres og analyseres systematisk i avanserte teststyringsløsninger og presenteres for interessentene i elegante grafiske formater. Eller håndskrevne notater kan brukes av en tester til å presentere testhistorien muntlig for en produkteier i et daglig statusmøte.

Uansett hvordan den samles inn og presenteres, er den avsluttende oppgaven i testingen å overlevere dokumentasjonen.

Hvordan

Uavhengig av prosjektets størrelse eller metodikk avhenger testing av en bestemt serie aktiviteter. Vi skal se på en generell prosess gjennom testerens (eller teamets) øyne, og deretter se på noen av variasjonene som forekommer. 

Det finnes det som kan kalles «testaktiviteter», og det finnes «teststøtteaktiviteter» eller «logistikkaktiviteter». For å være sikker på at du inkluderer alle aktivitetene i planen, kan tabellene nedenfor være nyttige sjekklister.

En aktivitet i tabellen ovenfor som du kanskje ikke kjenner igjen så godt, er tilbakemeldingsaktiviteten. Du har allerede måttet arbeide med dårlige krav. 

Aktiviteten med tilbakemeldinger, gjennomgang og utfordring er der testere, etter å ha tenkt gjennom og modellert et krav, oppdager problemer og kan bruke eksempler til å demonstrere hvor krav mangler, er tvetydige eller motstridende.

Hvis du oppfatter kravene som dårlige, er det absolutt verdt å sette av tid til denne aktiviteten.

Testlogistikk

Testlogistikk støtter testaktivitetene ovenfor. Selv om listen over testaktiviteter jeg har gitt, er ganske omfattende, varierer testlogistikken fra prosjekt til prosjekt og fra organisasjon til organisasjon. Listen nedenfor er derfor ikke uttømmende. I prosjektet ditt bør du ta deg tid til å tenke gjennom hver aktivitet eller avhengighet som kreves for å gjennomføre testingen.

Ressurser (menneskelige, fysiske)

Vi bruker ofte ordet ressurser når vi omtaler personer i prosjektene våre, og for noen føles ikke det behagelig. Mennesker er ikke ting, de er selvsagt menneskelige vesener. I mindre prosjekter kan det være mulig å bruke navn, men i større organisasjoner, når prosjektteam er involvert og kanskje ennå ikke er bemannet, er et antall ressurser ganske enkelt en kort måte å si et antall personer på.

Enda viktigere er det at det ikke nødvendigvis er antallet personer som teller – det er deres ferdigheter som virkelig betyr noe. Selvfølgelig arbeider mennesker på ulike måter og vanligvis i ulikt tempo, så du må ta hensyn til dette i planleggingen.

I tillegg til personer trenger du, på ulike stadier, forskjellige fysiske ressurser for at testingen skal kunne gjennomføres. Disse varierer fra det hverdagslige til det svært spesifikke, og mangel på noen av dem kan true testoppdraget.

Du kan allerede være så heldig å ha tilgang til et fullt utstyrt, administrert og dedikert testlaboratorium. Hvis ikke, må du kanskje spesifisere alt – fra fysisk plass og møbler til post-it-lapper og viskelær – for å definere arbeidsmiljøet ditt.

I tabellen nedenfor finner du noen typiske nødvendige ressurser. Listen din vil utvilsomt være betydelig annerledes. 

Når du har identifisert alle ressursene som kreves for å gjennomføre planen din, bør du vurdere om du trenger flere aktiviteter i planen for å skaffe dem.

Ditt støttenettverk

Hvis personene og ferdighetene du trenger for å gjennomføre testingen, var under din kontroll, kunne prosjekter vært mye enklere! Men få team har alle ferdighetene de trenger, eller fullmakt og tilgang til de nødvendige fysiske ressursene. Mange prosjekter bemannes og drives etter en matriseorganiseringsmodell. Viktige teammedlemmer rapporterer faktisk til ledere i andre spesialiserte avdelinger, og du får bare en begrenset forpliktelse fra dem.

Du må kanskje angi et bestemt antall timer per dag eller planlegge tidspunkter for å få tilgang til spesialistkompetansen ovenfor. Noen ganger vil du bli spurt om hvilket servicenivå som er akseptabelt, f.eks. «Høyprioriterte forespørsler vil bli besvart innen tretti minutter», og så videre.

Estimater

Estimering i programvareprosjekter er krevende. Det er skrevet mye om hvordan estimering er vanskelig eller til og med umulig. Men estimater er nødvendige i alle prosjekter, og jo større prosjektet er, desto mer avhengige er vi av dem.

Vi trenger estimater for å lage en tidsplan, men problemet er at estimering ikke gir deg nøyaktighet. Det beste vi noen gang kan gjøre, er å beregne en arbeidsinnsats eller medgått tid med en viss grad av sikkerhet eller sannsynlighet.

Noen betrakter estimering som en svart kunst, og det finnes til og med en #NoEstimates-bevegelse med mange tilhengere. Det er stor uenighet om estimering noen gang kan bli nøyaktig nok, eller om det i det hele tatt er god praksis i programvareprosjekter.

Estimering vil aldri bli en eksakt vitenskap. Men basert på mine erfaringer er dette noen prinsipper jeg føler meg komfortabel med å dele:

• Krav er feilbarlige og upresise.
• Folk er mer eller mindre kompetente, samvittighetsfulle og hardtarbeidende.
• Jo mindre arbeidsoppgaven er, desto enklere er den å estimere. Bryt ned store oppgaver i mindre enheter der det er mulig, og summer estimatene til den større oppgaven.
• Estimering er basert på erfaring. Hvis du ikke har noen, kan du finne ut hvor andres erfaring er relevant og kan tilpasses.
• Arbeidsoppgaven din er unik, så se etter arbeidsmønstre i andre kjente situasjoner der du har erfaring.
• Be andre om å estimere og sammenlign. Når avvik diskuteres, blir forskjeller i forventninger, sikkerhet og grundighet synlige.
• Estimer situasjonen i beste fall, og deretter situasjonen i verste fall. Et godt estimat ligger et sted imellom.

Estimer i dag og start arbeidet. I morgen og hver påfølgende dag vil estimatet for når du blir ferdig, forbedres med kunnskapen du har fått.

Avhengigheter, risikoer og antakelser

I en tidligere artikkel diskuterte vi risiko og testingens rolle i risikohåndtering. Produktrisiko handler om hvorvidt produktet oppfyller brukernes behov med hensyn til funksjonelle eller tekniske krav. Her er fokuset på risikoene knyttet til den faktiske leveringsplanen.

Ting går galt i prosjekter. I planleggingsarbeidet må du tydeliggjøre hvilke risikoer for feil du har vurdert og tatt høyde for. Det finnes tre aspekter ved dette: avhengigheter, risikoer og tiltak.

Avhengigheter

Avhengigheter representerer en liste over menneskelige og fysiske ressurser som kreves, samt forgjengeraktiviteter som må fullføres for at de planlagte aktivitetene dine skal lykkes og leveres. 

Det finnes alltid avhengigheter for enhver testaktivitet, enten det er en omfattende systemtest eller en utforskende testøkt av en funksjon. Avhengigheter dekker tre hovedaspekter.

Risikoer

Risiko er sannsynligheten for at planen din mislykkes under gjennomføringen. Risiko er knyttet til ting som:

• Estimater: Hva kan føre til at estimatene dine blir feil? At systemet er mer komplekst, har feil, er ufullstendig eller stadig endres, kan påvirke estimatene dine.
• At personer ikke er tilgjengelige, mangler erfaring eller ferdigheter, eller ikke er fullt ut forpliktet til prosjektfasen din. Dette kan være teammedlemmer eller personer i støttenettverket ditt.
• Infrastruktur, for eksempel testmiljøer, verktøy (eller opplæring i bruk av verktøy) eller kontorlokaler, som ikke er tilgjengelig, er feilaktig klargjort eller har feil.
• Forgjengeraktiviteter som ikke fullføres i tide (eller blir forlatt, leverer delvise eller mangelfulle produkter eller ikke leverer i det hele tatt).

Tiltak

For hver av disse risikoene må du vurdere sannsynlighet, konsekvens og, når det er betydelig, et passende tiltak eller en forventet konsekvens. Disse tiltakene har vanligvis én av følgende former:

• Antakelse: Risikoen anses som liten nok til å ignoreres eller betraktes som uvesentlig. Men den er registrert og dokumentert som en antakelse (om tilgjengelighet, fullstendighet osv.).
• Justering: Risikoen er betydelig, men det finnes et tiltak som kan redusere dens påvirkning på planen. Hvis systemet som skal testes for eksempel er delvis levert, med manglende funksjoner, kan planen justeres slik at bare de tilgjengelige funksjonene testes.
• Konsekvens: Noen risikoer kan ikke innarbeides. Hvis systemet leveres for sent, kan testingen ikke starte før det er levert.

Kommunikasjon, forpliktelse og fremdriftsrapportering

Til slutt kommer vi til et avgjørende, men ofte oversett aspekt ved planlegging. Du kan utarbeide en prosjektplan med alle oppgaver, deltakere, ressurser, ansvarsområder, avhengigheter, tidsplaner, arbeidsinnsats og kostnader inkludert. Eller det kan være en muntlig forståelse mellom medlemmene av et smidig team. 

Uansett må planen kommuniseres effektivt til alle, slik at alle vet hva som kreves og når.

En omforent plan er en kontrakt mellom deltakerne. Hvis en teamleder godkjenner en plan, er det implisitt eller eksplisitt en forpliktelse til å oppfylle teamets del av kontrakten.

Planen er en kontrakt mellom deltakerne.

I mindre formelle prosjekter finnes det kanskje ingen skriftlig plan eller noen forpliktelser i det hele tatt. Under slike omstendigheter er planen en løpende samtale mellom teammedlemmene. Teamet møtes daglig, og de aktive oppgavene i planen diskuteres i sanntid. Hva arbeider folk med? Går fremdriften som forventet? Hvilke problemer opplever folk? Hvilke problemer hindrer fremdriften?

I alle prosjekter er hensikten med fremdriftsrapportering todelt. Det er åpenbart nødvendig å kommunisere hvor alle befinner seg når det gjelder deres nåværende prosjektaktivitet. Men fremdriftsrapporten er også en løpende, periodisk kontroll av at fremdriften kan opprettholdes, og en bekreftelse på at deltakernes forpliktelser kan stoles på.

Takk for at du leste, bli med oss neste gang for … du gjettet det, gjennomføring!

Meld deg på nyhetsbrevet fra QA-lederen for å få beskjed når nye deler av serien publiseres. Disse innleggene er utdrag fra Pauls kurs i testledelse, som vi på det sterkeste anbefaler hvis du ønsker å fordype deg i dette og andre emner. Hvis du gjør det, bruk vår eksklusive kupongkode QALEADOFFER for å få $60 i avslag på full kurspris!