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.0 TM. 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.0 TM 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.0 TM en de rol van de klant Speech has allowed the communication of ideas, enabling human beings to work together to build the impossible. Mankind s greatest achievements have come about by talking and its greatest failures by not talking. It doesn t have to be like this. Our greatest hopes could become reality in the future. With the technology at our disposal, the possibilities are unbounded. All we need to do is make sure we keep talking. (Stephen Hawking) Vanuit het proces bezien zijn er vier onderwerpen voor de klant die direct met testen te maken hebben: het opstellen van acceptatiecriteria; het uitvoeren van acceptatietesten; het verhelderen van het bedrijfsbelang om op risico s gebaseerd te testen; het verschaffen van testdata; In de praktijk krijgt de klant veel vragen en bruikbare feedback van de tester omdat de bril van een tester helpt om omissies en dubbelzinnigheden in de requirements 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. Het opstellen van acceptatiecriteria Het is in de eerste plaats de verantwoordelijkheid van de klant goed te formuleren wat de business nodig heeft. De tester kan hierbij helpen. Samen met de klant kan hij de acceptatiecriteria zo formuleren dat ze ondubbelzinnig zijn en voor iedereen begrijpelijk. Wanneer bijvoorbeeld bepaalde requirements niet vertaald zijn in acceptatiecriteria zal de tester vragen om de impliciete criteria meer expliciet te maken. De tester zal erop bedacht zijn dat het stellen van vragen over de acceptatiecriteria de klant aan het denken zet, en dat deze mogelijk met nieuwe requirements op de proppen zal komen. Er is dus het gevaar van scope creep; het team heeft dan geen grip meer op de functionele wijzigingen. Aan de klant de taak om dit spel eerlijk te spelen. Hij zal begrip op moeten brengen als bijvoorbeeld het aanscherpen van de acceptatiecriteria ertoe leidt dat het team niet alle functionaliteit kan realiseren voor het einde van de iteratie. Een voorbeeld van een naar acceptatiecriteria uitgewerkte requirement is: 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 Het doel van de acceptatietest is uiteraard om te beoordelen of de werkende software voldoet aan de door de klant gestelde eisen. Door de nauwe interactie met de klant en het kunnen reageren op veranderingen is dit voor een deel al gewaarborgd. Maar er moet wel een formele bevestiging komen dat de klant ook tevreden is. Dus vandaar dat wij ook een acceptatietest opnemen in een Testen2.0-proces. Het is echter wel zo dat we dit niet zien als iets wat big bang achteraf moet gebeuren. Een acceptatietest wordt net als zoveel mogelijk andere 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 onder handen zijnde requirements steeds formeler. In het begin zal de klant zich flexibel op moeten stellen want nog niet alle taken zijn dan al uitgevoerd. Na verloop van tijd mag de klant echter wel de nodige eisen stellen. Het draait daarbij om het voldoen aan de acceptatiecriteria en de Definition of Done. Er mogen geen nieuwe eisen op tafel komen, maar het team mag ook niet de kwaliteit laten slippen. Bij de demo aan het eind van de iteratie vindt de definitieve, formele acceptatie plaats. Dan moeten de requirements aan de acceptatiecriteria en de Definition of Done voldoen. agile testen vooraankondiging.indd 3 11-9-2008 11:35:52
Voorbereiding Uitvoering Product Risico Analyse Acceptatietesten Definition of Done Werkwijzen Agile Testproces Agile testtechnieken Documenten opleveren Project Evaluatie Unit testen Master Testplan Regressie testen Geautomatiseerd testen Afbeelding: De acceptatietest vindt gedurende de iteratie en parallel aan de andere activiteiten plaats. De productrisicoanalyse, de Definition of Done en het Mastertestplan hebben hun impact op de werkwijzen in de iteratie. Aan het eind van iedere iteratie vindt een evaluatie plaats over het gehele proces. quick reference cards. De testscripts zijn bij voorkeur eenvoudig van opzet; dit maakt ze makkelijk wijzigbaar en makkelijk overdraagbaar. Daarnaast zijn ze ook nog eens makkelijker te automatiseren. Ook dat laatste is gewenst zodat de business altijd kan bepalen wat de 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 bij te staan in de acceptatietest. Het vertalen van acceptatiecriteria in logische of fysieke testgevallen is niet altijd even eenvoudig voor niet-gespecialiseerde testers. Het combineren van testvaardigheden met domeinkennis is een goede oplossing en die vaardigheden hoeven niet verenigd te zijn in één en dezelfde persoon. Aan vertegenwoordigers van de klant die regelmatig acceptatietesten doen kan natuurlijk een formele training in testvaardigheden gegeven worden in plaats van of naast het leren door het te doen. Ook kunnen testtechnieken worden geïntroduceerd middels Voor het structureren van de acceptatietest en het door klanten actief input leveren op de scripts kan de tool Fitnesse gebruikt worden. De inputwaarden voor testscripts kunnen ingevuld worden op een wiki, waarna (onder water) via fixtures de programmatuur wordt aangestuurd. Fitnesse kan onder andere gebruikt worden voor het vroeg testen en accepteren, het testen als er überhaupt nog geen user interface gebouwd is en voor het opstellen en uitvoeren van geautomatiseerde acceptatie- en regressietesten. agile testen vooraankondiging.indd 4 11-9-2008 11:35:53
Het verhelderen van het bedrijfsbelang Tijdens de planning van de iteratie krijgt de klant al vragen van teamleden om de requirements helder te krijgen. De tester is er alert op dat het feitelijke bedrijfsbelang van elke requirement bekend is. Dat bedrijfsbelang, in combinatie met de technische impact/complexiteit zoals vastgesteld door het team, levert voor elke requirement een risicocategorie op. In de teststrategie kan dan onderscheid gemaakt worden door aan een requirement in een hogere risicocategorie ofwel meer inspanning toe te wijzen ofwel een uitgebreidere testmethodiek. De klant kan er dan toe besluiten om de risicoinventarisatie formeler aan te pakken, en bijvoorbeeld meer stakeholders bij het proces te betrekken, dat is een productrisicoanalyse. De tester heeft een adviserende rol bij een dergelijke beslissing, en een faciliterende rol bij de eventuele productrisicoanalyse. Het verschaffen van testdata Relatief vaak zal het team data nodig hebben die lijkt op productiedata om het systeem effectief te kunnen testen. Dit is gewoonlijk een gevoelig onderwerp en de klant moet mogelijk met een hoger management overleggen om toestemming te krijgen om zulke data ter beschikking te stellen aan het team van de leverancier. Een effectieve manier om de zaak aan het management voor te leggen, is te doen wat testers doen, namelijk uitleggen wat de impact is wanneer het systeem níet getest wordt met realistische data. Het is redelijk om aan te nemen dat er meer fouten in het systeem zullen blijven zitten, die pas opgemerkt worden wanneer het systeem al in productie draait. Op eenzelfde manier is het mogelijk dat de klant gevraagd wordt het team te helpen om data samen te 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: Hoofdstuk 5: De rol van de klant Hoofdstuk 17: Productrisicoanalyse Hoofdstuk 24: Geautomatiseerd testen Bijlagen: Quick reference cards agile testen vooraankondiging.indd 5 11-9-2008 11:35:53
INHOUDSOPGAVE Voorwoord door James Lyndsay SECTIE: WAAROM TESTEN2.0? 1. Tijd voor het nieuwe testen 2. Testen en agile 3. De trend 2.0 4. Voordelen van de Testen2.0-aanpak SECTIE: DE AGILE CONTEXT 5. De rol van de klant 6. Agile projectmanagement 7. Korte introductie in agile methoden 8. Agile Must-haves 9. Agile valkuilen 10. Agile vaktaal SECTIE: NIEUWE WAARDEN EN PRINCIPES 11. Testen in een agile omgeving 12. Normen en waarden 12.1. Samenwerken 12.2. Feedback 12.3. Eenvoud 12.4. Flexibiliteit 13. Principes van Testen2.0 13.1. De klant heeft altijd gelijk 13.2. Kwaliteit is een teamverantwoordelijkheid 13.3. Testen is een teamsport 13.4. Testspecificatie en -uitvoering zijn geen gescheiden activiteiten 13.5. Het communiceren van een bug is belangrijker dan het registreren ervan SECTIE: TESTEN2.0 IN DE PRAKTIJK 14. Overzicht van de Testen2.0 werkwijzen 15. Testen2.0 en de rol van de klant 15.1. Het opstellen van acceptatiecriteria 15.2. Het uitvoeren van acceptatietesten 15.3. Het verhelderen van het bedrijfsbelang 15.4. Het verschaffen van testdata 16. Definition of Done 16.1. Het formuleren van de Definition of Done 16.2. Een gemeenschappelijk doel voor het team 17. Productrisicoanalyse 18. Een agile mastertestplan 19. Een testproces volgens Testen2.0 20. Unittesten 21. Agile testtechnieken 22. Documenten opleveren 23. Regressietesten 24. Geautomatiseerd testen SECTIE: DE METHODISCHE INBEDDING VAN TESTEN2.0 25. Testen2.0 binnen agile methoden 25.1. Scrum en Testen2.0 25.2. DSDM Atern en Testen2.0 25.3. RUP en Testen2.0 26. Testen2.0 en traditionele testmethoden 26.1. Risk and Requirements Based Testing en Testen2.0 26.2. TestFrame en Testen2.0 26.3. TMap Next en Testen2.0 SECTIE: TRANSITIE NAAR TESTEN2.0 27. Praktijkverhalen 27.1. Agile en Ericsson vanuit Testers bekeken 27.2. Planon Case: drie jaar agile testen 28. Traditionele werkwijzen die waardevol zijn in een agile omgeving 29. Agile werkwijzen die waardevol zijn in een traditionele omgeving 30. Valkuilen van agile testen SECTIE: DE AGILE TESTER 31. Rol van de tester 32. Persoonlijke vaardigheden 33. Attitude 34. Vakkennis BIJLAGEN: QUICK REFERENCE CARDS 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 agile testen. Sinds 1997 is hij actief als professional in het software testen. Hij is in het bezit van een ISEB- Practitioner en TMap-PA certificaat. Vanaf 2001 houdt hij zich bezig met agile software ontwikkeling en de rol van de tester daarin. In 2007 publiceerde hij het eerste en enige Nederlandse boek over agile testen. Hij heeft bijdragen geleverd aan de conferenties Eurostar, SQS-UK, Agile2005 en XPDAYS en aan diverse TestNet evenementen. Onze aanpak en dienstverlening verdienen uw aandacht. Maak vrijblijvend een afspraak met: Ordina ICT Management & Consultancy - BU Testing Ringwade 1 3439 LM Nieuwegein Tel: 030 663 74 10 Mail: agiletesten@ordina.nl 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