Testen2.

0TM - de praktijk van agile testen

QRC: Beslissingstabel
Definitie: Het samenstellen van testgevallen op basis van beslissingen uit het systeem, waarbij de
volledigheid en juistheid van de verwerking hoog is.
Doel: Het verhogen van de volledigheid en de juistheid van een verwerking.
Principe: Door de testgevallen te baseren op de logica van enkelvoudige beslissingen binnen het
systeem, worden de functionaliteiten van het systeem gecontroleerd. De diepgang en het
aantal testgevallen is daarbij afhankelijk van de testmaat en de detailleringsmaat.
Toepasbaarheid: • Unittest
• Integratietest
• Systeemtest
• Functionele acceptatietest
Aanpak:
Stap 1. Bepaal de triggers en de enkelvoudige condities. Zet deze in kwadrant A (zie onder).
Stap 2. Definieer de bijbehorende acties. Zet deze in kwadrant B.
Stap 3. Werk kwadrant C uit – laat iedere conditie één keer waar en één keer onwaar zijn.
Stap 4. Vul kwadrant D in. Geef aan welke beslissingen onmogelijk zijn en voeg dubbele testgevallen samen.
Stap 5. Beschrijf zo nodig de testgevallen in realistische situaties.

Figuur 32 Een beslissingstabel wordt uitgewerkt in kwadranten

Voorbeeld: Uitverkoop kledingzaak
Uitverkoop is alleen van toepassing op artikelen die langer dan drie maanden in voorraad zijn. Op broeken krijgt men
30%, op overhemden 20% en op sokken 50% korting.
Logisch testgeval 1 2 3 4 5 6 7 8
Trigger = Artikel in voorraad J J J J J J J J
B1: Meer dan drie maanden in voorraad J J J J N N N N
B2: Artikel = broek J J N N J J N N
B3: Artikel = overhemd J N J N J N J N
A1: Geen korting x x x x
A2: Korting = 30% x x
A3: Korting = 20% x
A4: Korting = 50% x
A5: Artikel = sokken x
Stap 4: Testgeval 2 is gelijk aan testgeval 1 omdat bij conditie “Artikel = broek” het niet uitmaakt of
“Artikel = overhemd” waar of onwaar is. Testgeval 6, 7 en 8 zijn gelijk aan testgeval 5 omdat het niet
uitmaakt welke waarde het artikel heeft zodra deze niet langer op voorraad is.
Stap 5: Beschrijf de testgevallen in realistische situaties
Testgeval 1: Een artikel is meer dan drie maanden in voorraad en het artikel is een broek.
Actie: korting = 30%
Testgeval 3: Een artikel is meer dan drie maanden in voorraad en het artikel is een overhemd.
Actie: korting = 20%
Testgeval 4: Een artikel is meer dan drie maanden in voorraad en het artikel is geen broek en
geen overhemd. Actie: artikel = sokken, korting = 50%
Testgeval 5: Een artikel is minder dan drie maanden in voorraad.

Pagina 1 van 19
Testen2.0TM - de praktijk van agile testen

QRC: Blink testen

Definitie: Een blinktest is een test waarbij men een grote hoeveelheid data analyseert
door niet op de inhoud van de data zelf te letten, maar op het patroon van de
data. Hierbij maakt men gebruik van het menselijke vermogen om patronen te
herkennen in bijvoorbeeld grootte, vorm, kleur en geluid.
Doel: Het snel kunnen analyseren van een grote hoeveelheid data.
Principe: Met blink testen bladert men door een grote hoeveelheid data en wordt er
gezocht naar onregelmatigheden in deze data. Deze onregelmatigheden
kunnen dan duiden op fouten. Door deze methode kunnen echter niet alle
fouten gevonden worden.
Bruikbaarheid: Blink testen zal ook gebruikt moeten worden als aanvulling op bestaande tests,
niet als een op zichzelf staande testsoort.
Engelse term: Blink testing.

Aanpak
De aanpak van het opzetten van een blinktest kan per situatie verschillen. Het algemene patroon is:

Stap 1. Voer een willekeurig aantal testscenario's uit zodat er een bepaalde uitvoer geproduceerd wordt (logging,
output op een scherm, een document, records in een database of iets dergelijks).
Stap 2. Geef het afwijkend patroon een bepaalde kleur (bijv. via tekstverwerker of spreadsheet) of zorg dat het op
een ander wijze visueel herkenbaar is.
Stap 3. Analyseer de uitvoer op patronen en zoek naar onderbrekingen in het gevonden patroon.
Stap 4. Bespreek de waarnemingen met een specialist.

Voorbeelden
• Blader snel door een lang logbestand (door bijvoorbeeld page down ingedrukt te houden) en kijk naar het patroon
van wat er voorbij komt en kijk of er vreemde variaties in zitten.
• Plak een grote logfile in een spreadsheet en zoom uit. Kijk of er een patroon in de lengte van de regels zit.
Gebruik de voorwaardelijke opmaak op bepaalde regels om het patroon makkelijker te herkennen. Als er een
patroon herkend wordt, zoek dan naar onderbrekingen van dit patroon. Indien gevonden, zoom hier weer in om te
eigenaardigheden te traceren
• Open twee schermprinten en ‘alt-tab’ deze heel snel heen en weer. Wat valt op?
• Print een groot document uit (technische documentatie, databaserecords, output van een applicatie) en blader er
snel doorheen, zoekend naar patronen.
• Converteer een grote hoeveelheid data naar geluid. Luister naar patronen en onderbrekingen daarvan.

Pagina 2 van 19
Testen2.0TM - de praktijk van agile testen

QRC: Equivalentieklassen
Definitie: Het onderverdelen van mogelijke in- en outputvariabelen in verschillende
klassen die logischerwijs hetzelfde systeemgedrag hebben.
Doel: Het verhogen van de dekkingsgraad van inputwaarden.
Principe: Door testgevallen te baseren op equivalentieklassen in plaats van op elke
mogelijke invoerwaarde, blijft het aantal testgevallen beperkt, terwijl toch een
goede dekking verkregen wordt (elke waarde uit een klasse heeft dezelfde kans
op het vinden van een fout).
Bruikbaarheid: Onder andere voor:
• unittest;
• integratietest;
• acceptatietest.
Engelse term: Equivalence partitioning of domain testing.

Er wordt onderscheid gemaakt tussen geldige en ongeldige equivalentieklassen: ongeldige klassen leiden tot
foutmeldingen, geldige klassen worden correct verwerkt.

Types waarden
Er kunnen verschillende types waarden van invoerklassen worden gehanteerd:

Boolean: Juist of onjuist J/N, bijv. “Bent u particulier?”

