Test i a gile projekter projekterfaringer fra Thomas Kauders,

1. Test i agile projekter • projekterfaringer fra Thomas Kauders, Sr. Test Manager og Quality Delivery Manager

2. Om mig

3. Hvad koster en Program Test Manager? 9 mndr x 140 timer x 1000,- kr = 1.260.000 kr,- • Hvorfor vil man betale disse penge? • Hvad får man for disse penge – hvad er værdien? • Hvad er ”kernen” i testledelse og test?

4. Hvorfor vil man betale disse penge? Der er behov for test, fordi • Det er dyrt at være usikker på produktets kvalitet, da • negative overraskelser i produktion og quick fixes er tit omkostningsfulde • Der er dyrt at have fejl i produktet, da • fejl forsinker aflevering • medfører fejl i produktion og relaterede forretningsprocesser (fejlregistrering, fejlfakrurering, kundesiv) Fejl opstår i alle produkter, også med de beste udviklerressourcer, da det er menneskeligt at fejle

5. Hvad får man for disse penge – hvad er værdien? Værdien af test kommer af • Forudsigelse af produktets kvalitet • på basis af målbare og operationaliserede acceptkriterier samt enighed i fortokninger af krav • Færre fejl i produktet • hurtigere afleveringer ved færre fejlrettelser undervejs • ingen kritiske fejl i produktion

6. Hvad er testens mål? Proaktive • 1 Definere produktets acceptkriterier gennem konsesubaseret dialog mellem interessanter Reaktive • 2 Finde de væsentligste for kunden fejl • 3 Understøtte process for hurtig rettelse af defekter • 4 Informere interesenter om produktets kvalitet (=i hvilket grad acceptkriterier er opfyldt), så der kan træffes en beslutning om release på de mest faktuelle grundlag TM rolle er at sikre opnåelse af disse mål

7. Hvordan opnår vi disse mål? 1 Definere produktets acceptkriterier gennem konsesubaseret dialog mellem interessanter

8. Produktet – det handler om viden 1 • Softwareudvikling handler om viden • En destillationsprocess hvor erfaring og viden udkrystalliseres til et produkt • Viden kommer fra mange steder/afdelinger/ • interessenter

9. Viden fra forskellige brugere/grupper/interessanter 1 • Viden ”bor” og er uadskillelig fra de grupper som benytter sig af denne viden. • Udenfor disse grupper er viden blot informationer som er værdiløse • Grupperne kaldes ”Communities of Practice” • Under softwareudvikling formidler forskellige grupper af mennesker deres viden til hinanden for at produktificere det • Indbyrdes har gruppen fællse sprog, forståelse, mål • Kommunikation (vidensudveksling) er et problem mellem grupper • God vidensudveksling kræver • Brokere; mennesker med et ben i hver lejr • Objekter – fysiske artifakter at samles om at fortolke • Fejl opstår som følge af (mangende) interaktioner mellem CoPs

10. Hvad er fejlkilderne? 1 • Kan mitigeres – derfor er det vigtigt at Definere produktets acceptkriterier gennem konsesubaseret dialog mellem interessanter

11. Definere målbare accept/exit kriterier 1 Hvorfor? • Testens rolle er at måle om produktet lever op til aftalte acceptkriterier – i det daglige kaldet krav. • Men krav er amorfe er op til fortolkning. • En testcase er en fortolkning af kravet OG den er altid binær – Ja/Nej - PASS/FAIL • Et testsæt kan således entydigt afgrænse produktet / leverancen. Når alle testcases i testsættet er PASSed = produktet klar. • KUN testen kan definere entydige exit kriterier. • Hvis udviklere kender ExpectedResult på forhånd kan de kode efter dem og fejl kan forebygges! Testcase/testset = accept kriterier Krav Testsæt

12. Definere målbare accept/exit kriterier 1 • Opdelig af et system i ikke overlappende dele P1 P2 P3 P4 P5 P6 P7 • For at gøre systemet testbart skal det opdeles i partitioner. En partition er et levertbart systemkomponent, modul eller opgave,

13. Definere målbare accept/exit kriterier 1 Eksempler på hvordan jeg har løst opgaven: Ved at partitionere systemet i leverbare moduler kan jeg måle 0-100% levering af dele af systemet. Ved at udarbejde et testsæt ALTID med sporing til krav. Jeg gør testen målbar ved at hver testcase er udformet som et JA/NEJ spørgsmål og har ALTID et Expectedresult (Forventet resultat) På den måde kan du måle om kravet/kravene er opfyldt når testcasen er PASSed. TCs behøver ikke at være mange / detaljerede – men de skal ALTID have ExpectedResult

