Agile testen - kwaliteit onder controle Marc Evers – Piecemeal Growth Anko Tijman – Ordina TestNet 16 maart 2006 www.testnet.org

Agenda Wat betekent ‘agile’ en agile testen Kwaliteitsborging in agile projecten Test driven development - pauze - Test driven development in de praktijk Agile testtechnieken Discussie en afsluiting Niet vergeten: vertel kort iets over onszelf Tijdsindicatie: 18:00 – 18:20 Wat betekent agile 18:20 – 18: 40: Kwaliteitsborging 18:40 – 19.00: TDD Pauze 19:15 – 19.30 TDD praktijk 19:30 – 19: 50 Test technieken 19:50 – 20.15 Discussie en afsluiting

Agile softwareontwikkeling iteratief incrementeel kortcyclisch geprioriteerd eenvoud eerst Eigenschappen van agile so vragen: wie is bekend met agile? wie heeft agile gewerkt? wat weet men over agile? wat is het beeld dat men heeft? noteer steekwoorden --> Gebruik Flipover

Agile is... resultaatgericht - duurzaam resultaat mens- en procesgericht continu sturen op basis van feedback continu verbeteren, in kleine stappen communicatie duurzaam resultaat: niet alleen korte termijn succes, maar ook duurzaam resultaat kunnen blijven boeken concurrentievoordeel op basis van mensen en processen ipv technologie IT is more about people than about computers... n.b. proces != procedure continu sturen op basis van frequente feedback over produkt en proces “La perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever” (Antoine de Saint-Exupery)

Agile is... denkwijze en houding methodiek is beginpunt, niet het doel proces continu aanpassen aan veranderende omgeving kleine stappen, kleine problemen optimalisatie van hele cyclus (loop), niet slechts een deel agile is niet een specifiek proces of methode (zoals XP, DSDM, Scrum) Agile kijkt niet naar de individuele onderdelen, zoals ontwerp, bouw of test; het kijkt naar de hele cyclus en wil daar resultaat op halen. Geen suboptimalisatie dus. Verbeterprocessen richten zich (helaas) vaak wel op (het meten van) onderdelen. Agile betekent continue procesverbetering, simpel gezegd is je “metaproces”: zoek je ergste probleem - er is er altijd wel een - kijk naar het hele systeem stel een oplossing voor - hoe weet je of het werkt? probeer deze een tijdje - evalueer en behoud wat werkt

Agile waarden Mensen en interactie Werkende software Samenwerken met de klant Reageren op veranderingen “Simple, clear purpose and principles give rise to complex, intelligent behaviour. Complex rules and regulations give rise to simple, stupid behaviour.” (Dee Hock, ceo VISA)

Roots van agile deels bestaande, bewezen werkwijzen "lean" produktie, JIT, Toyota Productie Systeem dynamische programmeertalen – Smalltalk, Lisp systeemdenken aandacht voor rol van mens en teamdynamiek Psychology of Computer Programming (1971) Peopleware (1987) financieel risicomanagement (bijv. opties) "opstand" van programmeurs vraag om "agility" vanuit business aantal agile werkwijzen werden in de jaren 60 en 70 al succesvol toegepast we zien recentelijk opleving van dynamische programmeertalen, bijv. Python en Ruby systeemdenken: systeemdenken beschouwt werkelijkheid als systeem van gerelateerde delen, met de aanname dat het geheel meer is dan sec de som der ddelen. Systeemdenken gegroeid uit besturingstheorie / modellen van feedbackbesturing; toegepast op organisaties (o.a. Shell in jaren 70), 5e Discipline van Peter Senge, Theory of Constraints; Weinberg heeft systeemdenken binnen ICT gepromoot.

Agile testen Testen in een agile project Feedback Eenvoud Communicatie Teamwork Agile: values Flexibel: - klantgericht - projectgericht - oplossingsgericht

Agile testen Huidige stand van zaken Flexibele aanpak van het testen Context driven testing (Kaner, Bach & Pettichord)

Kwaliteitsborging Hoe weet je of dat wat je gemaakt heb, goed is? Als je iets moeilijks te maken hebt, hoe reduceer je de complexiteit? vragen: hoe zien deelnemers kwaliteitsborging? hoe gebeurt dat momenteel in projecten? hoe wordt dat gemanaged? hoe wordt op kwaliteit gestuurd? (als dat al het geval is) wat zijn de effecten van deze wijzen van kwaliteitsborging? Fundamentele vraag: wat is kwaliteit? Jerry Weinbergs definitie: waarde voor iemand ("value for someone") punt 1: Feedback punt 2: Simplicity Waarsch antwoorden: entry- en exit criteria, QA manager, audits, reviews, procescompliance

