Agile Testing In de praktijk

!

AGILE TESTEN IN DE PRAKTIJK

7 AUGUSTUS 2008

Agile Testing

Erik Boelen is een test professional sinds 2000.

In de praktijk

‘Ik ben een Agile Tester!’. Dit zijn erg trendy woorden tegenwoordig! In de meeste gevallen worden ze ook vergezeld door slagzinnen als ‘wij hebben alle documentatie overboord gegooid’, of ‘wij werken erg chaotisch’ om te komen tot een van mijn favorieten ‘wij scrummen elke dag minstens 2 keer’. Voor zover ik weet, is ‘scrummen’ enkel een werkwoord in de wereld van rugby en American football. Wij voeren scrums uit, zou al een betere zin zijn, wanneer je uiteraard de echte betekenis van Scrum in agile projecten even negeert.

Als test manager and test consultant heeft hij reeds een groot aantal bedrijven geholpen in de opzet van hun testproces, dikwijls in een agile omgeving. Hij is een frequent spreker op nationale en internationale conferenties. Zijn EuroSTAR2008 presentatie zal zijn vierde zijn, na zijn track sessions in 2003, 2006 en 2007. Vorig jaar richtte hij zijn eigen firma QA Consult Services op.

!

QA Consult Services Acaciadreef 16 3140 Keerbergen BELGIUM +32 486 394 573 [email protected] www.qaconsult.eu

WAT IS AGILE TESTING? Versta me niet verkeerd, ik geloof in alle goede intenties die vasthangen aan deze woorden. Ik heb met mijn eigen ogen gezien dat deze aanpakken een heel erg positieve invloed kunnen hebben op de uiteindelijke projectresultaten. Ik ben zelfs een ‘true believer’ zoals men dat noemt. Ik ben het echter niet eens met het feit dat je door het gebruik van deze termen en definities een agile tester wordt – laat staan een tester in het algemeen. Een goede tester – agile of niet – kan al deze principes gebruiken en toepassen, maar het gebruik ervan maakt per definitie geen goede tester van je. We moeten voorkomen dat testers en hun klanten de echte betekenis van agile vergeten, aangezien testen in agile projecten niet gaat over het gebruik van deze termen en definities. EEN KORTE TERUGBLIK OP AGILE TESTEN Als herinnering voor de lezer over wat nu precies agile in software opleveringen betekent, verwijs is graag naar een presentatie die Elisabeth Hendrickson gaf voor GoogleTalk over Agile Testing.

PAGE 1

!


7 AUGUSTUS 2008

Agile gaat over het continu voorzien van toegevoegde waarde aan je klanten. De twee belangrijkste onderdelen van Agile zijn: •

Verhoog het aantal keren dat je feedback geeft aan je eindklant

•

Verminder de afval

Een goede manier om Agile te omschrijven is door te vermelden wat het eigenlijk niet is. Dus, Agile gaat niet over: •

Het verkorten van de doorlooptijd, noch over

•

Het stopzetten van alle documentatie, en zeker niet over

•

Coderen tot de laatste minuut.

Het draait allemaal over de maximale toegevoegde waarde voor een minimale cost.

Elisabeth Hendrickson over Agile Testing Het begon allemaal met het Agile Manifesto voor softwareontwikkeling. Als je aandachtig de principes van dit manifesto leest, zal je zien dat de vorige statements duidelijk zijn afgeleid hiervan.

!"#$%$#&'()*'"#*$"+,-'.+$/")*!"#$%&$!'#((#(%)*+%,!!-(** 0/-1$"2*)/3+4'-,*!"#$%'!.&$#/#*(0"#%+!'1.#*,),0!*%* 5&)+/6,-*./(('7/-'+$/"*!"#$%'!*,$)',%*#2!,0),0!*** 8,)9/"#$"2*+/*.:'"2,*!"#$%3!--!40*2%)%&-)**

! Agile Manifesto voor So"ware ontwikkeling WIE IS EEN AGILE TESTER? EEN HONDENLEVEN

!