14. Definere målbare accept/exit kriterier 1 Ved at udarbejde et testsæt ALTID med sporing til krav gør jeg mine krav målbare.

15. Definere målbare accept/exit kriterier 1 Jeg gør testen målbar ved at hver testcase er udformet som et JA/NEJ spørgsmål og har ALTID et Expectedresult (Forventet resultat) TCsbehøver ikke at være mange / detaljerede – men de skal ALTID have ExpectedResult

16. Definere målbare accept/exit kriterier 1 The Agile twist Krav = User Story User Stories – nedbrydes i et antal PBI-er. For hver PBI udarbejdes et antal TBIer med action og expected result. Et PBI fortolker User Story Under Sprint planning udvælges færdige, elevante PBIer og TBI´er Sprint planning = PBI planning + TBI planning

17. Definere målbare accept/exit kriterier 1 Hvorfor? Hvordan? • Inden fejlen opstår • (i teststrategier, testplaner) og testcases • Partitionering i leverancer • Et fuld test sæt = Alle krav fortolket som Ja/Nej spørgsmål

18. Skabe konsensus om accept kriterier 1 Buy In; Forhåndsaccept af testcases som exit kriterier; CoP fælles kravfortolkning; give-and-take; Forhandling INDEN udvikling! Accept-kriterie drevet udvikling

19. Hvordan opnår vi disse mål? 2 Finde de væsentligste for kunden fejl

20. Organisere test at finde afvigelser fra disse (fejl) 2 • Inden fejlen opstår • i teststrategier, testplaner og testcases • Efter fejlen er opstået • i defekthåndtering

21. Hvordan opnår vi disse mål? 3 3 Understøtte process for hurtig rettelse af defekter

22. Fejl har som regel flere kilder (som sidder geografisk spredt) Defecttracking Defecttriageborard Personlig ansvar – assign defekter til navngiven person • Skabe- og holde kommunikationskanaler åbne for at forebygge- og løse fundne fejl 3

23. Hvordan opnår vi disse mål? Informere interesenter om produktets kvalitet (=i hvilket grad acceptkriterier er opfyldt), så der kan træffes en beslutning om release på de mest faktuelle grundlag

24. Inden fejlen opstår • i teststrategier, testplaner og testcases • Efter fejlen er opstået • i defekthåndtering • Informere alle løbende om pass/fail status for opfyldelse af de enkelte acceptkriterier 4

25. ----

26. Tiltag du bør kigge efter Som kunde bør du kigge efter at din PTM har fokus på følgende opgaver: • Partitionering • Kravsporing • Testplan - tidsplan • TestDesign/TestCases • Rapportering, KPI / synliggørelse / kommunikation • Defekthåndtering / Fokusering

27. Eksempler fra mine projekter Partitionering • Opdelig af et system i ikke overlappende dele P7 P1 P2 P3 P4 P5 P6 P7 • For at gøre systemet testbart skal det opdeles i partitioner. En partition er et levertbart systemkomponent, modul eller opgave,

28. Eksempler fra mine projekter Kravsporing • Testens formål at påvise afvigelser ift krav. • Krav kan være nedskrevne, strukturerede; eller ikke • Uanset skal testcases spores til krav • Når TCs er PASSED = kravet opfyldt

29. Eksempler fra mine projekter Testplanlægning • Behøver ikke at være en testplan i word... • Skal ”tjene” projektet - levere informationer på rette tidspunkt [Vis fil]

30. Eksempler fra mine projekter Testdesign / Testcases • Testcases = acceptkriterier • Deres formål er at operationalisere de oprindelige krav • Ved at nedbryde dem til binære spørgsmål: PASS / FAIL:: • NB: Uden konsensus om TC ingen konsensus om acceptkriterier

31. Eksempler fra mine projekter KPI / Rapportering • Hvad man måler det man optimerer • Færdiggørelsesgrad • Gns. Fejlretningstid • Antal åbne defekter per person(!) • Det handler om at synliggøre for relevante • beslutningstagere i hele organisationen hvad • status er og hvad det betyder for dem • Test er projektets øjne og ører: Rapporteringen fortæller • hvor er vi i forhold til vores mål (acceptkriterier). • NB: Uden konsensus om TC ingen konsensus om acceptkriterier

32. Eksempler fra mine projekter Defekthåndtering • Defekthåndtering handler om at rapportere kontrollere fremdrift på væsentlige fejl • KPI: • Gns. Fejlretningstid; Gns. liggetid per person; Antal defekter hos person • Det handler om at få mennesker at tale sammen og samarbejde.