Rij: Uit de rij of buiten de rij “Achternaam beginnend met de letters L t/m T.”
Nummers: Exacte nummers of onjuiste “De nummers 1 en 2 uit de poule gaan door.”
nummers
Grenswaarden: Onder, binnen of boven de grens

Aanpak
Stap 1. Bepaal de attributen: van welke gegevens moeten de inputwaarden worden vastgesteld?
Stap 2. Bepaal de geldige attribuutklassen: welke waarden leiden tot andere gegevensverwerking of
systeemgedrag?
Stap 3. Bepaal de ongeldige attribuutklassen: welke waarden moeten niet door het systeem geaccepteerd worden?
Stap 4. Stel de testgevallen op: welke fysieke waarden ga je gebruiken?

Voorbeeld
Creditcardautorisatie: op welke manier wordt de juistheid van creditcardinvoer gecontroleerd?

Attribuut (stap 1) Geldige waarde (stap 2) Ongeldige waarde (stap 3)

Maatschappij: VISA, American Express, Mastercard Diners Club, JCB
(stap 4)
Nummer: Voldoet aan toetsingscriteria Voldoet niet aan criteria, bijv. sofi-
nummer of bankrekeningnummer
Naam: J.A. Janssen, T.A. Pietersen Spelfout of niet bekend
Geldigheidsperiode: Tot einde maand afloop Na einde maand afloop

Pagina 3 van 19
Testen2.0TM - de praktijk van agile testen

QRC: Exploratory testen

Definitie: Elke vorm van testen waarbij de testgevallen worden ontworpen tijdens de
testuitvoer en de informatie die hieruit wordt verkregen wordt gebruikt om
nieuwe en betere testgevallen te ontwerpen.
Doel: Het in korte tijd testen van een module of een specifiek aspect van de software
om daarmee inzicht te krijgen in de kwaliteit ervan.
Principe: Voor een specifiek doel wordt een hoeveelheid testtijd ingeruimd op basis
waarvan de (ervaren) tester aan de slag gaat om binnen die tijd de belangrijkste
fouten te vinden. Dit wordt opgesteld in de vorm van een opdracht of ‘charter’.
Er is geen vooropgesteld script, maar de tester vaart op ervaring, doel en scope
van de sessie en op intuïtie.
Bruikbaarheid: Blackboxtesten.
Engelse term: Exploratory testing.

Aandachtspunten
• De primaire tester is iemand die het systeem goed kent, of een specialist in zijn vakgebied (bijv. usabilitytesten of
performancetesten).
• De diepgang van de test wordt bepaald door de ervaring van de tester(s) en de hoeveelheid tijd (hoe meer
diepgang gewenst, alloceer des te meer tijd).
• Maximale testtijd voor een opdracht is vier uur (client/server of webbased omgeving).
• Pair testing (samen met andere tester, ontwikkelaar, ontwerper of klant) is een optie om de dekkingsgraad te
verhogen.

Voorbereiding
Voorafgaand aan het testen dient het volgende voorbereid te worden door de testcoördinator of testmanager:
1. Scope: bepaal welke module of welk aspect je gaat testen. Baken de scope af door ook te noemen wat je níet
test.
2. Doel: omschrijf met welk doel/waarom je gaat testen: naar welke informatie over het systeem ben je op zoek?
3. Tijdsindicatie: hoeveel tijd mag er maximaal aan de opdracht besteed worden?

Uitvoering
Tijdens de uitvoering houdt de tester de volgende aspecten bij:
1. Hoe: op welke manier worden de fouten gezocht (bijv. gebruikt tool, logisch pad, de focus). Houd eventuele
wijzigingen in aanpak bij.
2. Bevindingen: welke bevindingen zijn geconstateerd (verwijs naar bevindingentool).
3. Verslag: wat is je algemene oordeel over de module/het aspect. Benoem eventueel nieuw ontdekte risico’s.

Voorbeeld
ET opdracht ‘ARKA’
Scope: Rapportagemodule systeem ‘ARKA’, uitsluitend pdf-uitvoer.
Doel: De lay-out van alle pdf’s dient consistent te zijn, de data die op de pdf
getoond wordt komt overeen met die op het scherm staan.
Tijd: Maximaal vier uur.
Hoe: Klantnrs 1001001 t/m 1001099 gehanteerd, beoordeeld of de klant
volledige gegevens per rapportage had, screendump gemaakt, pdf
gegenereerd en die afgedrukt. Screendump met pdf vergeleken.
Bevindingen: 111, 112, 114, 116, 118, 119, 121.
Verslag: De berekeningen rechtsonder worden niet goed getoond. Alle waardes
wel correct. Aanpassing pdf-generator.

Pagina 4 van 19
Testen2.0TM - de praktijk van agile testen

QRC: FitNesse
Doel: FitNesse maakt het mogelijk voor klanten, testers en programmeurs om (lerenderwijs) te
bepalen wat de software moet doen. De opgestelde verwachtingen kunnen automatisch
vergeleken worden met de daadwerkelijke output van het systeem. Testen kunnen desgewenst
samengevoegd worden waardoor een compleet geautomatiseerde (regressie) testset ontstaat.
Principe: In het algemeen kan gesteld worden dat hoe lager het niveau waarop getest wordt des te meer
technische kennis en vaardigheden de tester dient te bezitten. FitNesse lost dit probleem op
door een gebruikersvriendelijke voorkant (in de vorm van een wiki) te koppelen aan de te
testen module(s).
Bruikbaarheid: FitNesse kan gebruikt worden in de volgende situaties:
• vroeg testen en accepteren van belangrijke modulen en interfaces;
• Test Driven Development;
• testen als er überhaupt nog geen voorkant gebouwd is;
• opstellen en uitvoeren van geautomatiseerde regressietesten.
FitNesse is voor iedereen eenvoudig in gebruik als het framework eenmaal goed is ingericht.
Voor het koppelen van te testen modules aan FitNesse is echter kennis nodig van Java of C#.
URL: www.fitnesse.org.

Voorbereiding
Alvorens met FitNesse te kunnen starten dienen er fixtures geschreven te worden. Dit zijn de koppelingen tussen het
FitNesse framework en de te testen software. De koppelingen dienen zo ‘dun’ mogelijk te zijn om te voorkomen dat
het testresultaat wordt beïnvloed door de code van de fixture.

Uitvoering
Testcases kunnen via de geïntegreerde wiki opgevoerd en beheerd worden. De testcases worden in tabelvorm
opgeslagen. Er zijn diverse tabelvormen mogelijk afhankelijk van de gewenste verwerking. Hieronder staat een
voorbeeld van de meest eenvoudige tabelvariant.

Voorbeeld
Er wordt een module geschreven die input A deelt door B en de waarde C terugstuurt. Een test in FitNesse zou er
dan als volgt uit kunnen zien:

