Ledelse af test. et whitepaper om at holde styring på testforløb. Henrik Timm

Transkript

1 Ledelse af test et whitepaper om at holde styring på testforløb af Henrik Timm

2 Indholdsfortegnelse 1 INDLEDNING FORMÅL UDFORDRINGER TESTPOLITIK OG STRATEGI TEST FORLØB VÆR I KONTROL TESTVÆRKTØJ TEST UDFØRELSE MILJØVERIFICERING / SMOKETEST COCKPIT - EN VISUEL STATUS STATUS AFRAPPORTERING KVALITET HVAD ER NÆSTE SKRIDT OM FORFATTERNE Status: live Side 2 af 13

3 1 Indledning Igennem de senere år er det blevet mere og mere udbredt, at behandle test som en selvstændig disciplin i projekter, programmer og som organisatoriske enheder. Flere virksomheder har i mange år haft afdelinger, som står for testen af nye produkter eller løsninger, inden de tages i brug, blandt andet har det været fremherskende i den farmaceutiske verden og i den finansielle sektor. I dag tages test meget seriøst i IT-projekter, da det behandles på lige linje med projektledelse og programledelse der er tilmed fremkommet flere certificeringsformer, hvor ISTQB 1 er en af de ledende. Den stigende fokusering på test skal ses i en sammenhæng med et ønske om at levere et produkt eller løsning med bedst mulige kvalitet, samt kunne dokumentere/vise overfor brugerne at det er en god løsning. Tænk blot på IKEA, der har en stol udstillet i en montre, som konstant bliver presset ned af en maskine, for at simulere at personer skiftevis sætter sig og rejser sig fra stolen. Dette er en test, som giver kunderne en oplevelse af god brugskvalitet. Kort sagt skal test bidrage med viden om løsningen/produktet, således at de forretningsmæssige konsekvenser ved at ibrugtage løsningen/produktet kan vurderes. Dog kan test resultater ikke stå alene, men bør suppleres med andre forretningsmæssige overvejelser også. 1.1 Formål Formålet med dette whitepaper er at give inspiration til, hvorledes man med fordel kan planlægge, styre og afrapportere på et test forløb - enten som projektleder eller som testleder. Dette whitepaper skaber endvidere indsigt i de områder, som en stærk testleder eller projektleder bør sikre sig, at testen omhandler, for at undgå at testen bliver for detaljeret og dermed kun anvendelig for en begrænset modtager kreds. 1 ISTQB er en forkortelse for International Software Testing Qualifications Board Status: live Side 3 af 13

4 1.2 Udfordringer Når vi har arbejdet som projektledere og test managere har vi ofte hørt udsagn som Testen er bagud, Testen finder for mange fejl eller... det kan I ikke teste endnu. Vores påstand er, at det ikke er testen, som er problemet, men at testen viser rigets tilstand som f.eks. at leverancen har en ringe kvalitet, eller måske slet ikke er parat til at blive testet endnu. Ofte starter testen med en forsinkelse på grund af, at det undervurderes, hvor lang tid det tager at skabe et testmiljø. Typisk startes arbejdet med den endelige konfigurering og opsætning først lige inden testen skal begynde. Herved bliver udviklernes evne til at overholde de aftalte standarder testet, samtidig med at den endelige konfigurering også sættes op. Ofte har de forskellige udviklere benyttet deres egne udviklingsmiljøer, som de har tilpasset personligt for at få deres egne dele til at virke. Som test manager kan det ofte være en udfordring, at skulle afrapportere fra en test, da man risikerer, at afrapporteringen ikke lever op til den forventning som projektlederen har, eller som projektlederen har givet til interessenterne. Dette betyder, at man som test manager vil havne i et spændings felt mellem projektlederen og interessenterne. 1.3 Testpolitik og strategi Såfremt en virksomhed ønsker, at fokuserer på test på en professionel facon, kan der hentes meget inspiration fra, hvorledes projektledelse anskues med modeller, faser og metoder. Således at testen planlægges som en aktivitet eller fase i et projekt, ligesom udviklingsaktiviteter. Den efterfølgende figur viser vores forslag til de vigtigste områder som bør gennemtænkes: Status: live Side 4 af 13

5 Figuren viser, at der skal skabes sammenhæng mellem virksomhedens testpolitik og teststrategi som benyttes i de enkelte projekter, da der derved skabes sammenhæng mellem strategien i virksomheden og i projektet. Denne strukturering vil støtte op om gennemførelsen af testen i de enkelte projekter, da testen dermed udspringer af virksomhedens overordnede test politik. Det vil samtidig bidrage til at projektet støtter op om de gevinster som er tænkt ind i virksomhedens strategi. 1.4 Test forløb Pyramidefiguren kan omsættes til følgende overordnede test forløb: Status: live Side 5 af 13

