voorpublicatie
TESTEN2.0
TM
de praktijk van agile testen
Testen 2.0
agile testen vooraankondiging.indd 1
11-9-2008 11:35:52
In november 2008 publiceert Ordina het boek ‘Testen2.0TM. De praktijk van agile testen’ dat geschreven is door Anko Tijman en Eric Jimmink. Dit boek is het eerste Nederlandse handboek over gestructureerd testen in agile projecten. Agile projecten zijn gebaseerd op een iteratieve, incrementele ontwikkelaanpak waarin de business gedurende het gehele proces een actieve rol speelt. Testen2.0TM zet dan ook de business aan het roer, haalt het testen van het kritieke pad af en heeft een hoge mate van interne procesefficiency. Dit vereist een andere aanpak voor de tester, en dit boek legt uit hoe. Als voorpublicatie treft u hieronder hoofdstuk 15 uit het boek aan. Hierin gaat het specifiek over de rol van de klant binnen een iteratie. Bent u geïnteresseerd, wilt u de boekpresentatie bijwonen of wilt u een exemplaar van het boek bestellen, neem dan contact met ons op.
Testen2.0TM en de rol van de klant
Het opstellen van acceptatiecriteria
“Speech has allowed the communication of ideas,
Het is in de eerste plaats de verantwoordelijkheid van de
enabling human beings to work together to build the
klant goed te formuleren wat de business nodig heeft. De
impossible. Mankind’s greatest achievements have come
tester kan hierbij helpen. Samen met de klant kan hij de
about by talking and its greatest failures by not talking.
acceptatiecriteria zo formuleren dat ze ondubbelzinnig
It doesn’t have to be like this. Our greatest hopes could
zijn
become reality in the future. With the technology at our
bijvoorbeeld bepaalde requirements niet vertaald zijn in
disposal, the possibilities are unbounded. All we need to
acceptatiecriteria zal de tester vragen om de impliciete
do is make sure we keep talking.” (Stephen Hawking)
criteria meer expliciet te maken. De tester zal erop bedacht
Vanuit het proces bezien zijn er vier onderwerpen voor
zijn dat het stellen van vragen over de acceptatiecriteria
de klant die direct met testen te maken hebben:
de klant aan het denken zet, en dat deze mogelijk met
•
het opstellen van acceptatiecriteria;
nieuwe requirements op de proppen zal komen. Er is
•
het uitvoeren van acceptatietesten;
dus het gevaar van scope creep; het team heeft dan
•
het verhelderen van het bedrijfsbelang om op
geen grip meer op de functionele wijzigingen. Aan de
risico’s gebaseerd te testen;
klant de taak om dit spel eerlijk te spelen. Hij zal begrip
het verschaffen van testdata;
op moeten brengen als bijvoorbeeld het aanscherpen
•
en
voor
iedereen
begrijpelijk.
Wanneer
van de acceptatiecriteria ertoe leidt dat het team niet In de praktijk krijgt de klant veel vragen en bruikbare
alle functionaliteit kan realiseren voor het einde van de
feedback van de tester omdat de ‘bril’ van een tester helpt
iteratie. Een voorbeeld van een naar acceptatiecriteria
om omissies en dubbelzinnigheden in de requirements
uitgewerkte requirement is:
en de acceptatiecriteria op te merken. De klant zal bij testgerelateerde zaken waar nodig assistentie krijgen van de tester. Het is immers in het belang van het gehele team dat de klant gefaciliteerd wordt in zijn taken met betrekking tot het testen, en het is de tester die daar de juiste kennis en vaardigheden voor heeft.
agile testen vooraankondiging.indd 2
11-9-2008 11:35:52
Requirement (zoals aangeleverd vanuit product backlog)
Acceptatiecriteria (zoals met klant geformuleerd)
Tonen van recente wijzigingen in het overzichtsscherm
•
Tonen van wijzigingen in NAW-gegevens.
•
Alleen wijzigingen in de laatste zes maanden worden getoond.
•
Maximaal vijf wijzigingen per klant.
•
Bij meer dan vijf wijzigingen wordt de mogelijkheid tot de optie ‘Meer…’ geboden.
•
Details van wijzigingen hoeven in deze feature nog niet te worden getoond.
Het uitvoeren van acceptatietesten
onder handen zijnde requirements steeds formeler. In
Het doel van de acceptatietest is uiteraard om te
het begin zal de klant zich flexibel op moeten stellen
beoordelen of de werkende software voldoet aan de
want nog niet alle taken zijn dan al uitgevoerd. Na
door de klant gestelde eisen. Door de nauwe interactie
verloop van tijd mag de klant echter wel de nodige
met de klant en het kunnen reageren op veranderingen
eisen stellen. Het draait daarbij om het voldoen aan de
is dit voor een deel al gewaarborgd. Maar er moet wel
acceptatiecriteria en de Definition of Done. Er mogen
een formele bevestiging komen dat de klant ook tevreden
geen nieuwe eisen op tafel komen, maar het team mag
is. Dus vandaar dat wij ook een acceptatietest opnemen
ook niet de kwaliteit laten slippen. Bij de demo aan
in een Testen2.0-proces. Het is echter wel zo dat we dit
het eind van de iteratie vindt de definitieve, formele
niet zien als iets wat big bang achteraf moet gebeuren.
acceptatie plaats. Dan moeten de requirements aan de
Een acceptatietest wordt – net als zoveel mogelijk andere
acceptatiecriteria en de Definition of Done voldoen.
testsoorten – binnen de iteratie uitgevoerd, parallel aan de overige activiteiten. Het gaat dus alleen om de acceptatietest voor die requirements waar men in die iteratie aan werkt. De klant is op het project aanwezig en kan dus frequent feedback leveren. Door die waardevolle informatie vroeg te krijgen, wordt voorkomen dat pas in een laat stadium wordt geconstateerd dat de software niet aan de businesscriteria voldoet. Het spreekt voor zich dat op dag één van de iteratie er nog geen formele acceptatie kan plaatsvinden; er is immers nog amper iets gebouwd. Maar dat wil niet zeggen dat de klant niet vroeg in de iteratie al bij kan sturen. Alleen het ontwerp van een schermpje bekijken, misschien zelfs nog zonder werkende knoppen of lijsten, kan al feedback opleveren. Of het reviewen van de business rules, al is het op unittestniveau en samen met de programmeur. Gedurende de iteratie wordt de acceptatietest voor de
agile testen vooraankondiging.indd 3
11-9-2008 11:35:52
Uitvoering
Voorbereiding Product Risico Analyse
Acceptatietesten Agile Testproces
Definition of Done
Agile testtechnieken Werkwijzen
Documenten opleveren
Project Evaluatie
Unit testen Master Testplan
Regressie testen Geautomatiseerd testen
Afbeelding: De acceptatietest vindt gedurende de
quick reference cards. De testscripts zijn bij voorkeur
iteratie en parallel aan de andere activiteiten plaats.
eenvoudig van opzet; dit maakt ze makkelijk wijzigbaar
De productrisicoanalyse, de Definition of Done en het
en makkelijk overdraagbaar. Daarnaast zijn ze ook nog
Mastertestplan hebben hun impact op de werkwijzen in
eens makkelijker te automatiseren. Ook dat laatste is
de iteratie. Aan het eind van iedere iteratie vindt een
gewenst zodat de business altijd kan bepalen wat de
evaluatie plaats over het gehele proces.
exacte status van het product is.
Het is aan te bevelen om specifieke testscripts op te stellen voor de acceptatietest. Daarmee is dan immers de businesswaarde gewaarborgd. Gewoonlijk zal de tester aanbieden de klant of zijn vertegenwoordigers
Voor het structureren van de acceptatietest en het
bij te staan in de acceptatietest. Het vertalen van
door klanten actief input leveren op de scripts kan
acceptatiecriteria in logische of fysieke testgevallen is
de tool Fitnesse gebruikt worden. De inputwaarden
niet altijd even eenvoudig voor niet-gespecialiseerde
voor testscripts kunnen ingevuld worden op
testers.
testvaardigheden
een wiki, waarna (onder water) via fixtures de
met domeinkennis is een goede oplossing en die
programmatuur wordt aangestuurd. Fitnesse kan
vaardigheden hoeven niet verenigd te zijn in één en
onder andere gebruikt worden voor het vroeg testen
dezelfde persoon. Aan vertegenwoordigers van de klant
en accepteren, het testen als er überhaupt nog geen
die regelmatig acceptatietesten doen kan natuurlijk een
user interface gebouwd is en voor het opstellen en
formele training in testvaardigheden gegeven worden
uitvoeren van geautomatiseerde acceptatie- en
in plaats van of naast het ‘leren door het te doen’. Ook
regressietesten.
Het
combineren
van
kunnen testtechnieken worden geïntroduceerd middels
agile testen vooraankondiging.indd 4
11-9-2008 11:35:53
Het verhelderen van het bedrijfsbelang
Het verschaffen van testdata
Tijdens de planning van de iteratie krijgt de klant al vragen
Relatief vaak zal het team data nodig hebben die lijkt
van teamleden om de requirements helder te krijgen.
op productiedata om het systeem effectief te kunnen
De tester is er alert op dat het feitelijke bedrijfsbelang
testen. Dit is gewoonlijk een gevoelig onderwerp en
van elke requirement bekend is. Dat bedrijfsbelang, in
de klant moet mogelijk met een hoger management
combinatie met de technische impact/complexiteit zoals
overleggen om toestemming te krijgen om zulke data ter
vastgesteld door het team, levert voor elke requirement
beschikking te stellen aan het team van de leverancier.
een ‘risicocategorie’ op. In de teststrategie kan dan
Een effectieve manier om de zaak aan het management
onderscheid gemaakt worden door aan een requirement
voor te leggen, is te doen wat testers doen, namelijk
in een hogere risicocategorie ofwel meer inspanning
uitleggen wat de impact is wanneer het systeem níet
toe te wijzen ofwel een uitgebreidere testmethodiek. De
getest wordt met realistische data. Het is redelijk om
klant kan er dan toe besluiten om de risicoinventarisatie
aan te nemen dat er meer fouten in het systeem zullen
formeler
blijven zitten, die pas opgemerkt worden wanneer het
aan
te
pakken,
en
bijvoorbeeld
meer
stakeholders bij het proces te betrekken, dat is een
systeem al in productie draait.
productrisicoanalyse. De tester heeft een adviserende
Op eenzelfde manier is het mogelijk dat de klant
rol bij een dergelijke beslissing, en een faciliterende rol
gevraagd wordt het team te helpen om data samen te
bij de eventuele productrisicoanalyse.
stellen die representatief is voor het toekomstig gebruik van het systeem. Het verschaffen van een indicatie van de verwachte gebruiksintensiteit Een ander type data dat van de klant gevraagd kan worden (en er valt iets voor te zeggen dat dit onderdeel is van de requirements) is het beoogde of verwachte gebruik van het product. Dat wil zeggen of het bekend is welke onderdelen van de applicatie het zwaarste gebruik zullen kennen. Die informatie kan (moet) dan gebruikt worden bij de voorbereiding van het testen van onder andere nietfunctionele kwaliteitsattributen zoals performance. Zie ook:
agile testen vooraankondiging.indd 5
•
Hoofdstuk 5: De rol van de klant
•
Hoofdstuk 17: Productrisicoanalyse
•
Hoofdstuk 24: Geautomatiseerd testen
•
Bijlagen: Quick reference cards
11-9-2008 11:35:53
INHOUDSOPGAVE
16.1. Het formuleren van de Definition of Done 16.2. Een gemeenschappelijk doel voor het team
Voorwoord door James Lyndsay
17. Productrisicoanalyse 18. Een agile mastertestplan
SECTIE: WAAROM TESTEN2.0?
19. Een testproces volgens Testen2.0
1. Tijd voor het nieuwe testen
20. Unittesten
2. Testen en agile
21. Agile testtechnieken
3. De trend 2.0
22. Documenten opleveren
4. Voordelen van de Testen2.0-aanpak
23. Regressietesten 24. Geautomatiseerd testen
SECTIE: DE AGILE CONTEXT 5. De rol van de klant
SECTIE: DE METHODISCHE INBEDDING VAN
6. Agile projectmanagement
TESTEN2.0
7. Korte introductie in agile methoden
25. Testen2.0 binnen agile methoden
8. Agile Must-haves
25.1. Scrum en Testen2.0
9. Agile valkuilen
25.2. DSDM® Atern en Testen2.0
10. Agile vaktaal
25.3. RUP® en Testen2.0 26. Testen2.0 en traditionele testmethoden
SECTIE: NIEUWE WAARDEN EN PRINCIPES
26.1. Risk and Requirements Based Testing en
11. Testen in een agile omgeving
Testen2.0
12. Normen en waarden
26.2. TestFrame® en Testen2.0
12.1. Samenwerken
26.3. TMap®Next en Testen2.0
12.2. Feedback 12.3. Eenvoud
SECTIE: TRANSITIE NAAR TESTEN2.0
12.4. Flexibiliteit
27. Praktijkverhalen
13. Principes van Testen2.0
27.1. Agile en Ericsson vanuit Testers bekeken
13.1. De klant heeft altijd gelijk
27.2. Planon Case: drie jaar agile testen
13.2. Kwaliteit is een teamverantwoordelijkheid
28. Traditionele werkwijzen die waardevol zijn in een
13.3. Testen is een teamsport
agile omgeving
13.4. Testspecificatie en -uitvoering zijn geen gescheiden
29. Agile werkwijzen die waardevol zijn in een
activiteiten
traditionele omgeving
13.5. Het communiceren van een bug is belangrijker
30. Valkuilen van agile testen
dan het registreren ervan SECTIE: DE AGILE TESTER SECTIE: TESTEN2.0 IN DE PRAKTIJK
31. Rol van de tester
14. Overzicht van de Testen2.0 werkwijzen
32. Persoonlijke vaardigheden
15. Testen2.0 en de rol van de klant
33. Attitude
15.1. Het opstellen van acceptatiecriteria
34. Vakkennis
15.2. Het uitvoeren van acceptatietesten 15.3. Het verhelderen van het bedrijfsbelang
BIJLAGEN: QUICK REFERENCE CARDS
15.4. Het verschaffen van testdata 16. Definition of Done
agile testen vooraankondiging.indd 6
11-9-2008 11:35:53
Over de auteurs
Voor meer informatie
Anko Tijman is Partner van Ordina op het gebied van
Onze aanpak en dienstverlening verdienen uw
agile testen. Sinds 1997 is hij actief als professional
aandacht. Maak vrijblijvend een afspraak met:
in het software testen. Hij is in het bezit van een ISEBPractitioner en TMap-PA certificaat. Vanaf 2001 houdt
Ordina ICT – Management & Consultancy - BU Testing
hij zich bezig met agile software ontwikkeling en de
Ringwade 1
rol van de tester daarin. In 2007 publiceerde hij het
3439 LM Nieuwegein
eerste en enige Nederlandse boek over agile testen. Hij heeft bijdragen geleverd aan de conferenties Eurostar,
Tel: 030 – 663 74 10
SQS-UK, Agile2005 en XPDAYS en aan diverse TestNet
Mail:
[email protected]
evenementen.
www.ordina.nl
Eric Jimmink is Consultant Testen bij Ordina. Vanuit zijn achtergrond als ontwikkelaar en meewerkend voorman verlegde hij vanaf 1998 zijn focus naar het testvak. Eric is ISEB Foundation en TMap-PA gecertificeerd. Sinds 2001 houdt hij zich bezig met agile ontwikkeling en het testen in die context. Eric leverde een bijdrage aan de conferentie Agile2008 en zal op Eurostar2008 eveneens spreken.
agile testen vooraankondiging.indd 7
11-9-2008 11:35:53
agile testen vooraankondiging.indd 8
11-9-2008 11:35:53