Module optellen
WaardeA WaardeB ?Uitkomst
10 2 5
3 1 3
8 0 8
2 2 2

Als de test wordt uigevoerd dan zal FitNesse de eerste waarde A en waarde B verzenden en de uitkomst vergelijken
met de verwachte uitkomst. Hierna wordt de volgende regel verwerkt etc. Als de verwachting en de retourwaarde
overeenkomen wordt de uitkomst groen gekleurd. Als dit niet het geval is wordt de cel rood gekleurd. Als er iets
misgaat bij de verwerking wordt de cel geel gekleurd.

Module optellen
WaardeA WaardeB ?Uitkomst
10 2 5
3 1 3
8 0 8 (error)
2 2 2 (expected)
1 (actual)

Op basis van de output kan er besloten worden om de verwachting van een testcase aan te passen of een
codewijziging door te voeren. Op deze manier leert het team van de uitkomsten van de test en kunnen het systeem
en het testproces verbeterd worden.
Pagina 5 van 19
Testen2.0TM - de praktijk van agile testen

QRC: Pairwise testen

Definitie: Het reduceren van de complexiteit van meervoudige variabelen door uitsluitend de paarsgewijze
combinaties te testen (in plaats van alle mogelijke combinaties).
Doel: Het met zo min mogelijk inspanning behalen van een hoge dekkingsgraad op complexe materie.
Principe: De meeste fouten ontstaan als gevolg van één factor of een combinatie van twee factoren.
Pairwise testen nivelleert complexiteit door uit te gaan van een combinatie van twee in plaats van
meervoudige variabelen, waardoor een hoge dekkingsgraad wordt bereikt met minder
testgevallen.
Voorbeeld: Als A x B en B x C getest is, is de kans op een fout in de combinatie A x B x C nihil.
Bruikbaarheid: • Datacombinatietest (Dataflow test)
• Equivalentieklassen

Er kan gebruikgemaakt worden van twee tools:

• Allpairs van James Bach (www.satisfice.com/tools.shtml);
• Pict33 van Microsoft (www.pairwise.org/tool.asp).
Engelse term: Pairwise testing.
Beperkingen: Dit verwerkingsprincipe test alleen de combinaties van twee factoren.

Aanpak
Stap 1. Definieer het aantal variabelen en bepaal het aantal waarden per variabele.
Stap 2. Kies een van de tools: Allpairs of Pict 33.

• Allpairs kan worden altijd worden toegepast. De kracht van dit tool is dat de tester extra informatie krijgt over de
dekking per testgeval. Deze informatie wordt gebruikt bij de afweging of een testgeval wel of niet moet worden
uitgevoerd, wanneer als gevolg van tijdsgebrek blijkt dat niet alle testgevallen uitgevoerd kunnen worden.
• Pict33 kan worden toegepast als alle testgevallen uitgevoerd (kunnen) worden.

Stap 3. Pas de bijbehorende tool toe door:

• de inputfile te definiëren volgens de handleiding;
• de outputfile te genereren met de tool.

Stap 4. Beschrijf zo nodig de testgevallen vanuit de outputfile in realistische situaties.

Voorbeeld
Een administratie moet maandelijks loonberekeningen voor tien personen maken en een keer per jaar moet een
jaaropgave gegenereerd worden. De personen zijn onderverdeeld in drie loonschalen (schaal 1, schaal 2 en schaal
3) en voor iedere schaal geldt dat er drie verschillende declaraties mogelijk zijn (onkostenvergoeding,
lunchvergoeding en telefoonvergoeding). De personen werken parttime en fulltime.

Stap 1: Definieer het aantal variabelen en bepaal het aantal waarden per variabele

Variabelen Waarden
Soort Maandelijks, jaarlijks
Soort contract Parttime, fulltime
Loonschalen Schaal 1, schaal 2, schaal 3
Declaratie Onkostenvergoeding, lunchvergoeding, telefoonvergoeding

Stap 2: Kies een van de tools: AllPairs of PICT 33

In geval van uitwerking met PICT33 ziet de inputfile er als volgt uit:
Soort Maandelijks
Jaarlijks
Soort contract Parttime
Fulltime
Loonschalen Schaal 1
Schaal 2
Schaal 3

Pagina 6 van 19
Testen2.0TM - de praktijk van agile testen
Declaratie Onkostenvergoeding
Lunchvergoeding
Telefoonvergoeding

In geval van uitwerking via Allpairs ziet de inputfile er als volgt uit:
Soort Soort Contract Loonschalen Declaratie
Maandelijks Parttime Schaal 1 Onkostenvergoeding
Jaarlijks Fulltime Schaal 2 Lunchvergoeding
Schaal 3 Telefoonvergoeding

Stap 3: De output van de tool.

PICT33
Testgeval Soort Soort contract Loonschalen Declaratie
1 Jaarlijks Parttime Schaal 3 Onkostenvergoeding
2 Maandelijks Fulltime Schaal 1 Telefoonvergoeding
3 Maandelijks Parttime Schaal 1 Lunchvergoeding
4 Jaarlijks Fulltime Schaal 3 Telefoonvergoeding
5 Maandelijks Fulltime Schaal 1 Onkostenvergoeding
6 Jaarlijks Fulltime Schaal 2 Lunchvergoeding
7 Maandelijks Parttime Schaal 2 Telefoonvergoeding
8 Maandelijks Parttime Schaal 3 Lunchvergoeding
9 Jaarlijks Parttime Schaal 1 Onkostenvergoeding
10 Jaarlijks Parttime Schaal 2 Onkostenvergoeding
Allpairs
Testgeval Soort Soortcontract Loonschalen Declaratie Aantal combi’s
1 Maandelijks Parttime Schaal 1 Onkostenvergoeding 6
2 Jaarlijks Fulltime Schaal 1 Lunchvergoeding 6
3 Jaarlijks Parttime Schaal 2 Onkostenvergoeding 5
4 Maandelijks Fulltime Schaal 2 Lunchvergoeding 5
5 Maandelijks Parttime Schaal 3 Telefoonvergoeding 5
6 Jaarlijks Fulltime Schaal 3 Onkostenvergoeding 4
7 Jaarlijks Fulltime Schaal 1 Telefoonvergoeding 3
8 ~Maandelijks Parttime Schaal 2 Lunchvergoeding 1
9 ~Jaarlijks ~Parttime Schaal 2 Telefoonvergoeding 1
10 ~Maandelijks ~Fulltime Schaal 3 Lunchvergoeding 1

Stap 4: Beschrijf zo nodig de testgevallen vanuit de outputfile in realistische situaties.

