Lederskab inden for test: Testplanlægning

Hvad er en plan egentlig?

En projektplan samler projektopgaverne, de estimerede varigheder, afhængighederne og leverancerne i en planlagt model af virkeligheden.

Hvis du betragter planen som en forudsigelse af fremtiden, ville du være meget forsigtig med at stole på den, men det er normalt det, vi gør.

Du har måske mødt projektledere, der betragter deres plan som deres personlige virkelighed – deres egen vrangforestillingsverden. Men vi bør ikke være så hårde ved projektledere – de er ofte motiverede til at udarbejde en plan og levere i overensstemmelse med den, uanset hvad.

Planen er ikke virkeligheden; den er en model af virkeligheden, som kræver konstant forandring.

I denne artikel gennemgår jeg alle faser af testplanlægning, herunder:

• Leverancer
• Hvordan
• Ressourcer
• Dit supportnetværk
• Estimater
• Afhængigheder, risici og antagelser
• Kommunikation, forpligtelse og statusrapportering

Men først skal vi danne os en klar idé om, hvor nyttig en plan er. 

Hvorfor planlægge?

Formålet med planlægning er normalt at skabe en aftalt tilgang, et sæt forpligtelser, afhængigheder, omkostninger og en tidsplan for levering af et projekt. Planen er en forståelse mellem projektets interessenter, leverandører og deltagere, som typisk fastlægger følgende:

• Hvilke ressourcer der kræves, og hvornår
• Hvornår opgaver skal begynde og afsluttes, og hvem der skal udføre dem
• Hvilke kompetencer der kræves for at fuldføre opgaverne
• De værktøjer og teknologier, der understøtter planen
• Leverancerne, og hvornår de vil blive leveret
• Omkostningerne ved den nødvendige indsats og de nødvendige ressourcer
• Processen for at føre projektet/processen gennem dens faser
• De risici, der truer leveringen.

Nogle af disse aspekter kan være angivet i en strategi eller allerede være på plads. Det kan for eksempel være kendt, hvilke leverandører der er involveret, og hvad de skal gøre for projektet. De værktøjer og den teknologi, der skal anvendes, er måske allerede kendt og på plads. Personerne, testmiljøerne og dataene er måske klar. Der kan også være en strategi, som definerer den proces, tilgang eller de teknikker, der skal anvendes.

Mens strategien beskriver principperne eller teorien, beskriver planen imidlertid de praktiske forhold eller den logistik, der bestemmer, hvordan projektet skal leveres i virkeligheden.

En strategi beskriver, hvordan et projekt principielt skal gennemføres; planen definerer og bekræfter, hvordan projektet skal gennemføres i praksis.

For mange projektledere findes planen i software som Microsoft Project, men en brugbar plan afhænger af, at alle projektdeltagere ved, hvad de skal gøre, og hvordan det skal gøres. For at opnå dette skal planen og viden om, hvordan tingene skal udføres, kommunikeres til og forpligtes af alle involverede.

Planlægning er en rejse, ikke en opgave

For at citere den tidligere amerikanske præsident Dwight D. Eisenhower: "planlægning er alt. Planen er intet." Denne holdning er så vigtig, at den fortjener at blive gentaget i næsten enhver arbejdssammenhæng i systemprojekter. Men hvad vil det sige, at planen er intet? Hvad er meningen med planlægning, hvis resultatet er en værdiløs plan? 

Den plan, du ender med, er aldrig værdiløs, men Eisenhowers holdning handler om selve planlægningen og dens værdi sammenlignet med planen. Lad os hurtigt sammenligne, hvordan planlægning fungerer i henholdsvis længerevarende strukturerede projekter og agile/kontinuerlige projekter.

Struktureret planlægning kontra agil planlægning

I et længerevarende projekt skal din virksomhed, leverandørerne og det interne it-personale vide, hvilken forpligtelse der kræves af dem, så de kan planlægge tilgængeligheden af medarbejdere og fysiske ressourcer.