Risicomanagement Tijd / Kwaliteit / Functionaliteit Eenvoud Incrementeel Prioriteren Testen...! vragen: Ervaring met projecten die niet mogen falen / die moeten slagen? Welke ervaring hebben deelnemers met risicomanagement in projecten? Wat ziet men gebeuren? hoe wordt met risico’s omgegaan? Heeft men ervaring met “buffers” in projecten? (Agile) manieren van risicomanagement: vaste tijd / vaste kwaliteit / flexibele scope complexiteit reduceren door eenvoud toe te passen projectrisico's managen door geen big bang iteratief en incrementeel werken helpt je om allerlei risico beter te managen prioriteren van je requirements - de risicovolle eerst bouwen en herprioriteren tijdens de loop v/h project, helpt ook om de boel beheersbaar te houden test early / test often - dit levert je vroeg en continu feedback of bepaalde risico's zich gaan materialiseren zodat je meteen in kan grijpen

Kwaliteitsborging in agile projecten kwaliteitsborging ingebakken in proces risicomanagement werken in kleine stappen continu evalueren en monitoren van risico's voorbeeld: werkwijzen XP Kwaliteitsborging is niet iets wat je "erop plakt"/aan toevoegt – niet een separaat iets Risicomanagement in XP: XP werkwijzen helpen om aantal "standaard" risico's in softwareontwikkeling te beheersen en te beperken – bijv. frequente releases en korte iteraties; alles geautomatiseerd testen (voorkomen van regressie) Kwaliteit is in agile, net als tijdigheid, een niet- onderhandelbaar iets. De practice zit er in, en je doet hem goed. De flexibliteit komt vanuit de prioriteitstelling van de omvang van de oplossing.

