Test rapportage Waarom eigenlijk?

Transcriptie

1 Testrapportage Boodschappers van de koning? Test rapportage Waarom eigenlijk? TestNet voorjaarsevenement 2015 Jurian van de Laar Jurian van de 30 april

2 Jurian van de Laar 2 30 april

3 Agenda 3 30 april

4 Waarom test rapportage? A) Dat is een verplichte activiteit in ons testproces B) Om te laten zien dat ik goed getest heb C) Om het management inzicht te geven in de kwaliteit van het produkt D) Het testrapport is een vrijgave advies E) Het testrapport is bewijsvoering dat de requirements zijn afgedekt 4 30 april

5 Waar draait het om? Bewijs Feedback geven Status Voortgang Communicatie 5 30 april

6 Waar gaat het mis? Korten bondig? Samenvatting? Grafieken? Go/ No Go? Wat vertel je wel en Wat vertel je niet Interpretatie Interpretatie Interpretatie 6 30 april

7 Mijn werk 7 30 april

8 Mijn functie: Test Lead Image Chain Cluster Verantwoordelijkheden: Definiëren risk based test strategy Test Levels, Regulering Test lead in een project Test aanpak en implementatie Afstemming met Systeem Testers Test verbetering Test competentie 8 30 april

9 R&D Organisatie Validatie Systeem Ontwerp En Architectuur Systeem Integratie, Systeem Test En Verificatie Engineering Image Chain Cluster Unit 1 Unit 2 Unit april

10 Testen in het medisch domein De klant is koning de auditor ook! Bron: Wall Street Journal Bron: Eindhovens Dagblad april

11 Engineering Perspectief Auditor Perspectief Vertrouwen opbouwen Ontwikkelaar: het werkt Tester: het werkt niet Code reviews Unit testing Geautomatiseerde testen Code coverage meten Je kunt niet alles testen (risico / technieken) Bewijslast leveren ( evidence ) Formele documentatie (records) Geen test zonder specificatie Verificatie / Validatie Dekking = test per requirement Alle testen moeten slagen Volgorde autorisatie belangrijk april

12 Waarom een test strategie? Identificeren test levels Afstemming (ook organisatorisch) tussen levels Focus verandert van onder naar boven in de V Verticaal (feature based) werken Business doelen Generieke risico s Test Beleid Test Strategie Test doelen Blauwdruk Projecten Master Test Plan Bron: Improve Quality Services april

13 Test strategie (2015) User Needs Validation System Requirements System Design Verification System Integration Test System level Evidence (auditable) Unit specifications Unit test specifications Unit test reports Confidence UTS = Evidence Engineering level april

14 Hoe ziet een test rapport er eigenlijk uit? Veel tekst? Veel details? Tabellen? Plaatjes? Trends? april

15 Een tabel? Test Item High Priority Medium Priority Low Priority Total Totals Twee toepassingen: Open defects per test item / sub systeem Nieuw gevonden defects afgelopen week / testrun april Bron: Improve Quality Services

16 Een grafiek? Nieuwe defects Opgelost Open wk1 wk2 wk3 wk4 wk5 wk6 wk7 wk8 wk9 wk10 wk april Bron: Improve Quality Services

17 Defects per test uur en per prioriteit Defects / test hour 3 2,5 2 1,5 D C B A 1 0,5 0 wk1 wk2 wk3 wk4 wk5 wk6 wk7 wk8 wk9 wk10 wk april Bron: Improve Quality Services

18 Gewogen defects Prioriteit A = 1 Prioriteit B = 0,5 Prioriteit C = 0, wk 1 wk 2 wk 3 wk 4 wk 5 wk 6 wk 7 Priority 1 Priority 2 Priority april Bron: Improve Quality Services

19 Test rapportage: 10 do s en don ts 1. Dekkingsgraad van specificatie (requirements coverage) april Presentatie Michael Bolton (EuroSTAR 2014)

20 Test rapportage: 10 do s en don ts 1. Dekkingsgraad van specificatie (requirements coverage) 2. Aantal testgevallen (uitgevoerd / passed / failed) 3. Geautomatiseerde testen april Workshop met AslakHellesøy (EuroSTAR 2014)

21 Test rapportage: 10 do s en don ts 1. Dekkingsgraad van specificatie (requirements coverage) 2. Aantal testgevallen (uitgevoerd / passed / failed) 3. Geautomatiseerde testen 4. Dekkingsgraad van de software (code coverage) 5. Aantal defects / per getest uur / met prioriteiten 6. Produkt risico s (Prisma, Risk Poker ) Probability Damage april Bron: Improve Quality Services PRISMA

22 Test rapportage: 10 do s en don ts 1. Dekkingsgraad van specificatie (requirements coverage) 2. Aantal testgevallen (uitgevoerd / passed / failed) 3. Geautomatiseerde testen 4. Dekkingsgraad van de software (code coverage) 5. Aantal defects / per getest uur / met prioriteiten 6. Produkt risico s (Prisma, Risk Poker ) Probability Damage april Bron: Improve Quality Services PRISMA

23 Test rapportage: 10 do s en don ts 1. Dekkingsgraad van specificatie (requirements coverage) 2. Aantal testgevallen (uitgevoerd / passed / failed) 3. Geautomatiseerde testen 4. Dekkingsgraad van de software (code coverage) 5. Aantal defects / per getest uur / met prioriteiten 6. Produkt risico s (Prisma, Risk Poker ) 7. Grafieken en trends april

24 Test rapportage: 10 do s en don ts 1. Dekkingsgraad van specificatie (requirements coverage) 2. Aantal testgevallen (uitgevoerd / passed / failed) 3. Geautomatiseerde testen 4. Dekkingsgraad van de software (code coverage) 5. Aantal defects / per getest uur / met prioriteiten 6. Produkt risico s (Prisma, Risk Poker ) 7. Grafieken en trends 8. Test aspecten (mindmap) Bron: Rapid Software Testing Bron: vscomputer.wordpress.com/ april

25 Test rapportage: 10 do s en don ts 1. Dekkingsgraad van specificatie (requirements coverage) 2. Aantal testgevallen (uitgevoerd / passed / failed) 3. Geautomatiseerde testen 4. Dekkingsgraad van de software (code coverage) 5. Aantal defects / per getest uur / met prioriteiten 6. Produkt risico s (Prisma, Risk Poker ) 7. Grafieken en trends 8. Test aspecten (mindmap, SFDEPOT ) 9. Exploratory testing 10. Testverhaal (test level, confidence/evidence) april

26 Conclusies Geen silver bullet, Geen One Size Fits All : Maatwerk! Test strategie helpt Diversiteit stakeholders (bijv. in gereguleerde omgeving) Verschillen per test level Allocatie van test automatisering Expliciet maken van testbasis / mindmap Enige vorm van dekking (coverage) Confidence / Evidence Feature based Communicatie Praatplaat Visueel maken Trends Risico s / Mindmap Verwachtingsmanagement april

27 april

28 28 30 april