Det tager værdifuld tid at indsamle de nødvendige oplysninger for at udarbejde en plan. Med alle afhængighederne mellem ressourcer og mennesker samt leverandørernes og de interne medarbejderes forpligtelser og præstationer kan mange ting gå galt. Nogle ting vil gå galt. Derfor er planen som en forudsigelse af fremtiden forbundet med store vanskeligheder.

Dagen efter at en plan er offentliggjort, og hver dag derefter, kommer nye oplysninger frem, og der er behov for justeringer. Krav bliver droppet; leverandører leverer for sent; miljøer, testdata eller værktøjer er ikke klar i tide. Listen fortsætter. Planlægning er aldrig en engangsopgave, men en kontinuerlig — næsten daglig —aktivitet.

Uplanlagte hændelser bliver ofte betragtet som støj og får ikke megen opmærksomhed. Men senere udvikler nogle af disse mindre problemer sig til store problemer. En af udfordringerne ved vandfaldsprojekter er, at denne kontinuerlige justering kan være besværlig, fordi alle ændringer opfattes som unødvendigt pilleri. Projekter fortsætter ofte ufortrødent i håb om, at tingene vil være »i orden, når det gælder«. Men det er sjældent tilfældet, og det er blevet sagt mange gange:

Hvordan bliver et projekt et år forsinket? Én dag ad gangen.

Den agile tilgang er delvist en reaktion på frustrationen over faste eller ufleksible planer. Agilitet er det gennemprøvede alternativ til den træghed, der kendetegner besværlige, trinvise tilgange. Men betyder det, at agile projekter ikke planlægger? Nej. 

Selv i agile projekter er en vis indledende planlægning nødvendig for at strukturere arbejdet, mobilisere ressourcer og planlægge — i det mindste på et overordnet niveau — udgivelsesprocessen over de kommende måneder. Men for hver iteration og ofte fra dag til dag justeres den overordnede plan løbende for at tage højde for hændelser og nye oplysninger, der kommer frem.

Planlægning er en kontinuerlig læringsrejse, ikke en opgave med en leverance.

Testplanlægning

Indtil videre har vi set på projektplanlægning som helhed og fastslået, at det i høj grad er en kontinuerlig aktivitet. Nu fokuserer vi specifikt på planlægning af test i projekter. 

Testplanlægning minder meget om projektplanlægning – det er egentlig bare en plan i mindre skala. Testplanen skal naturligvis også integreres med den større projektplan, fordi den afhænger af andre projektaktiviteter og leverancer (og andre opgaver afhænger af testningen). Testplaner bliver ofte forstyrret, fordi disse afhængigheder ikke bliver opfyldt.

Testplaner er relativt enkle i oversigtsform. Der kan være flere aktiviteter, som afhænger af moderprojektet. Det er ofte disse, der optræder som opgaver i den større projektplan. Men aktiviteterne er fordelt på et team, som måske har en stor beholdning af testelementer, der skal planlægges og udføres test for. 

Dette detaljeringsniveau er ikke så relevant for projektlederens tidsplan og defineres og administreres normalt lokalt i testteamet.

Lad os se på nogle af kerneelementerne i din testplan.

Leverancer

Hvad er testningens leverancer?

Sikke et spørgsmål! Det er vel test specifikationerne, testene, resultaterne og rapporterne? Leverancerne er i det væsentlige indeholdt i dokumentationen, så det eneste, vi behøver bekymre os om, er at få papirarbejdet ud og sætte flueben i nogle felter. 

Men selvom denne tilgang er almindelig, er den delvist skyld i, at testning (og testere) har fået et ry for at være dyre, stive bureaukrater med begrænset værdi. For hvem læser egentlig disse omfangsrige dokumenter?

Antag, at der ikke er planer om at udarbejde testdokumentation i et agilt projekt. Det er meget sandsynligt, så hvad leverer testning egentlig i disse situationer? Hvilken værdi har testning overhovedet? Det er vel lidt sent at stille disse spørgsmål, ikke?