6 Figuren viser hvorledes test manageren bør tage afsæt i virksomhedens test politik, når planlægning skal ske. I planlægning udarbejdes projektets teststrategi og testprojektplaner. Samtidig med planlægning, kan der begyndes at blive udarbejdet testdrejebøger (testcases) når dele af test scopet (omfanget) er ved at være fastlagt. Efterfølgende eksekveres de forskellige testdrejebøger. Dette kan med fordel opdeles i forskellige testfaser afhængig af, hvilken type af test, der skal gennemføres. Undervejs skal der ske en rapportering, således at interessenterne kender til den aktuelle status. Tidspunktet, som rapporteringen skal begynde på, bør aftales fra starten af testen, således at det startes, når det giver mening. Som afslutning bør der ske en afrapportering på testen. Afrapporteringen afhænger af hvorledes testen er organiseret, f.eks. kan det være direkte fra Testlederen til projektlederen og styregruppen. Status: live Side 6 af 13

7 2 Vær i kontrol Når det handler om test, er det meget vigtigt at have styr på dokumentationen, således at man kan dokumentere sin test. Dette er vigtigt, da man ofte vil blive mødt med spørgsmål som: o o o o Hvad er testet? Hvorfor er det godt? Hvad er fejlbehæftet? Er det hele testet? Den kontrollerede test bør tage udgangspunkt i en teststrategi - og en testprojektplan. Disse dokumenter skal fungere som det dokumenterede aftalegrundlag for, hvad der testes og hvilke forudsætninger, der skal være på plads, inden testen kan starte. Den gode teststrategi og plan bør bl.a. indeholde: Det er en god ide, at beskrive selve testforløbet, og hvilke faser, der skal gennemløbes, samt hvilke former for test der skal gennemføres, således at forventningerne til testen er på plads fra starten af. De typiske faser i et forløb kunne være en Funktions test (FIT), system integrations test (SIT) eller bruger/kunde accept test (UAT). Mens typer af test kunne være risiko-baseret test, bug test, eksplorativ test osv. Dette er meget vigtigt også at overveje og dokumentere, da en udtømmende test normalt anses for umulig at gennemføre. Da en udtømmende test ofte vil være for omfattende og dermed for dyr i forhold til den gevinst der opnås. De forskellige typer af test vil have indflydelse på, Testscope Testteknikker/testtyper Entry & Exit kriterier Tidsplan Ressourceoversigt og særlige ressourcekrav Særlige uddannelses behov Rolle fordeling Testværktøj Defecthåndtering (Fejlhåndtering) Baseline af dokumentation Versioner af applikationer/systemer Krav til testmiljø og Testdata Testdata Risikostyring hvorledes testen bedst udføres og planlægges, samt på hvilke typer af testcases, der skal benyttes. Status: live Side 7 af 13

8 Desuden bør det fastlægges, hvem som rent faktisk ejer de enkelte testfaser og testscope, da dette kan være forskelligt. F.eks. vil en integrations test og system integrations test ofte være ejet af projektet/programmet, mens en kundetest vil være ejet af kunden. Præciseringen af ejerskabet vil hjælpe med at synliggøre, hvem det er, som kan træffe beslutninger - og bør gøre det. Efter vores opfattelse er dette ofte ikke ordentligt præciseret, hvilket medfører at IT-folk ofte påtager sig et for stort ansvar i forbindelse med test, og dermed bliver involveret i beslutninger, som komplicerer testforløbet. Flere og flere virksomheder har i dag dokumenteret deres egen testpolitik og metode (- strategi) på lige linje med f.eks. deres projektmodel. Derfor er det godt at orientere sig om der findes en testpolitik (- strategi) inden testen planlægges, og i givet fald sætte sig ind i den, da dette kan være en stor hjælp for gennemførelse af testen i henhold til de gængse metoder, som benyttes i virksomheden. Af teststrategien skal også fremgå evt. afvigelser fra test politikken, og af testplanen skal fremgå eventuelle afvigelser fra den test strategi, som måtte findes. Teststrategien og testtidsplanen (- og planen) skal til sidst gennemgås og godkendes af de vigtigste interessenter som f.eks. projektlederen, programlederen, forretningsansvarlige, miljøansvarlige og leverandører osv. Dette er meget vigtigt, da forventningerne til testen således er afstemte, inden testen startes. 2.1 Testværktøj Flere og flere virksomheder benytter et system/værktøj til have styr på deres testcases og eksekveringen af disse, samt på de fejl (defects) som findes. Fordelen ved dette er, at alt dokumenteres fælles, samt at det er let at have et fælles overblik over test forløbet. Et af de mest udbredte værktøjer er Quality Center fra HP (tidligere kaldet Testdirector). Forslag til agenda på kickoff møde: Tidsplan Scope Hvem tester hvad Håndtering af fejl (Defects) Evt. en forretningsmæssig gennemgang af testen Status: live Side 8 af 13

