Test (i Agile projekter) Teori og praksis fra mine projekter

1. Test (i Agile projekter) Teori og praksis fra mine projekter

2. Om mig

3. Hvad koster en PTM? 9 mdr x 140 timer x 1000,- kr = 1.260.000,- • Hvorfor er mennesker villige at betale så meget? • Hvorfor er det jeg gør så værdifuldt? • Hvad er ”kernen” i testledelse og test? Hvordan kan test bedst bidrage på et projekt?

4. Hvorfor er der behov for test?

5. 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

6. Hvad har test med det at gøre?? • Det er TMs rolle at organisere en proces som eliminerer / mitigerer disse fejlkilder i kommunikationsflowet ved at:

7. Hvad er fejlkilderne? • Kan mitigeres

8. Det handler om viden • Softwareudvikling handler om viden • En destillationsprocess hvor erfaring og viden udkrystalliseres til et produkt

9. Det handler om viden • 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 – fyfsike artifakter at samles om at fortolke • Fejl opstår når vidensudvekslingen (kommunkationen) går i stå

10. Definere målbare accept/exit kriterier 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! Krav Testsæt

11. Definere målbare accept/exit kriterier 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

12. Definere målbare accept/exit kriterier • 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 Ved at udarbejde et testsæt ALTID med sporing til krav gør jeg mine krav målbare.

14. Definere målbare accept/exit kriterier 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

15. Definere målbare accept/exit kriterier 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

16. Definere målbare accept/exit kriterier 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

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

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

19. 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

20. 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

21. Hvad har test med det at gøre?? • Inden fejlen opstår • i teststrategier, testplaner og testcases • Efter fejlen er opstået • i defekthåndtering

22. Hvilke resultater bør en TM levere for disse penge? • Afkorte / minimere spildtid i projektet; forkorte projektleveringstiden Ved at

23. 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

24. 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,

25. 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

26. 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]

27. 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

28. 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

29. 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.