De laatste tijd heb ik gemerkt dat verschillende firma’s op zoek zijn naar het profiel van Agile Testers. Dus, dat betekent dat er ook een definitie zou moeten bestaan van wat een agile tester nu precies is, een functieomschrijving. Dat deel maakte me wel nieuwsgierig. Wanneer ben je nu eigenlijk een agile tester? Is er iets dat je nodig hebt om een agile tester genoemd te worden? Welke karaktertrekken zijn belangrijk om in passen in een agile proces? Geïntrigeerd door deze vragen, heb ik wat onderzoek hiernaar gedaan. Daarbij heb ik ontdekt dat er sport is die Agility noemt. En als ik dan wat verder onderzoek deed naar deze sport, merkte ik dat deze sport nauw aansluit bij wat ik agile testing noem. Agility is inderdaad de hondensport waarbij deze een volledig parcours doorlopen met verschillende obstakels en hindernissen, en dit op de meest efficiënte manier. Om dit te kunnen doen moeten de honden

PAGE 2

!


7 AUGUSTUS 2008

een grote beweeglijkheid hebben en ‘nimble’ zijn. Ik gebruik specifiek het Engelstalig woord aangezien dit de lading perfect dekt. In Encarta dictionary kan je vinden dat ‘Nimble’ het volgende betekent: ‘Fast, agile and light in movement’, maar ook ‘Able to think quickly and clevery.’ Betekent dit dan dat agile testers vergeleken kunnen worden met honden?? Nu, het leven van het tester in het algemeen lijkt soms wel op een hondenleven natuurlijk. WAAROM EEN CHECKLIST? Ik had verscheidene redenen om deze checklist op te stellen. De eerste reden was om voor mezelf uit te maken hoe een agile tester nu in mekaar zit als persoon. Samen hiermee kwam de tweede reden; aangezien ik geloof dat testers een bepaalde ‘mindset’ hebben, ben ik altijd op zoek naar de persoon achter de skills van tester om deze mindset te kunnen bepalen. Tijdens een interview met een mogelijke kandidaat is het makkelijk om te spreken over de technische vaardigheden en de testing skills. Maar, wie is nu de persoon die tegenover mij zit? Wat bepaalt of hij of zij een goede tester is als persoon, meer bepaald voor de functie die ik op die moment in gedachten heb? Dit zijn ook de momenten waarop ik een checklist voor agile testers kan gebruiken, gedurende dergelijke interviews. En de derde reden is om agile testers een mogelijkheid te geven van een zel$eoordeling te doen, door een inzicht te geven in de (persoonlijke) skills die vereist zijn en hun feitelijke score op deze lijst. Dus, voor mij werd deze checklist een werkinstrument, een handleiding om een beter agile tester te worden zonder enkel aandacht te geven aan technieken en methodologieën, maar meer op de menselijke aspecten hiervan. DE CHECKLIST Ik hou van mijn klant De klant – niet noodzakelijk de eindgebruiker van het product – speelt een centrale rol in agile projecten, aangezien deze rol verantwoordelijk is voor het verzekeren dat de juiste oplossing gebouwd wordt door: •

De visie te voorzien die het product stuurt

•

Het project te sturen via specifieke beslissingen over de volgorde van taken gebaseerd op een kosten-baten analyse van elk onderdeel van het te bouwen systeem

•

De requirements duidelijk en volledig te omschrijven op het juiste moment en met het juiste level van detail

De klant is ok verantwoordelijk voor de beoordeling dat het systeem correct gebouwd werd door: •

Acceptatiecriteria en -testen te definieren die de productontwikkeling sturen

•

Het testen van het opgeleverde systeem (The Customer Role in Agile Projects - Workshop Position Paper by Jennitta Andrea)

Zoals je kan zien is het beter van je klant graag te zien dan slechte gevoelens te hebben. Daarom helpt het om als tester verbonden te zijn met je te testen object en de omgeving waarin je werkt. Als je de op te leveren oplossing niet ondersteunt of je niet op je gemak voelt met de requirements, is het soms erg moeilijk om motivatie en gedrevenheid te tonen. Agile projecten benadrukken het feit dat iedereen een onderdeel van de ketting is die het product uiteindelijk oplevert. Dus, wanneer je niet geïnspireerd bent, kan het zijn dat je de zwakste schakel wordt, diegene die over het gehele project vertraging met zich meebrengt.

PAGE 3

!


7 AUGUSTUS 2008