Voorbeeld
Testgeval Omschrijving
1 Een jaarlijkse berekening van een parttimer uit schaal 3 wordt gemaakt. De parttimer
heeft een onkostenvergoeding.
2 Een maandelijkse berekening van een fulltimer uit schaal 1 wordt gemaakt. De fulltimer
heeft een telefoonvergoeding.
Etc. Etc.

Pagina 7 van 19
Testen2.0TM - de praktijk van agile testen

QRC: Procescyclustest
Definitie: Het testen van de inpassing van het systeem in de bedrijfsprocessen door
opeenvolgende logische acties te doorlopen.
Doel: Vaststellen of de geautomatiseerde processen voldoende informatie leveren voor de
werkprocessen en vice versa.
Principe: Testgevallen worden gebaseerd op de benodigde acties voor het doorlopen van een
proces.
Bruikbaarheid: • Blackboxtesten
• Meerdere eindgebruikers met verschillende rollen in het proces dienen deze test
(mede) uit te voeren

Aanpak
Stap 1. Stel de beslispunten vast op basis van de werkprocessen.
Stap 2. a. Bepaal de padcombinaties, gevormd uit één tak vóór een beslispunt en één tak ná dat beslispunt.
b. Knoop padcombinaties aan elkaar tot paden door het werkproces.
Stap 3. Stel de testgevallen op: voorzie elk pad van de benodigde waarden voor de beslispunten, dit is gelijk de
basis voor de initiële gegevensverzameling en het testscript.

Voorbeeld
Uitverkoop kledingzaak.
Uitverkoop is alleen van toepassing op artikelen die langer dan drie maanden in voorraad zijn. Op broeken krijgt men
30%, op overhemden 20% en op sokken 50% korting.

Procesflow

Matrix met paden (testgevallen)

TG Pad/comb 1,2 1,3 3,4 3,5 5,6 5,7
1 1,2 X
2 1,3,4 X X
3 1,3,5,6 X X X
4 1,3,5,7 X X X

Testscript van testgeval 3

TG Stap Actie
3 P3-1 Het artikel ligt langer dan drie
maanden in voorraad.
P3-2 Het artikel is geen broek.
P3-3 Het artikel is een overhemd.
P3-4 De korting bedraagt 20%.

Figuur 33 Een procesflow bij procescyclustest

Pagina 8 van 19
Testen2.0TM - de praktijk van agile testen

QRC: Productrisicoanalyse
Definitie: Een productrisicoanalyse is de inventarisatie van de productrisico’s voor die
items/gebieden die het hoogste risiconiveau hebben en die daarom het
belangrijkst zijn om te testen.
Doel: Het met alle stakeholders gezamenlijk tot één beeld komen van wat de meer of
minder risicovolle kenmerken en delen van het te testen product zijn. Deze
analyse dient als basis voor de teststrategie waardoor onderdelen met het
hoogste risico als eerste en meer intensief worden getest dan die met lagere
risico’s.
Principe: De productrisico’s worden bepaald door alle belanghebbenden. Er vindt een
inschatting plaats van de gevolgen van mogelijke fouten en op basis daarvan
wordt er geprioriteerd.
Bruikbaarheid: De productrisicoanalyse wordt uitgevoerd als onderdeel van het op te stellen
(master)testplan. Hiermee wordt de testinspanning gericht op die onderdelen
waar de grootste risico’s zijn aangegeven.
Engelse term: Product Risk Analysis.

Tools: PRISMA (o.a. ImproveQS) en PRIMA (Valori).

Website: Http://en.wikipedia.org/wiki/ISO_9126.

Aandachtspunten
• Een productrisicoanalyse kan zowel eendimensionaal als tweedimensionaal worden uitgevoerd. Bij een
eendimensionale aanpak wordt slechts één dimensie, meestal een functionele opdeling van het
informatiesysteem, geprioriteerd. Deze is hieronder uitgewerkt.
• Bij de tweedimensionale aanpak worden ook kwaliteitscriteria meegenomen in de risicoanalyse.
• Faalkans: hierbij wordt bepaald in hoeverre het mogelijke (technisch) risico zich kan voordoen. De overwegingen
hierbij zijn onder andere complexiteit en frequentie van gebruik.
• Impact: hierbij wordt bepaald wat de mogelijke schade van falen is. De overwegingen hierbij zijn
gebruikersbelang en procesdoorwerking.

Aanpak
• Er wordt geïnventariseerd welke consequenties de productrisico’s mogelijk hebben.
• Vervolgens wordt gekeken naar het gevolg: heeft dit betrekking op één klant of op alle klanten, of is er al dan niet
een workaround beschikbaar?
• Op basis van de risico’s en hun impact wordt de prioriteit van het testen bepaald: Must test, Should test, Could
test en Would test.
• Bij de voorbereidingen van de nieuwe requirements voor de iteratie kan vervolgens bepaald worden in welke
risicocategorie de requirements vallen. De risicocategorie bepaalt de prioriteit en diepgang waarmee er getest
moet worden.

Voorbeeld
Als er een risico Wat gebeurt er? Voor wie? Categorie
optreedt, dan… Ontstaat er een Alle klanten Must test
levensbedreigende Eén klant Must test
situatie
Ontstaat er geen Alle klanten Should test
levensbedreigende
situatie
Eén klant Could test
Ontstaan er financiële Alle klanten Should test
consequenties Eén klant Could test
Ontstaan er niet- Alle klanten Could test
financiële Eén klant Would test
consequenties

Pagina 9 van 19
Testen2.0TM - de praktijk van agile testen

QRC: Proefgevallenanalyse
Definitie: Het op basis van een stroomschema uitwerken van testgevallen tot realistische
situaties, waarbij dekkingsgraad en overdraagbaarheid hoog zijn.
Doel: Het creëren van realistische situaties op basis van de informatiestromen door
het systeem.
Principe: De functionaliteiten van het systeem worden in een stroomschema beschreven,
waarna de verschillende mogelijkheden worden getest op basis van de
testmaat. De testmaat bepaalt hierbij de diepgang.
Bruikbaarheid: De proefgevallenanalyse is bruikbaar voor onderstaande testsoorten:
• unittest;
• acceptatietest;
• blackboxtesten.
Aanpak
Stap 1. Stroomschema opstellen; geef weer welke keuzes achtereenvolgens worden gemaakt en welke acties uit
deze keuzes volgen.
Stap 2. Inventariseren van beslispunten; geef weer welke beslissingen worden genomen.
Stap 3. Opstellen van padcombinaties en testpaden op basis van het stroomschema.
Stap 4. Uitwerken naar realistische situaties.

Voorbeeld
Uitverkoop kledingzaak
Uitverkoop is alleen van toepassing op artikelen die langer dan drie maanden in voorraad zijn. Op broeken krijgt men
30%, op overhemden 20% en op sokken 50% korting.

Stap 3: Opstellen van padcombinaties en testpaden op

