Test rapportage Waarom eigenlijk?

‘Testrapportage – Boodschappers van de koning’?

Test rapportage Waarom eigenlijk? TestNet voorjaarsevenement 2015 Jurian van de Laar Jurian van de Laar @JurianvdL 30 april 2015

@JurianvdL

Jurian van de Laar

2

30 april 2015 @JurianvdL

Agenda

3


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


Waar draait het om? Bewijs

Feedback geven

Status Voortgang Communicatie 5


Waar gaat het mis? • Kort en bondig ? • Samenvatting ? • Grafieken ?

Wat vertel je wel … en Wat vertel je niet … Interpretatie

• Go / No Go ?

Interpretatie

Interpretatie 6


Mijn werk…

7


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


R&D Organisatie Validatie Systeem Ontwerp En Architectuur Systeem Integratie, Systeem Test En Verificatie

Engineering Image Chain Cluster Unit 1

9

Unit 2


Unit 2

Testen in het medisch domein

… de auditor ook ! De klant is koning …

Bron: Wall Street Journal Bron: Eindhovens Dagblad

10


Engineering Perspectief

Auditor Perspectief

• Vertrouwen opbouwen

• Bewijslast leveren (‘evidence’)

• Ontwikkelaar: “het werkt”

• Formele documentatie (records)

• Tester: “het werkt niet” 

• Geen test zonder specificatie

• Code reviews

• Verificatie / Validatie

• Unit testing

• Dekking = test per requirement

• Geautomatiseerde testen

• Alle testen ‘moeten’ slagen

• Code coverage meten

• Volgorde autorisatie belangrijk

• Je kunt niet alles testen (risico / technieken) 11


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

Projecten Bron: Improve Quality Services

12


Test Beleid Test Strategie

Master Test Plan

Test doelen Blauwdruk

Test strategie (2015) User Needs

Validation

System Requirements

System Design

Unit specifications

System level Verification

System Integration Test

Unit test specifications

Unit test reports

Evidence (auditable)

Confidence UTS = ‘Evidence’

Engineering level

13


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

14


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 15


Bron: Improve Quality Services

Een grafiek? 60

Nieuwe defects

50

Opgelost

40

Open

30 20 10 0 wk1 wk2 wk3 wk4 wk5 wk6 wk7 wk8 wk9 wk10 wk11

16



Defects per test uur en per ‘prioriteit’ Defects / test hour D

3

C

2,5

B 2 A 1,5 1 0,5 0 wk1 17

wk2


wk3

wk4

wk5

wk6

wk7


wk8

wk9

wk10 wk11

Gewogen defects Prioriteit A = 1 Prioriteit B = 0,5 Prioriteit C = 0,2

35 30 25 20 15 10 5 0 wk 1

wk 2

wk 3

Priority 1 18


wk 4 Priority 2


wk 5

wk 6

Priority 3

wk 7

Test rapportage: 10 do’s en don’ts 1. Dekkingsgraad van specificatie (requirements coverage)

19


Presentatie Michael Bolton (EuroSTAR 2014)

Test rapportage: 10 do’s en don’ts 1. Dekkingsgraad van specificatie (requirements coverage) 2. Aantal testgevallen (uitgevoerd / passed / failed) 3. Geautomatiseerde testen

Workshop met Aslak Hellesøy (EuroSTAR 2014) 20



5. Aantal defects / per getest uur / met prioriteiten 6. Produkt risico’s (Prisma®, Risk Poker ®)

Probability

4. Dekkingsgraad van de software (code coverage)

Damage

21



PRISMA®


5. Aantal defects / per getest uur / met prioriteiten 6. Produkt risico’s (Prisma®, Risk Poker ®)

Probability

4. Dekkingsgraad van de software (code coverage)

Damage

22



PRISMA®

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

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

Bron: Rapid Software Testing

8. Test aspecten (mindmap)

Bron: vscomputer.wordpress.com/

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, ‘SFDEPOT’) 9. Exploratory testing 10. Testverhaal (test level, confidence/evidence) 25


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 26


Vragen ?

[email protected]

27


@JurianvdL

28


Test rapportage Waarom eigenlijk?

Recommend Documents