Når en komponent, et delsystem eller hele systemet bliver testet, er resultatet dokumentation for, hvordan systemet opfører sig i en bestemt situation eller sammenhæng. Dokumentation for systemets adfærd indsamles og samles for at blive præsenteret for interessenter (udviklere, brugere, ledere osv.), så de kan træffe en beslutning: at rette fejl, integrere en komponent, acceptere eller afvise funktionalitet, frigive eller implementere et delsystem eller hele systemet.

Testningens leverance er dokumentation for systemets adfærd, som interessenter bruger til at træffe en beslutning.

Nu er det i nogle projekter afgørende at levere testdokumentation for at registrere, hvordan en test blev afgrænset, designet, implementeret og udført. Men det er dokumentationen for systemets adfærd, der i sidste ende er det værdifulde resultat for interessenterne.

Værdien af test er det niveau af tillid, interessenterne har til at træffe beslutninger baseret på testdokumentation.

Denne dokumentation kan indsamles, opstilles i tabeller og analyseres systematisk i avancerede teststyringsløsninger og præsenteres for interessenterne i elegante grafiske formater. Eller de håndskrevne noter kan bruges af en tester til mundtligt at præsentere testforløbet for en produktejer på et standupmøde.

Uanset hvordan dokumentationen indsamles og præsenteres, er testens sidste opgave at overdrage dokumentationen.

Hvordan

Uanset projektets størrelse eller metode afhænger test af en bestemt række aktiviteter. Vi ser på en generisk proces gennem testerens (eller teamets) øjne og ser derefter på nogle af de variationer, der forekommer. 

Der findes det, man kan kalde »testaktiviteter«, og der findes »testunderstøttende« eller »logistiske« aktiviteter. For at sikre, at du inkluderer alle aktiviteter i planen, kan du med fordel bruge tabellerne nedenfor som nyttige tjeklister.

En aktivitet i tabellen ovenfor, som du måske ikke genkender så let, er feedbackaktiviteten. Du har allerede været nødt til at arbejde med dårlige krav. 

Feedback-, gennemgangs- og udfordringsaktiviteten er det sted, hvor testere efter at have gennemtænkt og modelleret et krav opdager problemer og kan bruge eksempler til at demonstrere, hvor krav mangler, er tvetydige eller selvmodsigende.

Hvis du vurderer, at kravene er dårlige, er det bestemt værd at afsætte tid til denne aktivitet.

Testlogistik

Testlogistik understøtter testaktiviteterne ovenfor. Mens den testaktivitetsliste, jeg har givet, er rimelig omfattende, varierer testlogistikken fra projekt til projekt og fra organisation til organisation. Listen nedenfor er derfor ikke komplet. I dit projekt bør du gøre dig umage med at gennemgå hver aktivitet eller afhængighed, der er nødvendig for at levere test.

Ressourcer (menneskelige, fysiske)

Vi bruger ofte ordet ressourcer om de mennesker, der arbejder på vores projekter, og for nogle føles det ikke rigtigt. Mennesker er ikke ting, men selvfølgelig menneskelige væsener. I mindre projekter kan det være muligt at bruge navne, men i større organisationer, hvor projektteams er involveret og måske endnu ikke er bemandet, er et antal ressourcer blot en kort måde at sige et antal mennesker på.

Endnu vigtigere er det, at det ikke nødvendigvis er antallet af mennesker, der tæller – det er deres evner, der virkelig betyder noget. Selvfølgelig arbejder mennesker på forskellige måder og som regel også i forskelligt tempo, så det skal du tage højde for i din planlægning.

Ud over mennesker får du på forskellige stadier brug for forskellige fysiske ressourcer, for at testen kan gennemføres. De spænder fra det helt almindelige til det meget specifikke, og hvis nogle af disse mangler, kan det true testopgaven.

Måske er du allerede så heldig at have adgang til et fuldt udstyret, administreret og dedikeret testlaboratorium. Hvis ikke, kan det være nødvendigt at specificere alt – fra fysisk plads og møbler til post-it-sedler og viskelædere – for at definere dit arbejdsmiljø.