basis van het stroomschema
Padcombinaties:
Beslispunt 1: (1,2), (1,3), (2,-).
Beslispunt 2: (3,4), (3,5), (4,-).
Beslispunt 3: (5,6), (5,7), (6,-), (7,-).

Testpaden:
Pad 1: 1, 3, 5, 7.
Pad 2: 1, 3, 4.
Pad 3: 1, 3, 5, 6.
Pad 4: 1, 2.

Stap 4: Uitwerken naar realistische situaties

1. Artikel is langer dan drie maanden op voorraad, en het zijn
sokken. Resultaat: 50% korting.
2. Artikel is langer dan drie maanden op voorraad, en het is een
broek. Resultaat: 30% korting.
3. Artikel is langer dan drie maanden op voorraad, en het is een
overhemd. Resultaat: 20% korting.
4. Artikel is minder dan drie maanden op voorraad. Resultaat:
geen korting.

Figuur 34 Een procesflow bij

proefgevallenanalyse
Stap 1: Stroomschema opstellen.

Stap 2: Inventariseren beslispunten

1. Artikel minder dan drie maanden op voorraad.
2. Artikel = een broek.
3. Artikel = overhemd.
4. Artikel = sokken.

Pagina 10 van 19
Testen2.0TM

QRC: Testmaat - Algoritmetest, Procescyclustest

Definitie: De testmaat geeft aan hoe diep de afhankelijkheden tussen opeenvolgende

beslispunten worden getest.
Doel: Het gebruiken van de juiste detailleringsmaat op de juiste plaats van het
systeem.
Principe: Bij testmaat n worden alle afhankelijkheden van acties vóór een beslispunt en
na n-1 beslispunten geverifieerd door alle mogelijke combinaties van n in
opeenvolgende acties in testpaden onder te brengen.
Bruikbaarheid: Het begrip testmaat wordt gebruikt bij de volgende testsoorten:
• algoritmetest;
• procescyclustest.

Aanpak
De keuze van de testmaat hangt af van de complexiteit en het risico van de functies.

• Testmaat 1 houdt in dat een actie slechts wordt beïnvloed door de beslissing en niet door de voorliggende acties.
• Testmaat 2 bevat dus altijd koppelingen van een actie voor een beslissing en een actie na een beslissing.

Er zijn ook hogere testmaten, waarbij aangenomen wordt dat de uitvoering van een actie doorwerkt in meer dan één
opvolgende acties. De hogere testmaten worden meestal alleen gekozen voor riskante en complexe functies. Een
hogere testmaat betekent vanzelfsprekend meer (of evenveel) testgevallen.

Voorbeeld

Figuur 35 Een voorbeeld van testpaden

Pagina 11 van 19
Testen2.0TM

QRC: Testmaat - Beslissingsanalyse

Definitie: De testmaat geeft aan hoeveel uitkomsten van determinanten er gecombineerd

worden.
Doel: Het gebruiken van de juiste detailleringsmaat op de juiste plaats van het
systeem.
Principe: Een beslissingstabel heeft de testmaat n als de tabel voor iedere groep van n
determinanten alle mogelijke combinaties bevat. Dit betekent dat er bij testmaat
n 2n situaties in de beslissingstabel bestaan.
Bruikbaarheid: Deze testmaat wordt gebruikt bij de beslissingstabellentest

Aanpak
De keuze van de testmaat hangt af van de complexiteit en het risico van de functies.
• Testmaat 1 houdt in dat alleen de uitkomsten van determinanten worden gecontroleerd: allemaal een keer ‘waar’
en een keer ‘niet waar’. Dit betekent dat er altijd maar twee logische testgevallen ontstaan, onafhankelijk van het
aantal determinanten.
• Testmaat 2 houdt in dat voor iedere groep van twee determinanten alle combinaties in de beslissingstabel zitten.
Een hogere testmaat betekent vanzelfsprekend meer (of evenveel) testgevallen.

Voorbeeld
De volgende beslissingstabel bevat drie determinanten.

Logische testkolom: 1 2 3 4
Determinant 1 0 0 1 1
Determinant 2 0 1 0 1
Determinant 3 1 0 0 1

De testmaat van deze tabel is gelijk aan 2, omdat elke groep van determinanten alle mogelijke combinaties bevat; de
groep van determinant 1 en determinant 2 bevatten 00, 01,10 en 11, evenals de groep van determinant 2 en
determinant 3.

De tabel hieronder toont het aantal logische testgevallen per testmaat.

Testmaat 1 2 3 4 5 6 7 8 9 10

Determinanten

1 2 2 2 2 2 2 2 2 2 2

2 2 4 4 4 4 4 4 4 4 4

3 2 4 8 8 8 8 8 8 8 8

4 2 5 8 16 16 16 16 16 16 16

5 2 6 10 16 32 32 32 32 32 32

6 2 7 12 22 32 64 64 64 64 64

7 2 8 14 29 49 64 128 128 128 128

8 2 9 16 37 72 107 128 256 256 256

9 2 10 18 46 102 172 228 356 512 512

10 2 11 20 56 140 266 392 476 512 1024

Pagina 12 van 19
Testen2.0TM

QRC: Unit testen - Voorbereiding

Definitie: Unit testen is het valideren van de werking van de kleinst onderscheidbare
eenheden van broncode. Bij objectgeörienteerd ontwikkelen: het testen van
individuele methoden van een klasse.
Doel: Het op het laagst mogelijke niveau veiligstellen van een goede werking van het
systeem. Door een snelle feedback weet je zeker dat de code goed werkt en of
een aanpassing (refactoring) geen ongewenste gevolgen heeft. Unit testen
vereenvoudigt de integratie doordat eenheden reeds getest zijn.
Principe: In een agile omgeving worden unittests gebruikt om de goede werking van de
code te borgen. Om effectief te kunnen zijn, moeten dergelijke testen veelvuldig
kunnen worden herhaald, bij voorkeur worden ze in een framework (bijvoorbeeld
JUnit bij Java) geautomatiseerd.
Unittests moeten snel kunnen worden uitgevoerd; de eenheid moet elementair
worden getest. Externe afhankelijkheden worden vervangen door zogenoemde
stubs of mock objects.
Na iedere build van het systeem moet 100% van alle unittests slagen.
Bruikbaarheid: Continuous integration (het frequent kunnen maken van een build) is een must.
Met name in omgevingen voor objectgeörienteerd ontwikkelen zijn er voldoende
tools die dit ondersteunen.
Voor een complex systeem kunnen unittests ook op integratieniveau worden
gedefinieerd. Het vervangen van deelsystemen door stubs is een dure
investering, mogelijk gerechtvaardigd door een betere onderhoudbaarheid en het
sneller corrigeren van fouten.
Engelse term: Unit testing.
Primaire Doorgaans uitgevoerd door de ontwikkelaar zelf, zeker niet door eindgebruikers.
uitvoerder Testspecialist kan assisteren of reviewen om de dekkingsgraad van de test te
valideren.