Ik werk op een zeer gestructureerde manier Agile projecten worden over het algemeen chaotisch, hectisch en zeer veranderlijk genoemd. Ik zal niet ontkennen dat dit ook vaak zo lijkt. Maar, mijn punt is dat binnen deze chaos, je aardig wat structuur nodig hebt om de organisatie in orde te houden en het proces volgens de planning te laten verlopen. Een vroegere collega van mij had de volgende mening over dit onderwerp: ‘Voor mij is agile testing een extreme vorm van gestructureerd testen. Het volgt van zeer nabij op voorhand gedefinieerde ontwikkelings packages die getest moeten worden. Deze ontwikkelings packages moeten gedefinieerd worden met een korte oplevertermijn (a(ankelijk van het project, maar meestal in termijnen van 1 a 2 weken) binnen de ontwikkel- en testafdeling om een kwalitatief product te kunnen opleveren op het einde van de iteratie. Zeer dikwijls definieert de klant de ontwikkelings packages samen met de leverancier om een invloed te kunnen uitoefenen op de meest dringende functionaliteiten voor de markt. Dit kan zelfs leiden tot een gefaseerde betaling aan de leverancier. Dagelijkse standup meetings worden vaak gebruikt om een precieze opvolging te hebben. Voor mij is dit de manier om grote projecten te hanteren in kleine opleveringen en om snel een return on investment te hebben. Voor mij is dit niet de manier om continue veranderingen vanuit de ontwikkelaars te hanteren. Dat zou ongecontroleerd testen zijn’. (Anneliese van Egghen - CTG). Ik zou het zelf niet beter kunnen zeggen. Ik bewonder onconventionele test tools Een aantal jaren geleden al las ik een artikel van James Bach, ‘Boosting your testing super powers’. Daarin stond een onderdeel over het gebruik van een transistor radio als test tool. Dit was om te checken of het programma al dan niet vastgelopen was via het storingsignaal op de frequenties. Het hoeft natuurlijk niet altijd zo extreem te zijn. Er zijn voldoende tools die niet als test tool omschreven worden en toch zo kunnen ingezet worden. Ik denk dat bijvoorbeeld aan CSV editors, screen cams, monitoring tools en mind mapping tools, die bijvoorbeeld kunnen ingezet worden bij de testvoorbereiding. De meeste van deze tools kunnen trouwens gratis gevonden worden op internet. De agile omgeving biedt de mogelijkheid aan de testers om deze tools te gebruiken, als ze hun toegevoegde waarde kunnen bewijzen voor het eindresultaat van de testactiviteiten. Naast deze reeds bestaande tools, worden er ook veel programma’s fit for purpose geschreven. Programmeertalen als Ruby en Python worden hiervoor vaak ingeschakeld in agile omgevingen. Ik communiceer vanuit een open positie Communicatie is cruciaal in testen, en vooral in agile testing. Zoals reeds eerder vermeld werd verkiezen agile projecten oplossingen te leveren aan klanten, boven het schrijven van documenten over de op te leveren oplossing. Daarom moeten de teamleden met elkaar spreken om de informatie te versturen en te ontvangen die ze nodig hebben om hun job uit te oefenen. Zowel gesproken als geschreven vormen van communicatie zijn belangrijk. Alistair Cockburn heeft een grafiek opgesteld waarin alle vormen van communicatie worden getoond binnen een agile omgeving. Hij doet dit door de rijkdom aan informatie van het informatiekanaal te mappen op effectiviteit van de communicatie in een agile omgeving. Let ook op de verschillende niet vaak voorkomende vormen van communicatie zoals de audiotape en de videotape.

PAGE 4

!


7 AUGUSTUS 2008

Figuur 2: Communicatie in agile projecten (Alistair Cockburn)

!

Waar komt dan het onderdeel ‘vanuit een open positie’ vandaan? In agile projecten, net zoals in andere projecten, wordt een verschil gemaakt tussen de rollen van analyst, ontwikkelaar en testers. Wanneer je als tester commniceert met de andere rollen, moet je eigenlijk openstaan naar deze rollen en niet enkel naar je eigen rol. De communicatie moet een interactie worden tussen de verschillende rollen. Ontwikkelaars worden betrokken op het terrein van de tester, analysten worden betrokken bij development en omgekeerd. Ik ben een VIP in mijn project team, net als de anderen Zoals vermeld in de intro van deze paper, een van de principes van de Agile Manifesto zegt dat ‘Individuen en interacties hoger ingeschat moeten worden dan processen en tools’. Elisabeth Hendrickson zegt dit ook in haar presentatie: ‘Ik werd geapprecieerd als tester! Wow, dit was nieuw voor mij!’. In agile omgevingen wordt de bijdrage van elk persoon aan het eindproduct sterk geapprecieerd. Het team bevat mensen, elk met hun capaciteiten die samengebracht worden door interactie. Een goed agile project haalt het beste boven bij elk individu, om het groter doel te eren. Daarom wordt de verloning en erkenning gedaan op een gelijkwaardige, edoch individuele manier, ona(ankelijk van de rol die opgenomen wordt in het project. Ik dek mezelf niet continu in Dit is het onderdeel waar documentatie een belangrijke rol speelt. ‘Werkende software boven allesomvattende documentatie’ wordt er aangehaald in het Agile Manifesto. Als je binnen een project de vraag stelt ‘Wat zijn de belangrijkste redenen om documentatie op te zetten?’ krijg je in zowat 90% van de gevallen antwoorden als ‘Ik doe dit om informatie door te geven, om een overeenkomst te hebben over de inhoud’ of ‘Om een databank van permanente documentatie op te bouwen’.

PAGE 5

!


7 AUGUSTUS 2008

Een van de hoofdredenen voor het opzetten van al deze documentatie is om onszelf in te dekken in tijd van nood. Het opstellen van documenten en hun review proces zijn nuttig, wanneer ze correct gebruikt worden. Ik sprak over het verminderen van de afval in de intro van deze paper. Overhead in documentatie is een onderdeel van deze afval. Het testplan kunnen we hier als voorbeeld gebruiken. In de meeste gevallen zijn de precondities en de voorgedefinieerde scope hiervan een onderdeel. Als we deze erg strikt definieren, nemen we de flexibiliteit onmiddellijk weg van de testactiviteiten. Deze scope en precondities houden altijd het risico in van naar verwezen te worden als er iets fout gaat en je hebt geen zin om de schuld op je te nemen, ook al is het je fout. Oplossingen voor problemen worden voorzien door het hele team in agile omgevingen. Er wordt geen - schaarse - tijd gespendeert om de schuldige te zoeken om deze met een blaam naar huis te sturen. De samenwerking tussen de verschillende teamleden is sterker dan de controlepunten die ingebouwd worden door de verschillende rollen ten opzichte van mekaar in veel gevallen.Entry en exit criteria zijn een ander perfect voorbeeld. Ik ben er van overtuigd dat deze echt wel nodig zijn, maar ze mogen niet misbruikt worden om te komen tot een spel van ‘Het was niet mijn fout’ of ‘Ik wist het’. Ik ken mijn grenzen Testen in een agile omgeving heeft het risico van chaotisch, ongestructureerd en ongecontrolleer te worden. Het is erg moeilijk om deze grens niet te overschrijden in agile omgevingen. De tester, net als de andere rollen, geniet van de vrijheid gecombineerd met een groot aantal verantwoordelijkheden. Als we in deze context over grenzen spreken, hebben we het over zowel de inhoudelijke grenzen als deze wat tijd betreft. Agile omgevingen zijn gekend voor hun opleveringen van kleine onderdelen van de uiteindelijke oplossing, ook wel incrementen genoemd. De inhoud van deze incrementen wordt overeengekomen vor de start van elke release. Als tester is het cruciaal van deze grenzen te begrijpen en zeker te respecteren. Het niet respecteren van deze grenzen zou overhead creëren bij het analyseren en doorsturen van mogelijke issues die gevonden worden. Het bepalen van wat niet in scope is, is minstens even belangrijk als het bepalen wat wel in scope is van de testactiviteiten. Samen met de grenzen wat inhoud betreft, moet er ook een testplanning opgesteld worden voor elk increment. Time boxing is een techniek die vaak bij gebruikt wordt bij agile projecten. Gedurende de testactiviteiten is het belangrijk om het tijdsschema strikt te volgen en mogelijke risico’s snel aanhalen als de testuitvoer niet tijdig klaar zal zijn. Dan kan er een beslissing genomen worden door het hele team om de testperiode te verlengen, of gewoon het risico te lopen van aantal testen niet te kunnen uitvoeren. Om dit soort van beslissingen mogelijk te maken, moet de tester altijd het tijdsschema respecteren. EN DAN, HET LAATSTE ITEM Normaal gezien zou ik dit onderdeel van deze paper moeten beëindigen met de nadruk te leggen op de verschillen tussen de agile testers en de testers in meer conventionele projecten. Maar, de aandachtige lezer heeft waarschijnlijk al gemerkt dat er niet echt veel verschillen zijn. Natuurlijk kan ik niet ontkennen dat testen in een agile omgeving een aantal persoonlijke skills vereist die verschillend zijn of meer verfijnd dan voor een tester in een conventioneel project. Voorbeelden hiervan zijn communicatieskills, openheid naar anderen toe en flexibiliteit. Dit zijn uiteraard ook karakteristieken die op zich geen kwaad kunnen in meer conventionele projecten. Dus, heb ik een bijkomend punt toegevoegd aan de lijst over het zijn van een tester.

PAGE 6


7 AUGUSTUS 2008

Ik ben een tester Dit is absoluut mijn favoriet item van de lijst. Boven alles, om een tester te zijn in een agile project, moet je een overtuigd tester zijn om te beginnen. Testen is een mindset; testtechnieken zijn een manier om het testtalent wat bij te schaven en meer structuur in het testen te brengen. Door agile testing te definieren als ‘Testen in een agile omgeving’ wordt het duidelijk dat een agile tester een tester is die bepaalde manieren van werken aanwendt. Het is ook zo dat bepaalde technieken die gebruikt worden in agile testing, zoals Exploratory Testing, natuurlijk aanvoelen voor een tester. Het is iets wat een tester automatisch zal doen bij het uitvoeren van zijn of haar voora$epaalde testgevallen. Als ik naar mijn eigen carriere kijk, kan ik vaststellen dat ik al agile testing technieken gebruikte nog voor ik ooit van deze term gehoord had. Dit brengt me dan ook terug naar het begin van deze paper. Het is niet door het gebruik van termen en definities dat je automatisch een tester wordt, laat staan een agile tester. TOEPASSING VAN DE AGILE PRINCIPES Net zoals bij andere methodologieën is het ook bij Agile Testen zo dat je niet altijd de full blown oplossing moet implementeren. Bepaalde aspecten kunnen gebruikt worden in bepaalde omstandigheden, a(ankelijk van het eindresultaat. Zo heb ik in het verleden ook iteraties gebruikt terwijl we in een totaal niet-iteratieve omgeving werkten. Samen hierbij hebben we Exploratory Testing gebruikt als voorbereiding op het scripted testen. Het model zag er als volgt uit:

Binnen dit model zijn er duidelijk twee onderdelen te herkennen: •

het niet-iteratieve gedeelte, en

•

het iteratieve gedeelte

Het niet-iteratieve gedeelte is geheel volgens de regels van een conventioneel project. Er wordt een scope bepaald, deze wordt ontwikkeld en na de systeemtesten volgen dan de acceptatietesten om het vervolgens in productie te zetten.

PAGE 7


7 AUGUSTUS 2008

Binnen het iteratieve gedeelte herkennen we vier onderdelen: •

Plan

•

Ontwikkel

•

Exploratory testing

•

Workshops met de eindgebruiker

PLAN Het plannen is een zeer belangrijk onderdeel in het werken met iteraties. Hierin werd er een overeenkomst gezocht tussen de plannings van eindgebruiker, development en de testafdeling. De eindgebruiker heeft uiteraard in de end-to-end planning. In de planning van verschillende iteraties werd er door testing bepaald welke gedeeltes er als eerste moesten ontwikkeld worden, om zo snel mogelijk gelinkte componenten end-to-end te kunnen testen. De developmentafdeling ging dan na hoe dit het best in hun planning paste, en zo werd er telkens een iteratie met zijn inhoud bepaald. ONTWIKKEL Binnen deze fase werd uiteraard de software die vastgelegd werd bij de planning van de iteratie ontwikkeld. Voor developers is het zeer belangrijk dat ze weten wat precies de inhoud en timing van een iteratie is, en dat ze zich hier ook aan houden. EXPLORATORY TESTING Telkens de software van een bepaalde iteratie ontwikkeld was, startte het testteam met exploratory testing. Het feit dat we exploratory testing gebruikten als voorbereiding op het scripted testen van de systeem- en acceptatietesten was cruciaal voor deze oplossing. De uitvoering van deze testen zorgde ervoor dat we de applicatie sneller leerden kennen. Gedurende deze fase werden de volgende activiteiten uitgevoerd: •

‘Ontdekken’ van het stuk van de applicatie dat al ontwikkeld was

•

Opstellen van test cases aan de hand van de documentatie, maar vooral op basis van de exploratory test cases die we uitvoeren

•

Testen van de applicatie en tevens ook loggen van de defects die we vonden tijdens deze exploratory testing fase

Door het werken met deze fases van exploratory testing ontdekten we tal van voordelen. In een ‘normale’ situatie zien de testers de applicatie pas bij het begin van de testexecutie van systeemtesten. Op voorhand dienen zij hun test cases op te stellen op basis van de documentatie die voorhanden is en met wat geluk ook op basis van een blik op een aantal schermen die reeds te bezichtigen zijn. Door het ontdekken van de applicatie verhoogde onze kennis hiervan aanzienlijk. Als gevolg hiervan zagen we duidelijk dat de efficientie van onze test cases veel hoger lag dan in een conventioneel project. Op langere termijn betekent dit dat we veel minder wijzigingen moesten aanbrengen aan de test cases tijdens de uitvoering ervan in de systeemtesten. Ook logden we tijdens het uitvoeren van deze exploratory testing reeds de issues die we tegenkwamen. Dit betekende dat de grootste issues reeds uit de software gehaald zijn voor we met de systeemtesten beginnen. Opnieuw tijdsvoordeel op langere termijn, aangezien er niets blokkerend meer werkt tijdens de systeemtesten.

PAGE 8


7 AUGUSTUS 2008

WORKSHOPS MET DE EINDGEBRUIKER Normaal gezien hebben de eindgebruikers gedurende de laatste weken voor oplevering de applicatie ter beschikking om hun testen uit te voeren. Deze testen hebben zij ook voorbereid op basis van de voorhanden zijnde documentatie. Binnen deze aanpak betrokken we de eindgebruikers in de iteraties. Telkens we een getest onderdeel van de applicatie hadden, hielden we workshops met de eindgebruikers om hen zo al op voorhand kennis te laten maken met de applicatie. Ook voor hun had dit een heel positief resultaat op de efficientie van hun test cases. Gedurende deze workshops werd ook hun feedback gevraagd zodat we deze ook hadden voor we aan de effectieve acceptatietesten begonnen. Sommigen beweren dat deze stap kan vervangen worden door prototypes, maar ik ben het hier niet meer eens. Prototypes zijn zeer handig bij het opzetten van requirements en ook voor het voorbereiden van een aantal basis testgevallen. Een werkende versie van de software daarentegen geeft een veel betere basis om een mening over te vormen. CONCLUSIE Binnen deze paper heb ik proberen aan te tonen dat agile testing in de praktijk niet om de termen en definities draait. Het is vooral een ‘doe-sport’ waarin je bepaalde karakteristieken beter kan gebruiken dan in de meer conventionele projecten. Als tester is het zeer belangrijk te weten dat je als agile tester een tester bent in een agile omgeving. Bij agile testen in de praktijk is het ook mogelijk van niet de full-blown oplossing te implenteren. In het voorbeeld dat ik heb aangehaald kan je duidelijk zien dat het toepassen van bepaalde aspecten van agile testen in de juiste context een heel flexibele oplossing kan geven voor een specifiek probleem. Erik Boelen – 05-08-2008

BRONNEN •

•

Anko Tijman – Agile Testing (Testen als teamsport)

•

Wictionary.org

•

Wikipedia.com

•

LinkedIn survey

•

Article James Bach – boosting your testing superpowers. (http://www.stickyminds.com/ sitewide.asp? Function=edetail&ObjectType=COL&ObjectId=3033&tth=DYN&tt=siteemail&iDyn=2)

Google Video – Googletalk – Elisabeth Hendrickson ((QualityTree.com) - http:// video.google.com/videoplay?docid=-3054974855576235846

•

The Customer Role in Agile Projects - Workshop Position Paper by Jennitta Andrea

•

The Agile Manifesto for software development - http://agilemanifesto.org/

PAGE 9

Agile Testing In de praktijk

Recommend Documents