I tabellen nedenfor er der angivet nogle typiske nødvendige ressourcer. Din liste vil uden tvivl være betydeligt anderledes. 

Når du har identificeret alle de ressourcer, der kræves for at gennemføre din plan, bør du overveje, om du har brug for yderligere aktiviteter i planen for at anskaffe dem.

Dit supportnetværk

Hvis de mennesker og kompetencer, du har brug for til at udføre testen, var under din kontrol, kunne projekter være meget enklere! Men få teams har alle de nødvendige kompetencer eller autorisation og adgang til de nødvendige fysiske ressourcer. Mange projekter bemandes og drives efter en matrixledelsesmodel. Centrale teammedlemmer refererer faktisk til ledere i andre specialiserede afdelinger, og du får kun et begrænset engagement fra dem.

Du kan få brug for at angive et bestemt antal timer pr. dag eller planlægge tidspunkter, hvor du kan få adgang til de specialiserede kompetencer ovenfor. Nogle gange bliver du bedt om at angive, hvilket serviceniveau der er acceptabelt, f.eks. at »anmodninger med høj prioritet vil blive besvaret inden for tredive minutter« og så videre.

Estimeringer

Estimering i softwareprojekter er en vanskelig disciplin. Der er skrevet meget om, hvordan estimering er vanskelig eller ligefrem umulig. Men der er behov for estimater i alle projekter, og jo større projektet er, desto mere afhænger vi af dem.

Vi har brug for estimater til at oprette en tidsplan, men problemet er, at estimering ikke giver dig nøjagtighed. Det bedste, vi nogensinde kan gøre, er at beregne en indsats eller forløbet tid med en vis grad af sikkerhed eller sandsynlighed.

Nogle betragter estimering som en sort kunst, og der findes endda en #NoEstimates-bevægelse med en betydelig tilhængerskare. Der er stor uenighed om, hvorvidt estimering nogensinde kan blive præcis nok eller overhovedet er en god praksis i softwareprojekter.

Estimering vil aldrig blive en eksakt videnskab. Men ud fra mine erfaringer er der nogle principper, som jeg føler mig tryg ved at dele:

• Krav er fejlbarlige og upræcise.
• Mennesker er mere eller mindre kompetente, samvittighedsfulde og arbejdsomme.
• Jo mindre arbejdselementet er, desto lettere er det at estimere det; opdel store opgaver i mindre enheder, hvor det er muligt, og læg estimaterne sammen til den større opgave.
• Estimering er baseret på erfaring. Hvis du ikke har nogen, så find ud af, hvor andres erfaringer er relevante og kan tilpasses.
• Dit arbejdselement er unikt, så se efter arbejdsmønstre i andre kendte situationer, hvor du har erfaring.
• Bed andre om at estimere og sammenlign. Diskussion af afvigelser afdækker forskelle i forventninger, sikkerhed og grundighed.
• Estimer den bedst mulige situation og derefter den værst mulige situation. Et godt estimat ligger et sted midt imellem.

Estimer i dag, og begynd arbejdet; i morgen og hver efterfølgende dag vil dit estimat for færdiggørelsen blive forbedret med den viden, du har opnået.

Afhængigheder, risici og antagelser

I en tidligere artikel diskuterede vi risiko og testningens rolle i risikostyring. Produktrisici handler om, hvorvidt produktet opfylder brugernes behov med hensyn til funktionelle eller tekniske krav. Her er fokus på risiciene for den faktiske leveringsplan.

Ting går galt i projekter. I din planlægningsaktivitet skal du tydeliggøre, hvilke risici for fiasko du har overvejet og taget højde for. Der er tre aspekter af dette: afhængigheder, risici og reaktioner.

Afhængigheder

Afhængigheder repræsenterer en liste over de menneskelige og fysiske ressourcer samt forgængeraktiviteter, der skal være afsluttet, for at dine planlagte aktiviteter kan lykkes og levere resultatet. 