Aandachtspunten
• Voor het uitvoeren van unittests wordt gebruikgemaakt van tools en libraries, zoals JUnit, TestNG en DbUnit.
• Het invoeren van unittests in een bestaand project kan kostbaar zijn. Het vergt bovendien een verandering in de
mindset van de uitvoerenden. De werkwijze wordt meer uniform en meer kwaliteitsgedreven dan in een project
zonder unittests.
• De bij unittests gebruikte dekkingsvormen (coverages) staan vermeld op een aparte QRC.

Voorbereiding
Op projectniveau dienen de volgende zaken te worden geregeld:
1. Continuous integration: de gehele applicatie wordt automatisch gecompileerd tot een nieuwe testbare versie, kort
nadat er code is ingecheckt in het codebeheersysteem.
2. Inrichting configuratiemanagementsysteem: de testconfiguratie (gegevens/database; invoer/testgevallen) moet
telkens hersteld of bijgewerkt worden.
3. Automatic deployment: installatie van de nieuwe versie op een testomgeving.
4. Automatische uitvoering unittests: volgend op een nieuwe build worden alle unittests geautomatiseerd uitgevoerd.

(Voor bovenstaande stappen zijn tools beschikbaar die op elkaar zijn afgestemd.)

Afspraken op projectniveau:
1. Welke applicatieonderdelen moeten daadwerkelijk van unittests worden voorzien? In verband met de
verwerkingssnelheid wordt interactie met gebruiker/netwerk/database doorgaans uitgesloten.
2. Diepgang (coverage) van de unittests, mogelijk afhankelijk van een indeling in risicoklassen.
3. Aanvliegroute: unittests parallel met de code opstellen, of eerst unittests opstellen voordat er code wordt
geschreven? De laatste werkwijze geniet de voorkeur, en wordt Test Driven Development genoemd. Een
(falende!) unittest wordt opgesteld vóórdat er code wordt toegevoegd. Pas daarna wordt de code geschreven,
zodat de test slaagt.

Pagina 13 van 19
Testen2.0TM

QRC: Unit testen – Uitvoering

Aanpak
1. Bedenk een test voor de gevraagde functionaliteit (wat is de bedoeling van de code).
2. Let ook op wat er moet gebeuren als het fout gaat.
3. Schrijf de test. Controleer dat de test faalt. (Immers, de code ontbreekt nog.)
4. Schrijf de code.
5. Voer de test uit (ook voor de foutsituatie).
6. Refactor de code.
7. Voer nogmaals alle tests uit.
8. Controleer of de beoogde coverage (zie mastertestplan/Definition of Done) is behaald.

Voorbeeld (JUnit 4.x)

Gevraagd: een functie die kan vertellen of een getal al dan niet positief is.
Coverage: het gebruik van equivalentieklassen wordt voldoende geacht.
public class Voorbeeld {

public static boolean isPositief(int x) {

}
}
// 2 equivalentieklassen: probeer zowel een positief als een negatief getal.
// @Test is annotatiesyntax, geïntroduceerd bij JUnit 4.0 en ondersteund door Java 5.
import org.junit.Assert;

public class Voorbeeld {

public static boolean isPositief(int x) {

}

@Test public void positieveTest() {

int a = 5;
boolean out = Voorbeeld.isPositief(a);
Assert.assertTrue("Uitkomst zou true moeten zijn want 5 is positief", out);
}
@Test public void negatieveTest() {
int a = -3;
boolean out = Voorbeeld.isPositief(a);
Assert.assertFalse("Uitkomst zou false moeten zijn want -3 is negatief",
out);
}
}

Als invulling van de code proberen we:

public static boolean isPositief(int x) {
return x>=0;
}

Nu slagen beide tests.

Later krijgen we het verzoek om ook de grenswaarde (x = 0) op te nemen in de test.
@Test public void zeroTest() {
int a = 0;
boolean out = Voorbeeld.isPositief(a);
Assert.assertFalse("Uitkomst zou false moeten zijn want 0 is niet positief",
out);
}

Die test faalt. Kennelijk is de code onjuist.

public static boolean isPositief(int x) {
return x>0;
}

Nu slagen alle drie de tests.

Pagina 14 van 19
Testen2.0TM

QRC: Dekkingsgraad / test coverage

Definitie: Dekkingsgraad = aantal geteste combinaties / benodigd aantal combinaties.
Doel: Kunnen bepalen of een (unit)test de complexiteit van de code voldoende afdekt.
Principe: Samengestelde condities uitdrukken in enkelvoudige condities. Selecteren van de
te testen combinaties. In praktijk: tooling geeft het behaalde percentage aan.
Bruikbaarheid: Whitebox testen, of blackbox in geval van een zeer formele of gestructureerde
testbasis.
Engelse term: Test coverage (de andere Engelse termen zijn hieronder opgenomen).

Aandachtspunten
• Context: vertaalslag als bij de beslissingstabellentechniek.
• Herhaalbaarheid: meerdere mogelijkheden om aan de gevraagde test coverage te voldoen.

Nadere definities:
• Statement coverage: ieder statement wordt ten minste één keer uitgevoerd → één testgeval.
• Multiple condition coverage: iedere combinatie van condities wordt getest → 2n testgevallen.
• Decision coverage (ook: branch coverage): de samengestelde determinant wordt één keer waar en één keer
onwaar getest → altijd maar twee testgevallen.
• Condition coverage: iedere enkelvoudige conditie in de samengestelde determinant wordt ten minste één keer
waar en één keer onwaar gekozen → wederom slechts twee testgevallen.
• Decision/condition coverage: de samengestelde determinant wordt één keer waar en één keer onwaar gekozen,
onder de voorwaarde dat iedere enkelvoudige conditie ook één keer waar en één keer onwaar is. Dit impliceert
decision coverage en condition coverage → ook nu slechts twee testgevallen.
• Modified condition/decision coverage (MCDC) (condition/determination coverage): iedere enkelvoudige
determinant bepaalt tweemaal de waarde van de samengestelde determinant, één keer waar en één keer
onwaar. Dit geschiedt onafhankelijk, dat wil zeggen door andere determinanten constant te laten. Modified
condition/decision coverage impliceert decision/condition coverage. MCDC vergt hooguit 1+ (1½ * n) testgevallen,
waar n het aantal enkelvoudige determinanten is.