Agile en testen geen aparte fase, maar een ingebedde, essentiële activiteit basis voor kwaliteits- en risicomanagement feedback over kwaliteit van produkt en proces basis om projecten (en resultaat) te sturen Testen draait om het verschaffen van inzicht in de kwaliteit en voortgang van het project. Dit is dus een iets andere definitie (vaak”'aantonen dat het systeem voldoet aan de gestelde specs”) feedback over kwaliteit van produkt en proces basis om projecten (en resultaat) te sturen Het blijft echter ook testen: - rol blijft - technieken (komen we op terug) - risicoanalyse .

Test driven development eerst test, dan implementatie incrementeel vroege & frequente feedback geautomatiseerd begin met het schrijven van de test alvorens hetgeen getest wordt te bouwen vroege, frequente feedback: je weet dus zsm dat er niet aan een bepaalde test voldaan wordt zodat je genoeg tijd hebt om dit aan te pakken dat houdt hetgeen je aan het doen bent een stuk beter voorspelbaar, itt testen aan het eind (en/of onvoldoende testen) als je testen op die manier naar voren trekt krijg je denk ik ook een heel andere defecten-dynamiek – defecten vind je eerder en los je eerder op ipv tegen het einde van het project opeens een hele voorraad aan defecten te hebben (die weer gemanaged moeten worden en zo) in feite begin je met een formele specificatie van wat je verwacht, bijv. qua functionaliteit, qua gedrag van een module, qua performance; daarmee wordt testen ook ontwerpen: je definieert je requirements en verwachtingen precies en concreet. testen ligt dus heel dicht tegen requirements (stories, etc.) aan – ben je als tester in een traditioneel project niet bezig achteraf de gaten in het requirements werk te dichten? Boriz Beizer heeft zoiets geschreven als “The design isn't done until the test cases are ready'!

Test driven development toepasbaar op alle niveaus & aspecten: technisch ontwerp en coderen functionaliteit performance & schaalbaarheid Valkuil: Test cases BDUF gaan beschrijven (...) Maatregel: In kleine stapjes blijven denken TDD binnen de iteratie uitvoeren

TDD - unittests geautomatiseerde unittests ontwerptechniek geschreven door programmeurs ontwerptechniek testbaar → onderhoudbaar voorkomt overbodige code groeiend vangnet van tests voorkomt regressie continue feedback over wijzigingen met TDD specificeer je eerst (formeel en executeerbaar!) wat de code moet doen; dit dwingt je na te denken over hoe de structuur eruit ziet; je schrijft alleen code die je begrijpt resultaat: net zoveel testcode als programmacode verzameling unit tests moet wel in korte tijd ( < 30 s.) uitgevoerd kunnen worden

TDD - unittests werkwijze schrijf testgeval controleer of de test faalt schrijf eenvoudigste implementatie die test laat slagen controleer of de test slaagt vereenvoudig programmacode om duplicatie te verwijderen

Unittesting - voorbeeld live demo van voorbeeld: tdd bouwen van een truncate – functie in Ruby

TDD – functionele tests Extreme Programming - “acceptance tests” geautomatiseerde functionele tests op basis van bijv. use cases of “stories” defineer tests aan begin van elke iteratie specificatie van functionaliteit en acceptatiecriteria wie is verantwoordelijk voor tests? Binnen de agile wereld is dit gebied de afgelopen tijd sterk in ontwikkeling Brian marick: exampler boek (maar staat in de ijskast) expliciete acceptatiecriteria die van te voren bekend is: ontwikkelaars weten wat er verwacht wordt en wanneer het af is verantwoordelijkheden: inhoud van test: “klant” infrastructuur: programmeur

TDD – functionele tests recente ontwikkelingen open source frameworks: Selenium, Watir, FIT eigenschappen voorkomen regressie herhaalbaar & snel voortgang direct zichtbaar extra onderhoudsinspanning acceptance testing was een van de moeilijke XP practices; recentelijk wordt er veel gedaan, gediscussieerd en ontwikkeld op dat gebied, met als resultaat betere theorieën en modellen èn betere tooling/frameworks bij Watir kun je de kracht van de onderliggende taal (Ruby) gebruiken om onderhoudbare tests te schrijven. Wat je in de praktijk ziet is dat je naar een domein-specifieke taal voor je applicatie toewerkt. voorwaarde voor slagen van dergelijke aanpak is m.i. dat de tests voldoende eenvoudig zijn om te schrijven en dat de onderhoudsinspanning beperkt blijft.

Functionele tests - voorbeeld

Agile testtechnieken Testtechnieken Waterval Documentatie Specificatiefase Uitsluitend de tester Wat is het “probleem” met testtechnieken? Dilemma: Niet per definitie ongeschikt Niet per definitie “out-of-the-box” geschikt Te veel traditionele ballast

Agile testtechnieken Eenvoud Snel toepasbaar Snelle feedback Voor en door teamleden “1-page-reference card” Eigenschappen van testtechnieken in een agile context Eenvoud: het minimale uitvoeren ipv het meest volledige

Agile testtechnieken Equivalentieklassen / Grenswaardenanalyse Exploratory Testing / Pair Testing Heuristic Evaluation Beslissingsanalyse

Agile testtechnieken Equivalentieklassen Identificeer attributen Identificeer klassen Identificeer testgevallen Unittest / Integratietest / Acceptatietest

Agile testtechnieken Exploratory testing Gelimiteerde scope Gelimiteerde tijd Duidelijk doel Aanpak Probleemgericht Referenties / verslag

Agile testtechnieken Pair testing Tester + ... Hogere dekkingsgraad Minder kans op fouten Complexe problematiek Versnipperde kennis Kan met ontwerper, bouwer, klant, directeur... Gescheiden taken (uitvoering + aantekeningen) Wanneer niet: Afhankelijk van teststrategie, bijv. als het geautomatiseerd moet worden Communicatieve problemen Als er reeds testgevallen zijn die hetzelfde afdekken Voorwaarden voor PT: Vrijwillige samenwerking Geschikte ruimte / werkplek Do Not Disturb!

Agile testtechnieken Heuristic Evaluation Usability test 10 grondregels Systematische inspectie Algemene bruikbaarheidsprincipes

Agile testtechnieken Visibility of system status Recognition rather than recall Flexibility and efficiency of use User control and freedom Consistency and standards Help and documentation Error prevention Help users recognise, diagnose, and recover form errors Match between system and the real world Aesthetic and minimalist design

Agile testtechnieken Beslissingsanalyse Bepaal de beslissingssituaties Ken acties toe aan beslissingssituaties Controleer op volledigheid / doe aanpassingen 17 pagina's in Tmap – dat laat je niet aan een niet-tester lezen. Het gaat hier om de kern. No Waste! Andere technieken: Eenvoud Snelle feedback Teamleden 1 page

Discussie en afsluiting ...vragen...? Stel vragen (en beantwoord vragen) - wat ga je direct toepassen? - wat gaat in jouw omgeving nooit werken? - is er iets dat je graag zou willen doen, maar waarvoor je nog obstakels ziet? welke obstakels? - waar zou je meer van willen weten?

Bronnen www.agilemanifesto.org www.xpnl.org www.testing.com www.testinglessons.com

Bedankt! Anko Tijman anko.tijman@ordina.nl www.ordina.nl Marc Evers marc@piecemealgrowth.nl www.piecemealgrowth.nl