Der er altid afhængigheder ved enhver testaktivitet, uanset om det er en test på systemniveau i stor skala eller en udforskende testsession af en funktion. Afhængigheder dækker tre hovedaspekter.

Risici

Risikoen er sandsynligheden for, at din plan mislykkes under udførelsen. Risiko handler om ting som:

• Dine estimater: Hvad kan få dine estimater til at være forkerte? At systemet er mere komplekst, fejlbehæftet, ufuldstændigt eller konstant under forandring kan alt sammen påvirke dine estimater.
• At personer ikke er tilgængelige, mangler erfaring eller kompetencer eller ikke er fuldt engagerede i din fase af projektet. Det kan være teammedlemmer eller personer i dit supportnetværk.
• Infrastruktur såsom testmiljøer, værktøjer (eller oplæring i brugen af værktøjer) eller kontorlokaler, der ikke er tilgængelige, er forberedt forkert eller er fejlbehæftede.
• At forgængeraktiviteter ikke bliver afsluttet til tiden (eller bliver opgivet, leverer delvise eller fejlbehæftede produkter eller slet ikke leverer noget).

Reaktioner

For hver af disse risici skal du vurdere sandsynligheden, konsekvensen og, hvor det er væsentligt, en passende reaktion eller forventet konsekvens. Disse reaktioner har typisk en af følgende former:

• Antagelse: Risikoen vurderes til at være tilstrækkeligt lav til at blive ignoreret eller betragtet som ubetydelig. Men den er på radaren og registreres som en antagelse (om tilgængelighed, fuldstændighed osv.)
• Tilpasning: Risikoen er væsentlig, men der er en handling, som kan reducere dens påvirkning af planen. Hvis systemet under test eksempelvis er leveret delvist og mangler funktioner, kan planen tilpasses, så der kun testes de funktioner, der er tilgængelige.
• Konsekvens: Nogle risici kan ikke indarbejdes. Hvis systemet leveres for sent, kan testen ikke begynde, før det er leveret.

Kommunikation, forpligtelse og statusrapportering

Til sidst kommer vi til et afgørende, men ofte overset aspekt af planlægningen. Du kan udarbejde en projektplan, der omfatter alle opgaver, deltagere, ressourcer, ansvarsområder, afhængigheder, tidsplaner, arbejdsindsats og omkostninger. Eller det kan være en mundtlig forståelse mellem medlemmerne af et agilt team. 

Uanset hvad skal planen kommunikeres effektivt til alle, så alle ved, hvad der kræves, og hvornår det skal ske.

En aftalt plan er en kontrakt mellem deltagerne. Hvis en teamleder godkender en plan, er det implicit eller eksplicit en forpligtelse til at opfylde teamets del af aftalen.

Planen er en kontrakt mellem deltagerne.

I mindre formelle projekter er der måske slet ingen skriftlig plan eller nogen forpligtelser. Under disse omstændigheder er planen en løbende samtale mellem teamets medlemmer. Teamet mødes dagligt, og de aktive opgaver i planen drøftes i realtid. Hvad arbejder folk på? Går fremdriften som forventet? Hvilke problemer oplever folk? Hvilke problemer blokerer fremdriften?

I alle projekter er formålet med fremdriftsrapportering todelt. Det er naturligvis nødvendigt at kommunikere, hvor alle befinder sig i forhold til deres aktuelle projektaktiviteter. Men fremdriftsrapporten er også en løbende, periodisk kontrol af, at fremdriften kan opretholdes, og en verificering af, at man kan stole på deltagernes engagement.

Tak, fordi du læste med. Vi ses næste gang til… ja, du gættede det, udførelsen!

Tilmeld dig nyhedsbrevet fra The QA Lead for at få besked, når nye dele af serien bliver udgivet. Disse indlæg er uddrag fra Pauls kursus i ledelse inden for test, som vi varmt anbefaler, hvis du ønsker at gå mere i dybden med dette og andre emner. Hvis du gør det, skal du bruge vores eksklusive kuponkode QALEADOFFER for at få $60 i rabat på kursets fulde pris!