Voorbereiding
Voorafgaand aan het testen dient het volgende voorbereid te worden door de testcoördinator of testmanager:
1. Keuze voor beoogde dekkingsgraad conform master testplan en product risicoanalyse.
2. Bepalen enkelvoudige determinanten.
3. (MCDC) Telkens voor één enkelvoudige determinant twee combinaties selecteren die alleen verschillen in de
waarde voor die enkelvoudige determinant, en wel zodanig dat daarmee de samengestelde determinant één keer
waar en één keer onwaar is. Hergebruik zoveel mogelijk combinaties.
4. Nadere uitwerking verwachte resultaten: hoe vertaalt een waarde van de determinanten zich naar een
verifieerbaar gedrag van de applicatie. (Zie beslissingstabellentechniek.)

Uitvoering
Tijdens de uitvoering houdt de tester de geteste combinaties bij, en vergelijkt waargenomen versus verwacht
applicatiegedrag.

Voorbeeld
Samengestelde determinant: V = (A EN B) OF (C EN D) OF (A EN C).
SC (statement coverage): 0000 . [V = 0]
DC (decision coverage): 0101 en 1110 . [V = 0; V=1]
CC (condition coverage): 0110 en 1001 . [V=0; V=0]
DCC (decision/condition coverage): 0101 en 1010 . [V=0; V= 1]
MCDC:

(A is bepalend) 0100 en 1100.

(B is bepalend) 1000 en 1100.
(C is bepalend) 1000 en 1010.
(D is bepalend) 0110 en 0111.
Na wegstrepen duplicaten: 0100, 0110, 0111, 1000, 1010, 1100 . [V=0;0;1;0;1;1]

Pagina 15 van 19
Testen2.0TM

QRC: Agile teams

Definitie: Een agile team is een team dat in staat is frequent werkende software op te
leveren, iteratief te werken en zich effectief multidisciplinair ontwikkelt.

Doel: Inzicht in de rolverdeling en aandachtspunten bij het samenstellen van high

performance teams.
Principe: Stel een zodanig team samen dat snel en langdurig in staat is klinkende
resultaten op te leveren.

Aandachtspunten bij het formeren van een agile team

• Een agile team is multidisciplinair: in principe is iedere stakeholder vertegenwoordigd in het team. Minimaal
bestaat een agile team uit een klantvertegenwoordiger (product owner), team facilitator (ScrumMaster),
ontwerper(s), ontwikkelaar(s), tester(s), eindgebruiker(s) en beheerder(s).
• Ieder teamlid moet mondeling goed kunnen communiceren met zijn teamleden.
• Een agile team zit zoveel mogelijk op één locatie.
• Bij outsourcing/offshoring: zorg voor multidisciplinaire teams op iedere locatie.
• Teamleden moeten elkaar qua karakter aanvullen; denk bijv. aan Belbin-rollen.
• Geadviseerd wordt om een nieuw team minimaal drie iteraties de tijd te geven om het proces op elkaar af te
stemmen.
• Als vuistregel geldt dat vooral beginnende teams niet te groot moeten zijn, een teamgrootte van zeven plus of min
twee leden.

Best presterende teams ontstaan niet vanzelf. Belangrijkste voorwaarde voor een succesvol team is dat iedereen
zich inzet voor het team en verstand heeft van softwareontwikkeling. In een agile team is iedereen gericht op
toename van zowel de individuele competenties als ook de teamsamenwerking.
Om agile te kunnen werken is het noodzakelijk dat teams een gemeenschappelijk doel hebben, er wederzijds
vertrouwen en respect is en er een proces is van gezamenlijke besluitvorming.
Zelforganiserende teams zijn geen ongeleide teams, maar steeds in staat om zichzelf te organiseren om tegemoet te
komen aan nieuwe uitdagingen waarvoor het team zich gesteld ziet.

Teamrollen
Scrum onderkent drie rollen:
• de stem van de klant
Product owner • eigenaar van requirements
• verantwoordelijk voor prioriteit en return on investment
• de doeners, creëren business value
• zelforganiserend
Teamleden • zelfsturend
• gekwalificeerde specialisten (multidisciplinaire teams)
bestaande uit zeven plus/minus twee leden.
• proceseigenaar
Projectleider (ScrumMaster) • faciliteert het proces en procesverbetering
• beschermer en coach van het team

DSDM Atern onderkent twaalf rollen op drie niveaus:

• Projectniveaurollen – de managers, coördinatoren en stuurgroepleden van het projectwerk. Ze zijn normaal

niet betrokken in de dagelijkse ontwikkeling van de oplossing, hoewel ze altijd voldoende beeld van de
oplossing moeten hebben om het proces te begrijpen en waar nodig strategische sturing te geven.
• Solution development teamrollen – de vormers en de bouwers van de oplossing. Ze zijn collectief
verantwoordelijk voor de dagelijkse ontwikkeling van de oplossing en de geschiktheid ervan voor het
bedrijfsdoel.
• Overige rollen – omvat andere stakeholders en specialisten. Deze rollen voorzien in het assisteren en hulp
bieden aan het projectteam waar dat nodig is.

Pagina 16 van 19
Testen2.0TM

Project manager Verantwoordelijk voor alle

aspecten in het opleveren van de oplossing.
Technical coordinator Zorgt dat er een technisch
coherente oplossing ontstaat die voldoet aan
technische kwaliteitsstandaarden.
Team leader Werkt met het team om alle aspecten
van oplevering te plannen en te coördineren. Meer
een leiderschapsrol dan een managementrol en wordt
idealiter gekozen door teamleden als de beste
persoon om het team door een bepaalde fase van het
project te leiden.
Business ambassadorVertegenwoordigt de
businessrol in het solution development team.
Business analyst Gericht op de relatie tussen
business- en technische rollen om juiste richting te
geven aan het development team. Vertaalt de
behoefte van de business naar de correcte richting
voor het development team.
Solution developer Vertaalt de businessbehoefte
in een werkende oplossing die tegemoet komt aan
functionele en non-functionele eisen.
Solution tester Is geïntegreerd in het development
team en voert testen uit die in overeenstemming zijn
met de technische teststrategie gedurende het project.
Business advisor Collega(’s) van de business
ambassador, geeft advies op specifieke vraagstukken.
Workshop facilitator Faciliteert het
workshopproces, katalysator voor voorbereiding en
Figuur 36 Rollen volgens DSDM Atern
communicatie.
Atern coach Helpt het team om het meeste uit de
Business sponsor Verantwoordelijk voor de
Aternaanpak te halen.
realisatie en eigenaar van de geleverde oplossing.
Specialisten Naast bovengenoemde kunnen
Business visionary Meer betrokken bij de
specifieke expertrollen op ad hoc basis aan het
uitvoering en verantwoordelijk voor het interpreteren
kernteam worden toegevoegd, bijvoorbeeld
van de behoefte van de business sponsor.
technische experts.