9 2.2 Test udførelse Umiddelbart før et testforløb skal starte, bør afholdes et fælles kickoff møde (opstartsmøde) for alle de involverede testere og øvrige interessenter, således at der sikres et fælles afsæt, når testen begynder. Dette er meget vigtigt, da et testforløb ofte er et meget hektisk forløb, hvor man som testleder eller projektleder virkelig får prøvet sine ledelses evner af, når man både skal holde styr på testerne, fejl (defects), styre afviklingen, samt kunne tilfredsstille ledelsen med den ønskede status/afrapportering. Det er med andre ord meget vigtigt, at have forberedt deltagerne mest muligt, således at de spørgsmål, der måtte være, eller den uddannelse/træning, som der skal ske, er gennemført inden testen starter, da det vil bidrage til et mere roligt forløb. Ofte er det også vigtigt, at fortælle den enkelte tester præcis, hvad han/hun skal teste de første par dage, da testeren så føler sig mere sikker på, hvad der skal laves. Samtidig med at det gør den enkelte mere tryg i starten. 2.3 Miljøverificering / smoketest Afhængig af testens omfang bør det overvejes, om der skal udføres en verificering af testmiljøet inden den egentlige test påbegyndes. Flere steder kaldes dette for en smoketest eller sanity check. Dette skal gennemføres som en simpel test, hvor der tjekkes, om de ønskede applikationer/systemer og interfaces er til rådighed, samt om deres basisfunktionalitet fungerer. Dette sikrer, at der ikke spildes tid ved, at igangsætte en test på et grundlag, som ikke er i orden. Samt skaber en mulighed for, at vurdere, om det reelt er muligt, at gennemføre hele det planlagte testscope. 2.4 Cockpit - en visuel status Testaktiviteter får ofte stor opmærksomhed fra både projektets interessenter og fra organisationen, da testen ofte er den første rigtige indikation af, om leverancen er brugbar eller ej. Derfor bør man som test manager/projektleder overveje, hvorledes man synliggør status på testen. Herved kan man også undgå, at de enkelte testere bliver udspurgt at interessenterne. En måde at håndtere dette på er at skabe en form for cockpit, som på en enkel facon viser, hvorledes afviklingen af testen De mange instrumenter i cockpittet på et fly bruges dels til at overvåge selve flyvningen (retning, højde, fart osv.), dels til at overvåge tilstandene i de forskellige systemer der findes i flyet (motor, elektrisk system osv.). Status: live Side 9 af 13

10 foregår. Herved bliver det synligt for alle de implicerende deltagere og nysgerrige interessenter, hvad der testes - og hvorledes det går. Cockpittet bør vise følgende: Vigtig information kendte fejl og udfordringer, som berører flere testere Tidsplan aktuelle deadlines Afviklingen af testsets f.eks. en burndown graf Fravær mangler der nogle testere (sygdom, andre opgaver etc.) Udviklingen i fejl (Defects) f.eks. et søjle diagram på dagsbasis Kontaktperson/telefonnumre på support til problemer med testmiljøet En motiverende kommentar til alle deltagerne - dette virker ofte stimulerende, samt sender signaler til alle øvrige, som ser cockpittet. Cockpittet bør opdateres dagligt ved f.eks. et kort stand-up møde med alle testere. Mødet bør ikke tage mere end min., da det ellers bliver for detaljeret og svært at holde dagligt. 2.5 Status Udover cockpittet bør det også aftales, hvorledes der fremlægges en skriftlig status fra testen. Er det hver dag eller en gang om ugen? Hvad skal den indeholde? Hvem skal modtage den? Det er her vigtigt at aftale, hvem som udarbejder status og hvem som er modtagerne. Dette sikrer, at det er testlederen eller projektlederen, som styrer Forslag til indhold i status: Fremdrifts måling på antal testcases i forhold til scope Udviklingen i defects Holder tidsplanen? Større udfordringer Kort kommentar om "mavefornemmelse" for afviklingen testen, og at det er dem som giver den præcise og formelle kommunikation om, hvorledes testen performer. Det medfører ofte støj", hvis status rapporteringen ikke gives i forhold til planen for testen, da andre ofte hurtigt drager deres egne konklusioner om, hvorvidt testen er foran eller bagud, eller går godt eller skidt. Status: live Side 10 af 13

11 2.6 Afrapportering Når testen er gennemført, er det vigtigt at få afsluttet den med en formel afrapportering, så hurtigt som muligt. Dette skal gøres for at markere, at testen er slut, således at der ikke er tvivl herom. Det kan gøres ved at udarbejde en rapport, som tager udgangspunkt i testplanen. Rapporten bør præsenteres på et møde med de interessenter, som var med til at godkende testplanen. Det kunne være f.eks. projektlederen, programlederen, forretningsansvarlige, miljøansvarlige og leverandører osv. Ofte har en sådan rapport det med at blive meget stor, da der er mange vigtige informationer, som man ønsker at dokumentere. Derfor er det en god ide, at første del af rapporten indeholder et kort resume (executive summary) af test forløbet, en konklusion samt anbefalinger. I den efterfølgende del kan detaljeringsniveauet være større på de områder/emner som kræver mere beskrivelse. Såfremt det er muligt er en det en god ide, at den første del også indeholder en visuel gengivelse af resultatet på nogle aftalte hovedområder. Dette kan vises ved at bruge trafiklys farverne grøn- gul og rød eller ved bruge smileys ud fra nogle givne emner. Hovedområderne kunne f.eks. være: Overholdelse af Entry og Exit kriterierne Testens dækningsgrad af scopet Defects Overordnet vurdering af testen resultat/kvalitet (mavefornemmelsen hos testlederen) Afrapporteringen er meget vigtigt at få gjort, da den er medvirkende til at der bliver "slået en streg i sandet", der dokumenterer resultatet, således at ledelsen kan tage beslutning om det næste skridt. Dette kunne f.eks. være i relation til, om en leverandør har overholdt kontrakten på baggrund af testens resultat, eller om der skal planlægges en ny test osv. Den gode test rapport bør indeholde: Vurdering af Entry & Exit kriterierne Oversigt over hvad der er testet og ikke testet Liste over kritiske defects og vurdering af deres forretningsmæssige konsekvenser Dokumentation af baseline og hvilke versioner af applikationer/systemer som der er testet på Evt. afvigelser fra testplanen Testlederens anbefaling til det videre forløb Status: live Side 11 af 13

12 3 Kvalitet Når man tester, er det altid vigtigt at gøre det med den bedst mulige kvalitet, for at opnå det bedst mulige resultat. En måde at tænke kvalitet ind i test på, kan gøres ved følgende tiltag: Brug skabeloner til testcases og fejlbeskrivelser. Brug skabeloner til planlægning og afrapportering Dokumenter processerne og sørg for at sikre, at de benyttes Udarbejd vejledninger og kvikguides Brug reviews for at sikre, at dokumenter og testcases ikke er skrevet på en indforstået facon Brug tjeklister med punkter, som skal huskes til f.eks. planlægning, kick off og testafvikling Evaluer forløbet og opdater skabeloner, dokumenter og tjeklisterne. Desuden er det en stor fordel at benytte et testværktøj til at håndtere testcases og fejl. Dette giver mulighed for at få et godt overblik, foruden at det vil begrænse de enkelte deltageres mulighed for at gøre tingene på deres egen måde undervejs. Dette er meget vigtigt, da der typisk er mange deltagere i et testforløb. Det kan ofte være nødvendigt at gå tilbage til tidligere afviklede testforløb. Derfor bør testen være dokumenteret ensartet og være meget struktureret. 4 Hvad er næste skridt Hvis du er interesseret I at diskutere testledelse eller få input til, hvad vi kan gøre for din virksomhed, er du velkommen til at kontakte Henrik Timm for et uforpligtende møde. Status: live Side 12 af 13

13 5 Om forfatteren Henrik Timm, Partner i Peak Consulting Group Henrik har en omfattende erfaring indenfor programstyring, projektstyring og kvalitetsledelse. Henrik har en baggrund som projektleder/programleder/teamleder bla. hos SDC, Banedanmark, Rigspolitiet og hos Dong Energy. Henrik er god til formidling på alle organisatoriske niveauer og har en god evne til at skabe samarbejde mellem systemudvikling og forretning og deres processer Henrik er uddannet Cand Merc. samt har en samfundsvidenskabelig basisuddannelse fra RUC. Henrik er certificeret i IPMA og er desuden IPMA assessor. Henrik er certificeret i Leadership Coaching, PRINCE2, MSP og ISTQB. tel ht@peakconsulting.dk Om Peak Consulting Group Peak Consulting Group er etableret i marts 2006, og er management konsulentvirksomhed, med fokus på portefølje-, program-, projektledelse og kvalitetsledelse. Peak danner sammen med IT virksomheden Asseco Danmark og offshore selskabet CodeConnexion, Asseco Northern Europe, som er den nordeuropæiske gren af Asseco Group. Vores samarbejde samt Internationale vidensnetværk muliggør, at vi kan tilbyde en bred vifte af kompetencer med omdrejningspunkt i Best Practice inden for portefølje-, program-, projekt- og kvalitetsledelse. Peak er den eneste virksomhed i Skandinavien der er godkendt til at levere både rådgivning (ACO) og undervisning (ATO) i P3M3, PRINCE2 og MSP Status: live Side 13 af 13