(zie http://www.dsdm.org/atern/roles-responsibilities/team-organisation/ )

Team overleg
Een agile team kent drie belangrijke overlegsoorten
Start van de iteratie
Dagelijkse stand-up
meeting.
Hierin worden de iteratieplanning bepaald,
schattingen gemaakt en prioriteiten
gesteld aan de requirements.
Hierin worden standaard drie zaken
behandeld:
• Wat heb ik gisteren gedaan?
• Wat ga ik vandaag doen?
• Welke belemmeringen ondervind ik?

• Demo van de resultaten

Einde van de iteratie • Retrospective

Pagina 17 van 19
Testen2.0TM

QRC: Scrum

Scrum is een populaire agile projectmanagementmethode, met name gebruikt voor softwareontwikkeling.
Het team dient multidisciplinair te zijn, uitgerust met alle benodigde vaardigheden, om tot werkende software te
komen. Er is geen sprake van een fasering; alle activiteiten vinden binnen de iteratie plaats.
Er wordt gewerkt met iteraties (sprints) van een vaste lengte (timebox). Er wordt áltijd op tijd opgeleverd, en volgens
een vast kwaliteitskader. Eventuele sturing vindt plaats op de op te leveren functionaliteit.

Er is altijd een intensieve samenwerking met de klant, en de sprints worden kort gehouden. Zodoende wordt er veel
feedback gegenereerd, en kan de klant zich ervan verzekeren dat het eindresultaat een hoge waarde heeft voor de
business. Requirements met de hoogste business value worden als eerste geïmplementeerd.

Proces
Sprint planning meeting Meeting van team en product owner, waarin de requirements worden verduidelijkt, en
de sprint backlog wordt opgesteld.
Daily stand-up meeting Een staande bespreking van hooguit vijftien minuten. Drie vragen voor iedereen:
(daily scrum) 1. Wat heb ik gedaan sinds de vorige meeting?
2. Wat ga ik vandaag doen?
3. Is er iets wat me daarbij hindert?
Demo De teamleden presenteren de gerealiseerde functionaliteit en ontvangen feedback
van de product owner en overige stakeholders.
Retrospective Team plus product owner evalueren het proces en definiëren acties ter verbetering.

Rollen
Product owner Neemt beslissingen over de inhoud en de Moet beschikbaar zijn voor het team.
onderlinge prioritering van requirements. Hij Mag de backlog aanpassen; wijzigingen gaan
is vertegenwoordiger van alle stakeholders. de volgende sprint in.
ScrumMaster Faciliteert het team onder andere door Alert op het onderkennen van problemen;
obstakels weg te nemen, en ziet toe op de voorzitter voor alle meetings met uitzondering
naleving van de Scrumprincipes. Schermt van de demo.
het team af van bemoeienissen van buitenaf.
Teamlid Uitvoerende. Neemt deel aan alle meetings Werkt eigen tijdsinschattingen bij tijdens de
en pakt taken zelfstandig op. Alle teamleden daily scrum. Proactief in het signaleren van
hebben één gezamenlijk doel. problemen.

Documenten en producten
Product backlog Lijst van requirements in een ruwe vorm,
geprioriteerd door de product owner.
Sprint backlog De requirements die worden opgepakt in
de sprint.
Werkende Definition of Done bevat alle
software kwaliteitscriteria die het team nastreeft.
Ook als er meerdere teams zijn, is er slechts
één product backlog en een product owner.
Team en product owner kiezen samen; team
committeert op basis van best-effort.
Er wordt alleen functionaliteit opgeleverd, die
voldoet aan de Definition of Done.

Pagina 18 van 19
Testen2.0TM

QRC: Definition of Done

In agile methoden (in het bijzonder bij Scrum) wordt het nagestreefde kwaliteitsniveau expliciet gemaakt door alle
kwaliteitscriteria en controlestappen op te sommen in de zogenoemde Definition of Done.
Om eenduidig te zijn en bruikbaar voor het maken van tijdsinschattingen dient de Definition of Done ook enkele
details te bevatten aangaande de werkwijze en de betrokkenen.
Beknoptheid is eveneens gewenst; daartoe zijn verwijzingen naar externe documenten mogelijk.
In de ideale situatie bevat de Definition of Done alles wat benodigd is tot en met het uitbrengen voor productie.

Werkwijze
Stap 1. Voordat het project goed en wel aanvang kan vinden, komen ‘het team’ en de klant (zijnde de opdrachtgever
plus de beheerorganisatie) een lijst van kwaliteitscriteria overeen. Deze lijst wordt op papier gezet, en
gecommuniceerd met alle betrokkenen.
Stap 2. De Definition of Done wordt in acht genomen bij het maken van tijdsinschattingen, en daarbij in het bijzonder
de samenstelling van het programma voor de eerste iteratie.
Stap 3. Gedurende de iteratie staat de Definition of Done centraal bij alle activiteiten. Alleen functionaliteit die
daadwerkelijk aan alle criteria voldoet en dus echt ‘af’ is, heeft waarde voor de business.
Stap 4. Na iedere iteratie wordt geëvalueerd of de overeengekomen Definition of Done inderdaad is gehaald, en of
deze voldoet. Ingeval er een nieuw criterium wordt toegevoegd, wordt er voor de eerstvolgende iteratie een
inhaalslag op het programma gezet.

Voorbeeld
# Criterium Uitleg Uitvoerende Opmerkingen
1 Bouw op build server Alle code is ingecheckt, en Ontwikkelaar. Bouw op een
compileert zonder fouten. gereserveerde
machine.
2 Gereed voor Versie neergezet in een Teamleider. Lijst met functionele
acceptatietest afzonderlijke omgeving voor wijzigingen
acceptatietesten. beschikbaar in
documentvorm.
3 Unittest Unit testen op Ontwikkelaar; voor 100% van de unittests
datacomponenten en kritische onderdelen moet slagen.
bedrijfslogica; níet op de (hoogste risico) Diepgang/coverage
interface. bijgestaan door afhankelijk van
testspecialist. technische
complexiteit en
bedrijfsrisico, als
beschreven in
mastertestplan.
4 Test Driven Iedere toevoeging wordt Ontwikkelaar.
Development voorafgegaan door een
(falende!) unittest.
5 Systeemtest Functionele systeemtest Tester, waar nodig
uitgevoerd; alle meldingen bijgestaan door
uit de categorie ‘blokkerend’ overige teamleden.
en ‘hoog’ zijn afgehandeld.
6 Regressietest Systeemtest wordt uitgebreid Testspecialist. Gefaciliteerd met
met een script, dat middels virtuele servers
speciale tools en vanwege
configuratiemanagement kan afhankelijkheid
worden herhaald. systeemklok.

Pagina 19 van 19