Testen van de backlog: samen streven naar een goed product

De productowner is verantwoordelijk voor inhoud van story's en volgorde van backlog. En de rest van het Scrumteam voert uit. De productowner vertelt niet hoe je een story bouwt, het Scrumteam vertelt niet hoe je de story schrijft. Heel eenvoudig. Maar ook gevaarlijk. Want de developers in het Scrumteam hebben kennis. Kennis die veel problemen kan voorkomen, als je daar al vroeg rekening mee houdt. Dus wat is een beter moment om hiermee te starten, dan het moment waarop de story's geschreven en geprioriteerd worden.

Nu kan je denken: dat heet toch product backlog refinement? Je wordt er als Scrumteam bij betrokken. En aan het eind snap je de story, begrijp je de prioriteit en sta je er dus volledig achter. Voldoende toch? Tja, ik zie zelf in de backlog refinement vaak beïnvloed worden door twee factoren:

Het eerste is de expertfactor. De productowner is expert op het gebied van de business. Wat de productowner zegt, stel je niet vaak ter discussie. En dat moet je als basis ook niet willen. Ik heb regelmatig meegemaakt dat een productowner vijf keer opnieuw de discussie aan moet gaan waarom een medewerker in het bedrijf echt wel blij wordt van een bepaalde story, zoals die beschreven is. Dat gaat vaak te ver, je moet het vertrouwen hebben dat de productowner met de persoon heeft gesproken. En het gewenste doel goed kan weergeven.  Maar zomaar geloven wat de productowner qua businesseisen in de story zet, dat is toch een ander verhaal.  Een productowner is misschien wel expert, maar geen allesweter. En is net als iedereen een mens, die fouten maakt.

De tweede factor is de uitzonderingsfactor. Elk Scrumteam heeft regels en afspraken gemaakt. En op het moment van opstellen staat iedereen hierachter. Maar dan verloopt de tijd. Een teamlid had wat tijd te weinig, er is een crisis die om snelle refinement vraagt of je hebt het gevoel dat de gemaakte afspraak nu vooral tijdsverspilling is. Dan ga je een uitzondering maken. Voor deze story verbreek je de afspraak. Daarna voor alle soortgelijke story's, want je deed het bij die ene story ook. Vervolgens voeg je hier een uitzonderingsgroep aan toe, want dat kon bij de vorige groep ook. En voor je het weet, is de afspraak eerder uitzondering dan regel.

Om dit te voorkomen moet je leren om zelf en op je eigen moment de backlog de testen. Ik spreek bewust niet van review, maar van testen. Bij een review speelt persoonlijke kennis en mening een belangrijke rol. Maar dat deel kan je vaak bij de refinement wel oppakken. Bij testen leg je het gemaakte product naast een bepaald eisenpakket. En kijkt of het product eraan voldoet. Vaak op eigen gelegenheid, zodat je er goed te tijd voor kan nemen.

Het projectdoel

Elk project heeft een doel. En het doel is vaak perfect geschreven voor de managers, die het geld beschikbaar moeten maken. Vaak ook nog voldoende om het Scrumteam en andere mensen in grote lijnen in te lichten. Maar kan je als Scrumteam het projectdoel ook gebruiken om de story en de backlog te testen? Anders gezegd: zorg ervoor dat iedereen in het Scrumteam het projectdoel begrijpt. 

Waarom? Stel dat de organisatie het belangrijk vindt dat op basis van gebruikersstatistieken achterhaald kan worden wat wel en niet werkt. Dan kan het verstandig zijn om bij elke story de volgende vraag te stellen: welke handelingen moeten gemeten kunnen worden? En kan dit meteen in deze story of moet dit in een aparte story er vlak achteraa?. Ook qua prioriteit kan het verschil uitmaken. Zijn alle onderdelen eigenlijk al te meten? Zo nee, moeten de story's die dit gaan oplossen, dan niet snel opgepakt worden?

Besef dat de hier beschreven business-eis niet snel op papier wordt gezet. Hij wordt als logisch gezien. En voor management en introductiemeetings niet zo van belang. Zorg daarom dat je duidelijkheid hebt over onderdelen als onderhoudbaarheid, meetbaarheid, performance, security en foutvindbaarheid (logfiles, etc.). Weet welke van deze eisen voor de business het belangrijkste zijn, want dan weet je wat bij de story's en de backlogprioriteit ook het belangrijkste is. Daarnaast kan je zelf kijken of er nog story's missen om deze doelen te halen.

De afspraakstatistieken

Elke uitzondering los lijkt niet erg. Tenslotte is Scrum bedoelt om flexibel te zijn. Een keer op het laatste moment een story oppakken, moet kunnen. Dus als je dan een keer niet helemaal aan de regels voldoet, is Scrum daar vast voor. Het is in ieder geval wat ik vaak gehoord heb: ja maar, bij Scrum mag je de prioriteiten toch steeds wijzigen? Ja, dat mag. En ja, je mag ook uitzonderingen maken. Maar als dit verbloemt dat een organisatie slecht kan prioriteren en daarom van het ene 'het moet nu' naar het andere 'het moet nu' springt. Waardoor steeds opnieuw story's vanuit het niets bovenaan de backlog komen. Dan wordt deze Scrumregel misbruikt. En een ander voorbeeld: als het Scrumteam geen tijd heeft of zin heeft zich aan hun eigen afspraken te houden. En daarom steeds opnieuw een uitzondering afspreekt. Dan misbruik je de geboden flexibiliteit vooral om jezelf voor de gek te houden.

Het belangrijkste middel hiertegen: maak de uitzonderingen zichtbaar. Dit kost tijd, tijd die je misschien liever ergens anders aan zou besteden. Maar zeker in een tijd met veel neiging tot uitzonderingen, levert het uiteindelijk veel op. De afspraken zijn tenslotte niet voor niets gemaakt.

Zo heeft bijna elk Scrumteam wel eisen waaraan een story moet voldoen. Leg van de story's die door het team 'geschikt voor in de sprint' verklaard zijn, vast hoeveel story's ook werkelijk aan deze eisen voldoen. Neem van mij aan: als je ziet dat slechts 50% van je story's voldoet aan alle gemaakte afspraken, is het woord "uitzondering" plotseling moeilijker te gebruiken.

En zulke statistieken kan je ook gebruiken voor andere afgesproken mijlpalen met eisen, Zelf heb ik naast bovenstaande mijlpaal, ook wel eens gebruik gemaakt van de mijlpaal 'geschikt voor refinement'. Hierbij ga ik ervan uit dat alle story's die in de komende drie sprints zullen komen op basis van huidige prioriteit, aan de eisen voldoen die het Scrumteam heeft opgesteld om er storypoints aan toe te kennen. Hiervoor heb ik het gemiddelde aantal story's per sprint bepaalt en vervolgens met drie vermenigvuldigd.

Tenslotte

Leg dus je backlog en story's naast het testdoel. Bekijk statistisch of je uitzondering wel een uitzondering blijft. En zoek je eigen testen. Welke problemen loopt jouw organisatie tegen aan? Heb je genoeg kennis om zelf deze problemen bij backlog of story's aan te geven? Kan je deze problemen met statistieken inzichtelijk maken? Of kan je zelfs een hele andere oplossing vinden? Waar het om gaat, is dat je leert om problemen te voorkomen door gebruik te maken van eisen van de business en afspraken van het Scrumteam. Dit zorgt voor draagvlak en voorkomt dat je strijd als 'eenmansoorlog' wordt gezien. Veel succes!

De ridders van Agile en de zoektocht naar de heilige testgraal

Binnen de wereld van Agile en Scrum wordt het testonderwerp vaak besproken. Men is op zoek naar dé manier van testen. Je moet vooral exploritory testing toepassen.  Of nee, je moet testen vooral automatiseren. En als je automatiseert, moet je vooral BDD toepassen. Of TDD. Welke manier van testen moeten we nu gaan toepassen bij Agile of bij Scrum? Wat is de beste methode en kunnen we aan de toekomstige testers gaan leren? Maar bij mij komt eerder deze vraag op: waarom voeren we deze discussie eigenlijk?

De discussie is al ouder en werd al gevoerd voordat Agile gemeengoed werd. TMap was een grote winnaar, maar toch waren er regelmatig groepen die opriepen om die methode vooral niet te volgen. Automatisch testen kwam meer in, waardoor het handmatig testen steeds meer in twijfel werd getrokken. Was het wel nodig? Moest je het wel willen? Dat deze discussie zich daarom bij Agile herhaalde, is dan ook niet vreemd. Er kwam wel een nieuw element bij. Waar vorige discussies vooral door testexperts onderling werden gevoerd, kwam er nu een nieuwe groep bij: de Agile experts. Een groep die zeker niet alleen uit testexperts bestaat.

Het kan echt geen kwaad om de gebruikte testmethodes en -technieken af en toe is ter discussie te stellen. Om erover te praten en weer opnieuw de voor- en nadelen vast te stellen. In het kader van Agile is het zelfs handig om je af te vragen hoe een bepaalde methode of techniek met Agile gecombineerd kan worden. Het wordt gevaarlijk als men Agile en Scrum als argumenten gaat gebruiken om bepaalde manieren van testen af te keuren. Als mensen beweren dat je testen wel moet automatiseren, omdat je anders niet goed genoeg kan inspelen op de steeds opnieuw veranderende applicatie tijdens een sprint. En als je dan toch handmatig test, moet het exploritory testing zijn, andere methodes zijn niet flexibel genoeg en vragen teveel papierwerk. Als wordt beweerd, dat je op BDD over moet gaan, omdat dit de enige methode is waarmee je de business bij het testen kan betrekken. Als mensen beweren dat je juist TDD moet toepassen, omdat zo programmeurs al kunnen testen, wat de multidisciplinaire karakter van een team versterkt. Wat hier het gevaar van is? Men kijkt niet meer naar de nadelen van deze methodes.

Exploritory testing is een methode die moeilijk te leren is. Als je hem goed wil toepassen, heb je echt iemand nodig die het je leert. Veel mensen die beweren deze methode toe te passen, doen eigenlijk gewoon maar wat. Bij een team waar flexibiliteit verwacht wordt, is een methode met een lange leercurve een nadeel. Je kan niet zomaar iemand bijschakelen. Daarnaast hangt de kwaliteit zeer sterk van de ervaring af. De tester bepaalt zelf de strategie en die is niet bij iedere tester van dezelfde kwaliteit. Veel testers zijn ook juist bij deze methode niet in staat om ervoor te zorgen dat bij vakantie of ziekte het werk zomaar door een ander overgenomen kan worden. Want hoe leg je de uit te voeren exploritory testen vast? En hoe leg je het hertesten vast?  Deze nadelen heeft een ouderwets testscript niet. Een testscript uitvoeren is eenvoudig te leren en kan ook goed overgenomen worden tijdens ziekte of vakantie. Het kost wel wat meer voorbereiding, maar daarna kan iedereen binnen je team meetesten. En bijna iedere tester weet hoe je er een schrijft.

Geautomatiseerd testen heeft ongeveer dezelfde nadelen. Ik heb zelf regelmatig geprobeerd om geautomatiseerde testen over te dragen en meestal is het niet gelukt. Alleen als de testen zijn geschreven in de taal van de ontwikkelaar met de tools van de ontwikkelaar is overdracht echt realistisch. De leercurve voor automatisch testen is ook nog eens veel groter dan bij exploritory testing, omdat mensen vaak eerst moeten leren programmeren in een taal en/of een testtool moeten leren gebruiken, voor de ook maar 1 test kunnen schrijven. Daarnaast is ook de voorbereidingstijd voor een goede automatische test enorm groot. De test is misschien zo geprogrammeerd (3 x zo lang als een handmatige test?). Maar herhaalbaarheid van de test en gebruik van goede testdata is vaak een probleem. De terugverdientijd is soms vrij lang. Terwijl juist door de snelle wijzigingen in een applicatie een test soms maar 3 x kan draaien, voordat hij opnieuw aangepast moet worden. Of misschien zelfs in zijn geheel weggegooid kan worden. Handmatig testen vraagt, zeker bij exploritory testing, veel minder voorbereiding en onderhoud. En is daardoor makkelijk aan te passen aan veranderingen in de software.

TDD en BDD zijn beide technieken die eenvoudig klinken, maar moeilijk zijn. TDD goed toepassen vraagt veel van programmeurs, daarom gebruiken vele een lichtere variant van TDD. Bijvoorbeeld eerst een aantal testen schrijven, daarna programmeren i.p.v. één test schrijven en dan programmeren. Wat de voordelen van TDD weer vermindert. Daarnaast worden er heel, heel veel testen geschreven. Dit vraagt veel onderhoud. De kleinste aanpassing gooit je testen al omver. Ook is TDD erg gericht op de kwaliteit van de code van een klein onderdeel van je applicatie. Kleine, eenvoudige testen. Testen waarbij gekeken wordt of module 1 ook goed samenwerkt met module 2 worden meestal niet geschreven. Zeker niet als de onderdelen in verschillende programmeertalen zijn geschreven. Of bij verschillende bedrijven zijn ontwikkeld. Het test daarom vaak niet voldoende om vast te stellen of je applicatie in zijn geheel geschikt is voor productie. Ouderwetse functionele testen zijn juist gericht op de gehele applicatie en staan veel meer los van een bepaald onderdeel. Een ervaren tester weet ook het aantal testcases beperkt te houden, zonder daarmee minder te testen.

BDD is ook al een methode waarbij de programmeurs vaak een light variant nemen. Hoewel de methode business-eisen als basis verwacht, worden die business-eisen regelmatig niet door de business ingebracht. Ergens ook logisch. Je maakt je zo afhankelijk van mensen die niet in je team zitten. En deze afhankelijkheid wil je eigenlijk zo min mogelijk hebben. Maar als de eisen niet van de business afkomen, heeft het dan nog veel meerwaarde? Daarnaast hebben deze testen vaak een lage dekkingsgraad. De business is niet opgeleid om tot een goed dekkende testcase set te komen. En de ontwikkelaars vaak ook niet. Nu BDD vaak gebruikt wordt om testers niet of minder nodig te hebben, is hun ervaring op dit gebied vaak afwezig. Wat is het dan een voordeel als je functionele test op meer gebaseerd is dan de business-eisen, waarbij door een tester goed is gekeken naar de dekkingsgraad.

Wil ik nu naar een Agile of Scrum wereld waarin al deze technieken niet gebruikt worden? Nee, natuurlijk niet. Wat ik wil is dat we stoppen met het verheerlijken van een bepaalde manier van testen. Zeker in Agile en Scrum. Agile vraagt een flexibiliteit van een tester, waarbij je kan inspelen op veranderingen in de applicatie, in je team, in de organisatie, in het ontwikkelproces. En naar mijn mening vraagt dit om de vaardigheid om de juiste keuzes uit je testgereedschappen te kunnen maken. Daarvoor moet je de voor- en nadelen van elke manier van testen heel goed kennen. En de voor- en nadelen die elke methode heeft binnen Agile en/of Scrum. Zodat je elk moment opnieuw kan besluiten of jouw team voor jullie situatie op de juiste manier test. Zowel Agile of Scrum schrijven tenslotte bewust niet voor hoe je moet testen of programmeren of documenteren. Welk testtool geschikt is, welke programmeertaal het beste is of welke template je aan moet houden voor het opschrijven van een story. Omdat beseft werd dat dit per situatie anders kan zijn. Wanneer gaan alle Agile (test)experts dat nu ook beseffen?

Testen door vergelijken van website resultatenlijsten

Misschien ken je de situatie: je moet een website (her)bouwen. De site heeft een zoek- of vergelijkmechanisme. Het resultaat van dit zoeken of vergelijken komt van een externe leverancier en je hebt geen idee hoe ze dit zoeken of vergelijken doen. Je hebt ook geen controle over de gegevens die gebruikt worden in de testomgeving. Of het zoeken of vergelijken is ingeregeld via een tool, op een manier die niemand meer snapt. Misschien is het zelfs wel de situatie dat de code zo ingewikkeld is geworden (en niet gedocumenteerd), dat de ontwikkelaars de code niet meer volledig kunnen doorgronden. Is ook niet nodig, want het mechanisme wordt volledig hergebruikt. Hoe ga dan je testen?

Kiezen van de testmethode

De beste manier is eerst een goede beschrijving maken van de wijze waarop gezocht of vergeleken wordt. Aangevuld met een goede testdatabase. Dit kost alleen heel veel tijd. En bij een externe leverancier is dit vaak niet haalbaar, omdat je hun medewerking niet (voldoende) krijg. Zelfs als je het lukt, zal je nooit helemaal zeker weten of je alles hebt gehad.

De daarop volgende keuze is via webservices of query's, waarmee je direct de data op kan vragen. Deze kan je dan vergelijken met de resultaten die je met de website gekregen hebt. Dit vraagt veel kennis van de technische kant van de applicatie, maar is mogelijk. Probleem is alleen het volgende: hoe weet je of je de webservice juist gebruikt en of je query correct is.

De snelste oplossing wordt vaak als meest onbetrouwbaar gezien: vergelijk je resultaat met een resultaat van een ander website. Dit kan bij een herbouw project de huidige versie van de website zijn. Maar bij externe leveranciers zijn er vaak meer klanten die dezelfde leverancier gebruiken. En in heel veel gevallen ga jij op een soortgelijke manier zoeken als de andere klanten. Dus als je op de huidige versie of op de website van de andere klant gegevens invoert en daarna precies dezelfde gegevens invoert op de nieuwe website, dan kan je deze twee resultaten met elkaar vergelijken.

Dit lijkt allemaal testregels en principes te overtreden. Want hoe weet je nu zeker dat je bij dit testen geen fouten overneemt in je nieuwe applicatie? Nu, dat weet je niet zeker. Net zo min als je zeker weet dat je in je geschreven documentatie geen zoekcriterium bent vergeten. Of een vergelijkingsbereking hebt gemist. En net zo min als je zeker weet dat je de webservice foutloos hebt gebruikt. Of je query naar precies de juiste tabellen kijkt op precies de juiste wijze. Want de business zal niet in staat zijn om je documentatie of je technische implementatie goed te controleren. En als de ontwikkelaars dit echt goed konden, had jij nu niet een testprobleem.

Staat bij een van de twee de betrouwbaarheid vast, omdat de kennis wel aanwezig is, ga dan voor die methode. Maar is dit niet zo, waarom zou je dan niet kiezen voor de snelle methode? Waar het wel om gaat: als je een van beide andere methodes tot je beschikking hebt, probeer het te gebruiken om je bevindingen te controleren. Steek meer tijd in de verschillen en probeer te achterhalen waardoor het komt. Kijk of er sprake is van een fout in de nieuwe site of in de huidige site. Het uitzoeken van verschillen kost vaak minder tijd dan het uitzoeken van het totale zoek- of vergelijkingsmechanisme.

Maar bedenk ook hierbij: als een site al minimaal een jaar in gebruik is, dan is vaak de klant tevreden en het bedrijf tevreden. Dus als de nieuwe site gelijk gaat werken, hoe groot is dan de kans dat ze ontevreden zullen zijn?

Aanpak

Wat wel van belang is, is dat je de test zo betrouwbaar mogelijk maakt. Voor het gemak hou ik het vanaf hier even op een zoekmechanisme. Stel je hebt een evenementen database, die op basis van ingevoerde criteria bepaalt welk evenement voor jou interessant kan zijn. Je kan invoeren of je het evenement met kinderen gaat bezoeken, in of rond welke stad het evenement plaatsvindt, hoeveel kilometer rond deze stad het evenement mag plaatsvinden en op welke datum het evenement plaatsvindt. Bepaal dan eerst welke gegevens je per veld in wil voeren.

De Ja/Nee velden zijn het meest eenvoudig. In dit voorbeeld: bij de vraag of je met kinderen het evenement gaat bezoeken, heb je dus twee interessante waardes: ja en nee. 

Daarna komen de keuzelijsten. Stel dat in bovenstaand voorbeeld in een keuzelijst van steden slechts 1 stad gekozen kan worden. Zorg er dan voor dat in elke testcase die je gaat samenstellen, een andere stad gekozen wordt. Heb je meer testcases dan steden, probeer dan zoveel mogelijk elke stad evenveel te herhalen. Wanneer je meerdere steden mag kiezen, kies dan minimaal de volgende: 0 steden, 1 stad, 2 steden. Probeer de steden zo te kiezen, dat ze niet of nauwelijks overlappende resultaten zullen hebben. In dit geval: twee steden die ver uit elkaar liggen. Hierdoor kan je beter zien dat alle gekozen waardes ook werkelijk in de zoekopdracht worden meegenomen. Maar kies ook testcases met de omgekeerde optie: twee steden die juist heel dicht tegen elkaar liggen. Dit is vooral om na te gaan of zoekresultaten dubbel getoond worden.

Dan hou je nog de vrije velden over: het aantal kilometers en de datum. Kies voor deze velden waardes die overduidelijk andere resultaten opleveren. Als je dit niet weet, dan kan je hier hulp vragen van iemand in het bedrijf met meer domeinkennis. Deze kan je vertellen wat de meest gebruikte waardes zijn en wat vaak een ander zoekresultaat oplevert. Maar regelmatig kan je het zelf beredeneren. Neem bijvoorbeeld het aantal kilometers. Als je 2 en 3 kilometers aanhoudt, dan is de kans dat je dezelfde evenementen te zien krijgt vrij groot. Maar als je 2 en 30 kilometers aanhoudt, grote kans dat het aantal evenementen bij 30 km groter is. En qua datum: rond kerst zijn er vaak bijzondere evenementen, net als in de zomervakantie. Data in die periode geven zeer waarschijnlijk een ander resultaat.

Stel dat je zo tot de volgende verzameling gegevens komt:

Kinderen: Ja, Nee

Steden: 0 steden, 1 stad, 2 steden

Aantal kilometers: 2, 30, 100

Datum: 10 maart, 8 augustus, 25 december

Om tot een zo betrouwbaar mogelijke test te komen, zou ik aanraden al deze gegevens in elke mogelijke combinatie testen. Dus je krijgt 2 x 3 x 3 x 3 = 54 testcases. Als je over een tool of de kennis beschikt, kan je ook kiezen voor pairwise testen.  Een methode waarbij je elke combinatie van twee gegevens minimaal 1 keer test. Dit zorgt meestal voor een betrouwbare test, maar wel met flink minder testcases. Maar hoe dit werkt is een blog op zich. Er zijn wel online tools beschikbaar, die je hierbij kunnen helpen.

Als laatste stap, zoals eerder geschreven: bepaal de steden. Verdeel de steden uit de keuzelijst zo gelijk mogelijk over de testcases. Probeer testcases samen te stellen, waarbij de kans op dubbele zoekresultaten groot is. En probeer testcases te maken, waarbij de kans op dubbele zoekresultaten juist erg klein is. Als het kan: probeer ook bij de testcases voor meerdere steden steeds voor andere steden te kiezen.

Door de gegevens goed te verdelen, de combinaties te testen en de data goed te variëren vergroot je de kans alle regels, uitzonderingen en bijzondere situaties te raken. En daarmee om fouten te vinden. Is het ideaal? Nou, nee.... Maar als de ideale wijze niet kan, is het wel een heel goed alternatief.

Streven naar betere kwaliteit: minder bugevaluatie, meer procesevaluatie

Er zullen zeker testers zijn die dit herkennen: de discussie over bugs. De voornaamste vragen? Is dit een bug of niet? Staat het in de story beschreven of niet? Had een ontwikkelaar het goed kunnen bouwen of niet? Kan je een zin op twee manieren lezen of niet? Tenminste, dit zijn de vragen die ik te vaak hoor. Ik geloof niet dat deze vragen echt leiden tot de best haalbare kwaliteit. Omdat de vragen streven naar iets wat niet bereikt kan worden: 100% duidelijke communicatie voor iedereen,die iedereen hetzelfde leest en hetzelfde begrijpt.

Agile streeft er bewust naar om niet alles tot in detail te documenteren en te vertrouwen op de onderlinge communicatie. Dit heeft automatisch een aantal gevolgen voor wat wel wordt vastgelegd, zoals wat vastgelegd wordt in story's, acceptatiecriteria en andere documentatie die voor testen gebruikt wordt.

De belangrijkste gevolgen:

1. Meestal staan niet alle eisen waaraan een story moet voldoen in de story beschreven. Wat beschreven is, is vaak datgene wat je nog niet weet of wat je kan vergeten. De eisen die je al kan weten of op kan zoeken, bijvoorbeeld van voorgaande story's of standaarden, worden daarom vaak weggelaten.

2. De tekst kan vaker op twee manieren gelezen worden. Dit komt regelmatig doordat de tekst vaak een soort samenvatting is van een gesprek. Een tekst die uitgaat van voorkennis en je herinneringen. Natuurlijk streef je ernaar om de tekst door iedereen hetzelfde te laten begrijpen. Maar omdat het een hulpmiddel is bij communicatie, worden er geen uitgebreide reviews en evaluaties gehouden over de tekst. Waardoor de tekst nu eenmaal minder snel helemaal perfect zal zijn. En misschien over een maand net iets anders over kan komen.

3. Bepaalde 'eisen' mogen tijdens de sprint bediscussieerd worden, waardoor ze niet of meer open vastgelegd worden. Tijdens de sprint kan besproken worden om iets net even anders te bouwen. Vaak omdat de bedachte oplossing veel meer tijd blijkt te kosten dan gedacht. Maar een andere veelvoorkomende reden is, dat de theorie bedachte oplossing in de praktijk nog wel eens tegen kan vallen.

Om tot een goede kwaliteit te komen, moet je juist bij Agile en Scrum leren vertrouwen op het volgende principes:
1, Nieuwe functionaliteit wordt niet in een keer goed gebouwd, want de perfecte oplossing kost meerdere evaluaties en daardoor sprints
2. Wat goed genoeg is voor deze sprint bepaal je niet met alleen ontwikkelaars, je hebt er business en/of product owner voor nodig

Waar het om gaat, is dat je als team samen met de productowner overlegd, wat gezien de huidige situatie de beste oplossing is. En als story gaat over een onderdeel waar ook de productowner niet alles van weet, vraag er dan gerust iemand anders buiten het team bij om de vraag goed te beantwoorden. Het voornaamste doel is niet zoveel mogelijk bouwen, het voornaamste doel is bouwen naar tevredenheid.

Dat is allemaal leuk geschreven, maar de in het begin genoemde discussie ontstaat niet voor niets. Er is dan vaak geen tijd meer om alles naar wens te bouwen, daarvoor zijn er gewoon teveel bugs. Moet je dat dan niet voorkomen, door betere en uitgebreidere documentatie te schrijven? Dat is tenminste wel een oude les die altijd heeft gewerkt.

Als je je probleem omschrijft als 'teveel bugs hebben', lijkt wat hierboven staat inderdaad de juiste oplossing. Maar is dit dan de juiste manier van het probleem omschrijven? Wat als je 'teveel bugs' als symptoom gaat zien? Kunnen er dan andere problemen zijn?

In mijn ervaring zijn er vier belangrijke problemen die veel bugs veroorzaken. Kijk eerst of er geen sprake is van een van deze vier problemen, voordat je je documentatie uitbreidt.

1. Teveel watervalplanning
Hoeveel tijd bugfixen kost, is vaak een van de meest onbetrouwbare delen van een planning. Toch is er nog steeds de neiging om eerst zoveel mogelijk te bouwen en pas daarna tijd te besteden aan het testen, zoals bij de oude, vertrouwde waterval. Hierdoor verplaats je voor een heleboel te bouwen onderdelen het risico naar het eind van de sprint. En maak je de kans groter in tijdnood te komen, doordat er meer bugs gevonden worden dan verwacht. Dat kan je teveel noemen. Maar als je het testen meer verspreid over je sprint, heb je minder risico aan het eind. En aan het begin mogelijkheid om eventuele tegenvallers binnen de sprint op te vangen. Zelfs als je aan het eind vastloopt, heb je het grootste deel van de sprint al afgerond en goedgekeurd.

2. Testen en/of bugfixen in de planning niet meenemen
Ja, het komt echt voor. Ontwikkelaars vertellen dat ze klaar zijn op 12 september. De laatste dag van de sprint, dus mooi op tijd. Probleem: ze zijn klaar met bouwen. Maar dan moet het eigenlijk nog wel getest worden. Daar is dan geen tijd meer voor. Als je meer geluk hebt, hebben ze wel gedacht aan tijd om te testen. Maar niet aan tijd voor bugfixen of hertesten. Resultaat: bij een beetje tegenslag in bugs worden de bugs al snel teveel.

3. Teveel vertrouwen in eigen kennis en kunnen
In veel gevallen is een story toch wel minimaal twee weken voor de start van de bouw uitgebreid besproken met iedereen erbij. Twee weken is ruim lang genoeg om dingen te vergeten of je te vergissen. Toch zijn er genoeg ontwikkelaars die volledig bouwen op basis van hun herinnering. Als het niet staat beschreven, dan bouwen ze het volgens hun herinnering. En die staat niet ter discussie. Wanneer je nog meer pech hebt, bouwen ze zelfs volledig volgens hun herinnering en lezen ze zelfs wat wel beschreven staat niet meer goed door. Het is verstandig om te controleren of je herinneringen correct zijn, door de story vlak voor de bouw nogmaals goed door te nemen met alle betrokken personen. De kans dat je iets allemaal op dezelfde manier fout herinnerd, is flink kleiner. En bij discussie: gewoon navragen.

4. Alle controle na de bouw
Communicatie is heel belangrijk, juist omdat de documentatie niet alles beschrijft. Nu kan je eerst alles tot het kleinste detail afbouwen en pas daarna laten controleren of testen. Maar als het gebouwde dan niet goed blijkt, moet je heel veel aanpassen. Bugs fixen kan dan heel veel tijd gaan kosten. Je kan ook in een eerder stadium controleren of je op de goede weg bent, zodat corrigeren weinig tijd kost. Als op je scherm alle velden en teksten staan, laat het alvast zien. Wanneer een ingewikkeld proces in grote lijnen ingebouwd is, laat het alvast zien. Laat het zien op het moment dat duidelijk is wat het wordt, maar aanpassingen nog niet zoveel tijd kosten. Dit kost niet zoveel extra tijd en wint zich al snel terug.

Dit is mijn lijstje, maar dit is vast niet volledig. Kijk bij teveel bugs daarom eerst echt uitgebreid naar andere oorzaken, voordat je de documentatie uit gaat breiden. Uit mijn ervaring is gebleken, dat als je deze oorzaken oplost, de bugs misschien niet minder worden. Maar de discussie over de bugs verdwijnt vanzelf. Er is tijd om de story te verbeteren. En omdat de meeste teams wel degelijk zo goed mogelijk werk af willen leveren, zullen ze die tijd meestal ook willen besteden. Als ze het gevoel maar hebben dat die tijd ook beschikbaar is.

Tenslotte nog een belangrijk punt: hoewel in het stuk hierboven gesproken wordt over ontwikkelaars en bouwen, kunnen precies dezelfde problemen zich voordoen bij testers en testen. Ook testers kunnen er teveel naar streven zoveel mogelijk samen te testen, het hertesten vergeten bij plannen, teveel testen naar eigen herinnering of eerst alle testen uitvoeren en dan pas vragen stellen. De reden dat ik meer over bouwen schrijf is heel eenvoudig: in de meeste teams zitten meer programmeurs dan testers, dus zullen bouwproblemen vaker voorkomen. Maar kijk ook of je zelf van deze problemen geen last hebt bij een evaluatie. Je bent ten slotte als tester niet heilig.

Documenteren tijdens het testen - Gewoon doen!

Iedere tester kent de situatie: het testen wil niet lukken. Je weet als tester niet hoe het moet werken. En/of de programmeur weet niet hoe het moet werken. En/of jullie weten het allebei, maar er zijn zoveel situaties... "Oh ja, daar hadden we ook rekening mee moeten houden!" Ondertussen komt tijdens het testen de ene naar de andere fout naar boven. Of nog erger: je moet het testen opgeven of stoppen. Je kennis is op of de tijd is op en goed testen kan of mag niet meer.

Documenteren hoe iets moet werken, zeg maar functionele documentatie, was en is altijd een probleem. Er is bijna niemand die het leuk vindt. Als je geluk hebt, is er nog iemand die het bij de eerste bouw beschrijft. Maar daarna deze documentatie bij elke wijziging weer opnieuw aanpassen, is vaak teveel gevraagd. Soms is er ook nog het omgekeerde probleem: er is zoveel documentatie, dat niemand meer weet wat waar staat. Processen staan beschreven in wel 5 documenten en de documenten spreken elkaar tegen. Als men processen in de vele documentatie nog weet te vinden.

Nu wordt functionele documentatie zeker niet als taak van een tester gezien. Als er al documentatie moet worden geschreven, gebeurt dat voor het testen. En deze documentatie wordt dan tijdens het testen gebruikt. Dus de documentatiefase is bij de functionele test in principe afgerond. Maar juist tijdens het testen blijkt te vaak dat de documentatie mist of niet klopt. Zoals hierboven beschreven, blijkt dit vaak doordat er steeds opnieuw fouten naar boven komen. De belangrijkste oorzaken:

• Het ontwikkelteam is niet voldoende op de hoogte van de domeinkennis om bepaalde processen en gegevens te kunnen controleren
• De programmeurs zijn niet voldoende op de hoogte van processen en business rules in de applicatie om hiermee rekening te kunnen houden tijdens het bouwen of aanpassen van de applicatie
• Er worden regels, verwachtingen of specificaties vergeten. Nieuwe worden niet gebouwd. Bestaande worden niet meegenomen of gecontroleerd bij aanpassingen.

Waarom zou je als tester dan functionele documentatie willen schrijven? Omdat je als tester een kwalitatief goed product wil. Omdat je als tester het fix-traject wil verkorten. Omdat je als tester bij een volgende keer fouten wil voorkomen.

Nu moet je niet denken dat je plotseling de hele applicatie moet gaan documenteren, als dat nog nooit gedaan is. Het is voldoende om datgene vast te leggen wat er getest moet worden. Leg die informatie vast, die je wil testen en waarvoor documentatie nodig blijkt te zijn. Let er wel op dat je niet alleen de wijzigingen vastlegt. Leg ook de informatie vast die je blijkt te missen voor het goed uitvoeren van een regressietest.

Dit mag onzinnig lijken, want wat helpt dat kleine beetje documenteren nu? Mij is echter in de praktijk anders gebleken. Belangrijke functies worden in een bedrijf vaak aangepast of uitgebreid, waardoor ze meestal meer door een testfase heengaan dan minder belangrijke functies. De eisen en wensen voor die functies zijn namelijk zo belangrijk, dat een aanpassing sneller interessant is voor de organisatie. Hierdoor heb je automatisch het merendeel van de risicogebieden bij de belangrijke functies vaak al binnen een jaar vastgelegd. En zal je deze documentatie al vrij snel weer kunnen gebruiken, waardoor het nut zich snel bewijst.

Het allerbelangrijkste bij vastleggen van functionele documentatie: zorg ervoor dat je de documentatie zo vastlegt dat je de documentatie ook weet terug te vinden. Bij voorkeur zelfs zo dat iedereen in je ontwikkelteam de documentatie weet terug te vinden. En nog beter: dat ieder toekomstig lid van je ontwikkelteam, ook een nieuwe tester, de documentatie weet terug te vinden. De regels hiervoor:

• Kies voor een goede basis indeling. Dit kan zijn per proces, per module, per scherm, per menu-item. Maar kies een indeling die logisch is voor jouw applicatie 
• Leg informatie over een scherm of een proces maar op 1 plek vast
• Als de informatie in het ene document voor een ander document van belang kan zijn, verwijs dan in het ene document naar het andere document

Stel de documentatie bij voorkeur met hulp van de ontwikkelaar en met de eindgebruiker (of een ander persoon met domeinkennis) op. En start hiermee zeker zodra iets drie keer achter elkaar is gefaald, doordat men zaken niet wist of vergat. Houd je niet strikt aan je rol, maar ga voor de kwaliteit. Durf te documenteren!

Testen is meer dan "de race om zoveel mogelijk bugs"

Het is in: zoveel mogelijk bugs vinden in zo weinig mogelijk tijd. Er zijn een heleboel deskundigen, boeken en cursussen over, waarbij het doel soms sterk lijkt op: hoe vindt je zo snel mogelijk zo veel mogelijk fouten voor één invoerveld? Wat mij opvalt: deze testkennis wordt voornamelijk naar voren gebracht door mensen die werken in grote testteams met meerdere testers. En met een vrij groot testbudget in uren. 

Voor er misverstanden ontstaan: elke tester moet in staat zijn om dit soort testen uit te voeren. Het goed testen van invoer en validatie is een basisvaardigheid waarover een tester moet beschikken. Het probleem ontstaat als testers deze kennis gaan toepassen zonder een goede teststrategie. Als ze op het eerste scherm dat ze vinden doorgaan met testen, net zo lang totdat alle mogelijke te bedenken varianten geweest zijn. Waardoor grote fouten in scherm nummer vier pas ontdekt worden vlak voor het eind van de sprint of de deadline. Of als testers volledig losgaan op het testen van invoerschermen, maar de belangrijke processen en berekeningen in het testen naar achteren schuiven. Omdat ze deze eigenlijk moeilijk vinden om te testen of er tegenop zien.

In een groot testteam heb je vaak een zeer ervaren tester of testcoördinator, die ervoor zorgt dat de belangrijke onderdelen en moeilijke onderdelen op tijd getest worden. Je kan rustig voluit gaan testen op jouw scherm, want de rest van de applicatie goed testen, dat ligt in handen van anderen. Dit wordt anders als je alleen of met heel weinig testers in een team bent. En je daardoor niet alleen zelf moet testen, maar ook je eigen strategie moet gaan bepalen. Kan je dat wel?

Basis testvaardigheden

Als tester moet je er eerst voor zorgen dat je over genoeg testvaardigheden beschikt, om alle mogelijke verschillende onderdelen in een applicatie te testen. Je moet overtuigd genoeg zijn van je vaardigheden als tester, om in ieder geval de verleiding van afstel/uitstel te vermijden. Ik ben zelf van mening dat je minimaal de volgende vier applicatieonderdelen moet kunnen testen:

1. Een invoerscherm met bijbehorende invoer- en validatietesten
2. Een proces in de applicatie, waarin tenminste drie schermen betrokken zijn
   B.v. een proces met drie schermen: invoeren van uren, goedkeuren van uren, uitbetalen van uren
3. Een berekening met minimaal vier verschillende inputwaardes
   B.v. een factuur voor een webwinkel, waarbij het totaalbedrag van de bestelling, eventuele kortingsbonnen, klantenkorting en betaalkosten voor de creditcard tot een correct eindbedrag moeten leiden
4. Een beslisproces, waarbij de uitkomst bepaald wordt door minimaal drie verschillende factoren
   B.v. toegangsrechten in een applicatie testen, waarbij datgene wat de gebruiker mag in de applicatie bepaald wordt door zijn functie, zijn afdeling en zijn bedrijf.

Prioriteren van testen

Wanneer je voldoende testvaardigheden hebt, moet je nog weten in welke volgorde je moet gaan testen.

De basis van prioriteren is weten welk onderdeel of proces het eerst getest moet worden. In veel gevallen is deze prioritering al bekend, namelijk de volgorde van de story's. Daarom wil ik hier niet veel aandacht aan besteden. Mocht deze niet bekend zijn, dan kan je altijd hulp vragen aan een teamleider of projectleider om de juiste prioriteit vast te stellen.

Maar een prioritering bij het testen van een onderdeel of proces is ook verstandig. Wanneer je een onderdeel van de applicatie of een proces in de applicatie test, dan is het verstandig ernaar te streven om eerst de grootste fouten eruit te halen en daarna de minder grote fouten. Grote fouten kosten vaak meer tijd om op te lossen. Daarnaast kunnen ze ook bepaalde testen blokkeren. Als de "Opslaan" knop geen gegevens opslaat, kan je ook niet nagaan of gegevens goed opgeslagen worden. Hoe eerder je ze dus vindt, hoe beter!

Wat een grote fout is en wat niet kan per bedrijf en per applicatie verschillen. Het voorstel dat ik hieronder doe, zal in veel gevallen werken, maar het kan nodig zijn deze voor jouw situatie aan te passen. Ik hoop vooral dat het proces van prioritering duidelijk wordt.

Test 1: Blockers
Test de applicatie door met de Franse slag. Let nu nog niet op correctheid, let er alleen op of er foutmeldingen of fouten zijn die het gebruik van de applicatie volledig onmogelijk maken. En daarmee het testen blokkeren. Denk hierbij aan een "Volgende" knop die niet naar het volgende scherm gaat of een "Opslaan" knop die geen gegevens opslaat.

Test 2: Majors
Deze test gaat voornamelijk om de correctheid. Worden de gegevens goed opgeslagen? Worden de juiste gegevens getoond? Worden berekeningen goed uitgevoerd? Worden de juiste knoppen, menu's en invoervelden op de juiste momenten getoond? Anders gezegd: als een gebruiker geen fouten maakt, werkt de applicatie dan goed?

Test 3: Minors
De nadruk ligt hier veel op foutafhandeling. Wat gebeurt er als een gebruiker foute gegevens invoert? Wat gebeurt er als een gebruiker in een wizard besluit terug te gaan naar een vorige stap? Werkt de annuleren knop? Anders gezegd: werkt de applicatie ook goed, als de gebruiker fouten maakt?

De testbasis

Waar het om gaat, is dat je als tester niet alleen probeert om veel bugs te vinden. Probeer ook om alle onderdelen goed te testen, juist als ze moeilijk zijn. Al zal hierdoor het aantal bugs per uur afnemen, de test is zeker niet minder belangrijk. En streef ernaar om de grootste bugs het eerst te vinden, om het ontwikkelproces en het testproces zo soepel en snel mogelijk te laten verlopen. Als je beide kan, dan kan je desnoods als enige tester in het hele bedrijf toch goed testwerk afleveren.

Als een senior tester niet voldoende is.....

Als je als beginnend tester wil leren als tester, dan is alles simpel. Je gaat gewoon naar een senior tester. Testen leer je van collega's, wat anders? Maar dan kom je in aanraking met Scrum, met Agile. Plotseling moet je veel meer dan testen. Je bent misschien geen beginnend tester meer, maar wel een beginnend Scrummer. Je moet niet alleen heel anders testen. Nee, je moet opeens ook heel anders overleggen, om samen met programmeurs tot een aanpak van een story te komen. Je moet mensen corrigeren, omdat je als groep verantwoordelijk bent voor het nakomen van de afspraken. Je moet misschien programmeurs coachen, om ze ook te laten testen. Je moet opeens veel meer.

Dan blijkt de senior tester ook niet van alle markten thuis. Wel goed in samen werken met de programmeurs. Maar minder goed in samenwerken met de productowner. Die is echt nooit tevreden. Hoe vaak je ook afspreekt: dit is hoe het gebouwd gaat worden, die wil toch steeds weer wat anders. "Dit is niet goed genoeg! Dit moet aangepast worden!". En de senior tester gaat er maar in mee. Tenslotte moet de productowner akkoord gaan, toch? Dat is toch Scrum? Dat is toch Agile? Gelukkig is er een programmeur in het team, die grijpt op een bepaald moment in. Stelt de juiste vragen: "Wat wil je nu? Wil je de volgende story in je sprint ook nog bij de oplevering naar productie? Of heb je liever je groene button met precies 10 pixels tussen de tekst en het pijltje in alle verschillende browsers?"

Die vaardigheden wil je ook wel leren. Toch? Tja, in de praktijk blijkt dit een ander verhaal. Als junior tester mag je alle testvaardigheden leren van een senior tester. Maar als het om vaardigheden als overleggen, overtuigen en coachen komt, lijkt het opeens minder logisch om te leren. Als junior tester merk je dat je in het ene deel van testen beter bent dan het andere. Toch probeer je meestal op alle testvlakken te leren. Zeker als je die vaardigheden nodig hebt voor je vak als tester. Maar een junior communicator, die kiest vaak in de praktijk vooral welke communicatie hij of zij goed is en welke communicatie hij of zij vervolgens aan een ander over gaat laten. Ook al heb je al die vaardigheden als Scrummer eigenlijk nodig. Als een ander het al doet, dan is dat voldoende. Beter worden in de communicatie waar je slecht in bent, waarom zou je?

Stel dat je daar niet zo over denkt. Stel jij wil ook die productowner overtuigen. Het is vreemd, hoe Agile en functieloos we ook werken, het leertraject is vaak nog erg hiërarchisch. Als junior tester staat het je vrij om te leren van een senior tester. Je kan rustig overleggen en advies vragen. Je kan terecht bij je teamleider, je scrummaster, en misschien je testcoördinator of testmanager. Ook die staan open om je advies te geven. Maar stel dat jij als junior overtuiger leren wil van een senior overtuiger. Van die programmeur in je Scrumteam die de productowner zo goed kan overtuigen. Mag die persoon dan tijd vrij maken om jou te coachen bij overtuigen?

Ik zou zelf het liefst zien dat we binnen een team niet meer alleen elkaars topvaardigheden zouden weten. En dan bedoel ik dus nu vooral de vaardigheden die buiten de officiële specialisatie liggen, zoals op het gebied van communicatie. Mijn ervaring is dat die kennis meestal in het team wel aanwezig is. Ik zou zelf ook heel graag zien, dat we binnen het team zouden proberen deze vaardigheden van elkaar te leren en aan elkaar te leren. Leren overtuigen van een senior overtuiger. Leren plannen van een senior planner. Leren meeting voor te zitten van een senior voorzitter. En als een vaardigheid in het team niet aanwezig is, zouden we die dan niet van iemand buiten het team kunnen leren? Als het over testen gaat, is dit een vrij logische vraag. Misschien is het antwoord niet altijd "Ja", maar de vraag is logisch. Als het gaat om collega's op de regels te wijzen, iets wat velen in een Scrumteam moeilijk vinden, dan is de vraag opeens veel minder logisch. En het antwoord vrijwel gegarandeerd "Nee". Eigenlijk vreemd, want deze vaardigheden zijn vaak net zo belangrijk als testvaardigheden om een project tot een goed einde te brengen. Zo belangrijk dat ook hier zoveel mogelijk multi-disciplinair zijn, net als bij vakgebieden, hele grote voordelen heeft. Misschien wordt het tijd voor verandering......

Als Scrum de kwaliteit vermindert

Scrum wordt door sommige mensen gebracht als de oplossing voor alle problemen. Maar de praktijk valt soms anders uit. Zo kan kwaliteit ook binnen een Scrum traject erg onder druk komen te staan. En bepaalde sterke punten binnen een Scrum aanpak, kunnen juist nadelig werken voor het testtraject. De terechte vrijheid van het Scrumteam kan leiden tot een slecht product. Maar pas wel op voor je een schuldige aanwijst!

Binnen Scrum heeft het scrumteam, terecht, heel veel vrijheid om het eigen proces in te vullen. Om bijvoorbeeld een eigen Definition of Done op te stellen. Of te bepalen welke testen er uitgevoerd zullen worden tijdens de sprint. Bij veel vrijheid komt veel verantwoordelijkheid. En daarmee veel mogelijkheid om de verkeerde weg in te slaan.

Zo kan je de acceptatiecriteria gebruiken om een story die je nooit in productie zal brengen, toch goed te laten keuren. In de acceptatiecriteria staat vaak echt niet dat bij een proces dat een halve minuut kan duren, de gebruiker moet zien dat hij moet wachten. Bijvoorbeeld met een zandlopertje. Dat zo ongeveer elke gebruiker na ongeveer 10 seconden denkt dat de site niet werkt en weggaat, doet niet ter zake. Het staat niet in de acceptatiecriteria, dus de story is goed.

En je hebt als Scrum team alle vrijheid om voor een website te besluiten om deze nu even niet in verschillende browsers te testen. Een browser is voldoende. Geschikt voor mobiel komt later wel. Dat websites juist regelmatig problemen geven op verschillende browsers, zeker op mobiel, is nu niet belangrijk. Scrum is een ideale methode om je kop in het zand te steken en door te gaan. Dat mag je tenslotte ook, want je bent zelf verantwoordelijk.

Laat ik wel eerlijk blijven: kwaliteit staat misschien bij veel Scrum projecten wel onder druk. Maar situaties die lijken op bovenstaande voorbeelden zal je niet bij alle Scrum projecten zomaar tegenkomen. Naar mijn ervaring staat kwaliteit vooral onder druk bij projecten die niet regelmatig naar productie gaan. Als een applicatie naar productie gaat en de kwaliteit is slecht, dan wordt het Scrumteam vanzelf gedwongen hun kwaliteitsproblemen aan te pakken. Geen enkele organisatie accepteert dat er drie sprints achter elkaar producten worden opgeleverd, die vervolgens weer teruggedraaid moeten worden.

Het probleem ontstaat vooral bij projecten waar de gang naar productie later is. Omdat men eerst een groot deel van de functionaliteit af wil hebben. Vaak is hier sprake van herbouw van een bestaande applicatie. De nieuwe applicatie moet dan toch minimaal vergelijkbaar zijn met de oude, voordat je naar productie gaat. Waardoor kwaliteitsproblemen meer verborgen kunnen blijven. En de redenering "Dat kunnen we in een komende sprint wel oplossen"erg geloofwaardig klinkt.

Juist bij projecten met een herbouw karakter is ook de druk vanuit de organisatie groter. Men wil resultaat zien. Hoe meer nieuwe functies, hoe meer vertrouwen men in het Scrumteam heeft. Om dit vertrouwen te winnen, kan je heel eenvoudig story's met problemen toch als afgerond beschouwen. Bij de Sprint Review kan je om de problemen heen een demo geven. De problemen schuif je door, geen probleem, je hebt nog zo veel sprints.  Het resultaat van de sprint lijkt nu opeens duidelijk beter. Het probleem is alleen, dat dit de volgende sprint weer gebeurt. En de sprint erna weer. En de sprint erna weer. Op een bepaald moment heb je een volledige sprint nodig om alle problemen op te lossen. Tijd voor die sprint is er niet. En verwerken in andere sprints is moeilijk. Want op de organisatie komt dat al vrij snel over als "het team levert minder werk".

Andere manieren om veel nieuwe functies op te leveren, is om werk te besparen. En veel testtaken zijn hiervoor ideaal. Regressietesten, performancetesten, compatibiliteitstesten, ze kosten tijd. Maar niemand van de business heeft het door als je ze achterwege laat. Terwijl de extra story's zeer welkom zijn. Bouwen van nieuwe story's is ook goed zichtbaar. Testen daarentegen, je kan er nauwelijks een demo over geven. En zelfs als je het doet, de interesse is niet groot. Dat deze tijd in latere sprints, op deze manier gedacht, ook niet beschikbaar is, is van latere zorg.

Maar niet altijd is druk vanuit de organisatie de oorzaak. Veel ontwikkelaars die beginnen met Scrum hebben ook moeite om om te gaan met de vrijheid die ze krijgen. Kregen ze eerst vaak het proces voorgeschreven. En stond tot in detail de te bouwen functie uitgewerkt. Nu moeten ze het proces bijna helemaal zelf bepalen. En wat ze moeten bouwen, kan je plotseling niet meer alleen lezen... nee, je moet deze zelf bespreken . Soms zelfs zelf beslissen. Dat moet je leren, maar de tijd die hiervoor nodig is krijg je niet. Toch krijg je krijg je wel te horen dat je beslissing niet correct was; het was dan een dom besluit. Veel ontwikkelaars grijpen zo terug naar de oude papieren zekerheid: als het niet is vastgelegd, hoef ik het niet te doen. Dat geeft tenminste duidelijkheid en voorkomt dat jij fouten maakt. Het voorkomt niet dat het fout gaat, maar het voorkomt wel dat jij fouten maakt.

Is Scrum dan niet geschikt voor herbouwtrajecten? Ik denk dat iedereen mijn antwoord kan raden: natuurlijk wel! Er zijn echter in mijn ogen wel bepaalde factoren nodig om een Scrumproject te laten slagen zonder kwaliteitsverlies.

1. Een scrumteam mag door een organisatie niet onder druk gezet worden om meer story's op te leveren. Zeker niet als de organisatie niet in staat is om de kwaliteit van het tussenproduct goed te controleren.
2. Een scrumteam moet in staat zijn om zonder schuldvraag hun fouten vast te stellen. Fouten zijn niet van een persoon, maar van het team als geheel. Het doel van het vinden fouten is niet een zondebok vinden, maar het streven naar een beter product en/of proces.
3. Elk scrumteamlid moet ernaar streven om trots te zijn op de opgeleverde story. Niet alleen op zijn of haar regels code, maar ook op het eindresultaat van de story als geheel. Niet alleen op de story's waar hij of zij een bijdrage heeft geleverd, maar op alle story's. Dit zal zeker niet altijd lukken, maar het moet altijd het streven zijn.
4. Scrumteamleden moeten gemotiveerd worden om kwaliteit te leveren. En gemotiveerd worden om het proces zo in te richten dat ze sneller de gewenste kwaliteit bereiken. Juist in dit laatste moet de organisatie de tijdwinst zien, die ze zo graag willen. Als het Scrumteam eerder problemen onderschept, kunnen ze eerder en vaak sneller opgelost worden. Of de problemen zullen niet eens voorkomen. En daardoor komt er weer tijd vrij om extra story's te bouwen. Maar dan wel met de gewenste kwaliteit.

Uiteindelijk komt de kwaliteit neer op de volgende regel uit de Scrumguide: "Aan het eind van een Sprint moet het nieuwe Increment “Klaar” zijn, wat betekent dat het in bruikbare toestand is en voldoet aan de Definitie van “Klaar” gebruikt door het Scrum Team." Een Increment moet dus niet alleen voldoen aan de Definition of Done, maar ook bruikbaar zijn. Een niet erg duidelijk omschreven criterium. Maar als elk lid van het Scrumteam trots is, inclusief productowner, scrummaster, programmeur en tester, dan is het bijna zeker bruikbaar. Bij elk lid dat de bruikbaarheid ter discussie stelt, blijft het nodig om kritisch naar de kwaliteit te kijken. Want te vaak heeft dat ontevreden lid wel een heel terechte opmerking over de kwaliteit, en als gevolg hiervan vaak over de bruikbaarheid. En hiervoor moet je altijd open willen en kunnen blijven.

Regressietesten om de bugs heen

Als tester wil je altijd een goed product opleveren. Alle fouten eruit. Dus zou het testtraject simpel moeten zijn: testen, bugfixen, hertesten. Zeker bij een regessietest. In de praktijk gaat, helaas, het bugfixen niet altijd door. De meest voorkomende reden: de applicatie moet toch echt naar productie, ook al zitten er nog wat foutjes in. Niet opleveren kost de organisatie meer geld dan wel opleveren. En de verbeteringen in deze versie zijn belangrijker dan de nieuwe bugs.

Maar wat doe je dan met je regressietestscript? Een regressietest is tenslotte om vast te stellen of de delen van de applicatie die niet aangepast zouden moeten zijn, ook niet aangepast zijn. Om deze reden moet het regressietestscript, als je hem op productie uit zou voeren, altijd voor 100% slagen. In theorie tenminste. Dus volgens deze theorie moet je, als een applicatie met bugs naar productie wordt gebracht, je testscript aanpassen op deze bug. Maar daar staat tegenover: het doel van een testscript is juist om vast te stellen of je applicatie bugs bevat. De bugs je testscript inschrijven is daarmee in tegenspraak. Moet je een applicatie dan vervolgens afkeuren, omdat de bug niet meer op dezelfde manier fout gaat?

Wel of niet een bug

Om te bepalen of je je regressietestscript wel of niet aan wil passen, moet je eerst het volgende nogmaals controleren: is er echt sprake van een bug? In veel gevallen zal er eerder sprake zijn van een verbetering, meestal op het gebied van interactie. Als een gebruiker nu geen geboortedatum in kan voeren met het toetsenbord, maar wel een datum kan kiezen met de muis, is dat geen bug die naar productie gaat. Het is misschien wel een aanpassing op de eerder geformuleerde eisen.

Er is alleen sprake van een bug als de gebruiker denkt: "Dit is fout", niet als hij denkt "Dit kan beter". Stel dat een gebruiker een geboortedatum invoert op stap 1. Als hij er pas op stap 5 achterkomt dat de invoer fout was, terwijl dit al op stap 1 had gekund, is dit erg ongewenst. En ik zou als tester zeker niet aanraden om hiermee naar productie te gaan. Maar als dit toch besloten wordt, is er uiteindelijk geen sprake van een bug. De gebruiker kan de geboortedatum nog aanpassen. Een voorbeeld van een echte bug is het volgende: een gebruiker voert op stap 1 een geboortedatum invoert en deze wordt op stap 2 verkeerd getoond Ook al lijken de gevolgen minder ernstig. Ook al wordt de geboortedatum op stap 3 t/m 5 wel goed getoond. Dit is een echte bug.

Alleen bij echte fouten moet je overwegen om je regressietestscript niet aan te passen. Dit heeft alles te maken met de betrouwbaarheid van je applicatie. Als gebruiker moet je je applicatie kunnen vertrouwen. Dat is ook een van de belangrijkste redenen om een regressietest uit te voeren. Of de gebruiker na het invoeren ontzetten geïrriteerd is, omdat het invoeren erg moeilijk ging, is zeker ook het melden waard. Maar voor een regressietest van minder belang.

Daarnaast blijven verbeteringen vaak langer open staan dan bugs. Ze vragen vaak meer tijd om te bouwen en ze krijgen vaak een lagere prioriteit. Redenen waarom ze vaak naar achteren worden geschoven. En verbeteringen hebben meestal ook meer effect op je regressietest, juist omdat ze regelmatig over interactie gaan. Als je een verkeerde geboortedatum invoert en er staat in je testscript dat de foutmelding al in stap 1 moet verschijnen, maak je je testscript een flink stuk minder bruikbaar als de echte controle pas in stap 5 plaats vindt. Terwijl je deze controle toch echt wil testen. Want een verkeerde geboortedatum die geaccepteerd wordt, kan ernstige gevolgen hebben.

Wel of niet aanpassen

Bij een echte bug is de basisregel: pas je regressietestscript niet aan. Een bug moet opgelost worden en een steeds falende regressietest is een goed middel om daaraan te blijven denken. En een middel om de organisatie ervan te overtuigen dat de prioriteiten meer naar bugfixen zouden moeten verschuiven.

Maar wanneer pas je je regressietest dan wel aan? Tijd is hierbij de belangrijkste factor. Als een bug over twee weken wordt opgelost, pas je de regressietest niet aan. Maar als nu al vast staat dat de bug pas over een jaar wordt opgelost, pas je de regressietest wel aan. Want een jaar lang een falende regressietest maakt van een regressietest een onbetrouwbaar testhulpmiddel. Voor mij ligt de grens ongeveer op twee maanden wachten op een bugfix, maar deze grens kan per bedrijf en per project verschillen.

Daarnaast is van belang in hoeverre de bug de betrouwbaarheid van je regressietest aantast. Als een vrouw op een scherm plotseling met "Meneer" wordt aangesproken, kan de bug rustig twee maanden in je regressietest blijven. Je regressietest blijft voor de rest betrouwbaar. Maar als de keuze voor het geboorteland "Griekenland" het opslaan onmogelijk maakt, kan je ook het opslaan van de andere gegevens niet meer testen. Dan zal je eerder een ander land moeten kiezen.

Hoe aanpassen

Van belang is dat je nooit de fouten in je regressietest toevoegt. Houd de volgende regel aan en deel deze ook mee aan je team en andere belanghebbende: bij fouten worden de falende controles uit de regressietest verwijderd. Ze worden niet aangepast naar de foutsituatie. Zodra de bug is opgelost, wordt de controle weer toegevoegd. Dit voorkomt dat je regressietest faalt, omdat een bug opgelost is. Of omdat een fout de volgende keer net iets anders fout gaat. Om deze reden kan het zeker verstandig zijn om een openstaande buglijst bij te houden. Bij deze buglijst kan je dan noteren welke controles je opnieuw toe moet voegen aan de regressietest, om te voorkomen dat je de aanpassing vergeet.

Samenvatting

Hoe ga je om met een regressietest bij bugs? Je bepaalt of er echt sprake is van een bug: ziet de gebruiker het als een fout of als iets wat beter kan werken. Afhankelijk van het tijdstip waarop de bug opgelost gaat worden en het effect op de betrouwbaarheid van de regressietest bepaal je of er een aanpassing nodig is. En als je besluit de regressietest aan te passen, verwijder je de controles die falen. Op deze wijze vind je een evenwicht tussen "altijd blijven testen" en "trouw zijn aan je testprincipes".

Testautomatisering: Elementen herkennen in een veranderende webapplicatie

Een van de meest gehoorde problemen bij testautomatisering van een webapplicatie. Je maakt via record-and-play functionaliteit een werkend testscript. Je past hem aan en hij werkt. Er komt een nieuwe versie van de applicatie.... en je testscript werkt niet meer. De knop staat op een andere plaats. Het de naam van het invoerveld is plotseling anders. De getoonde lijst heeft een andere sortering. En jij mag het weer gaan aanpassen.

Er zijn echter manier om dit soort problemen flink te verminderen. Maar de belangrijkste les om dit doel te bereiken, vraagt misschien voor sommige testers een flinke stap: ga niet uit van record-and-play. Als record-and-play een item voor je vastlegt in het testscript, zal dit te vaak op een manier zijn die niet geschikt is voor een veranderende applicatie. Daarom zal je als tester zelf moeten leren hoe je objecten op een pagina uniek kan identificeren. Tenminste, als je je testscript meer geschikt wil maken voor veranderingen.

Leer de HTML-structuur

De eerste stap is het leren lezen van een HTML pagina. Je hoeft niet alles te snappen, je moet wel weten hoe je de structuur van een HTML pagina kan herkennen. En je moet weten hoe je in de HTML code een specifieke knop of afbeelding kan terugvinden. Elke programmeur kan je vertellen hoe je dit doet en welke tools hiervoor geschikt zijn. Om deze blog niet te lang te maken, zal ik dit daarom niet beschrijven.

Leer zelf elementen herkennen

Voor de tweede stap moet je je testautomatiseringstool beter leren kennen. Leer hoe je tool elementen kan identificeren en leer hoe je deze identificatie zelf aanpast. Hieronder staan de leerdoelen beschreven, die je, naar mijn ervaring, bij voorkeur moet kunnen toepassen. Zelf heb ik meestal gebruik gemaakt van Selenium IDE. Bij Selenium IDE kan je gebruik maken van XPath of CSS-selectors om elementen te vinden. Voor onderstaande leerdoelen zal ik dan ook alvast het XPath of de CSS-selector meegeven.

1. Een deel van de waarde van een attribuut selecteren
Een voorbeeld van een attribuut met een waarde is type="submit" . Het kan echter handig zijn om bij langere waardes slechts een deel van de waarde te kunnen selecteren. Dit is bijvoorbeeld verstandig als de naam of het id, de meest gebruikte attributen bij testautomatisering, niet bij elke versie van de applicatie dezelfde waarde hebben. Sommige programmeertalen geven een element bij elke versie een ander id of een andere naam. Dit gegenereerde deel is vaak herkenbaar door een numerieke waarde of een onleesbaar stukje met letters en cijfers. Maar bijna altijd is er ook een deel wat de functionaliteit van het element beschrijft, b.v. id="btn_zoek939"  of id="input_G4K9L_surname". Als je dit deel van de waarde gebruikt, is het niet nodig om elke versie je testscript aan te passen.

HTML-code = <INPUT id="input_G4K9L_surname">
XPath = //INPUT[contains(@id,'surname')]
CSS-selector = input[id*=surname]

2. Tekst herkennen
Tekst op een HTML pagina is niet bepaalt een vast gegeven. Teksten worden regelmatig aangepast. Daarom is tekst vaak niet verstandig om te gebruiken bij het identificeren van elementen. Er zijn echter uitzonderingen op deze regel. De meest voorkomende hiervan is "selecteren op basis van gegevens". Soms moet je in b.v. een filterlijst of een zoekresultatenlijst altijd een bepaalde waarde selecteren of openen. Bijvoorbeeld in een filterlijst wil je altijd "Duitsland" selecteren. Of in een tabel met aangeboden producten wil je altijd de stofzuiger openen. Als deze concrete waarde nergens in een attribuut terug te vinden is, dan zal je het element voor deze keuze aan de hand van de tekst moeten herkennen.

HTML-code = <TD>Stofzuiger</TD>
XPath = //TD[contains(text(),'Stofzuiger')]

3. Het zoveelste attribuut selecteren
Als er op een pagina lijsten voorkomen, bijvoorbeeld tabellen voor een productkeuze of checkboxlijsten voor filteren, is het soms moeilijker om een element te vinden. Als je altijd de eerste optie kiest, zal dit vaak niet veel problemen opleveren. Maar het is regelmatig ook verstandig om (ook) de derde of zevende te kiezen. Dan moet je kunnen tellen om een element te herkennen.

In een andere situatie heb je soms elementen onder elkaar, die hele verschillende gegevens bevatten, maar op geen enkele manier uniek te herkennen zijn. In een tabel staat bijvoorbeeld in de eerste kolom de naam van een persoon, in de tweede kolom het adres en in de derde kolom het telefoonnummer. Maar alle teksten staan in het standaard HTML-element voor een kolom, namelijk <TD>. Ook dan moet je, om het adres te kunnen controleren, weten hoe je het tweede <TD> element moet selecteren. In onderstaande uitwerking wordt van deze situatie uitgegaan.

HTML-code= <TR><TD>Jan de Visser</TD><TD>Damplein 4</TD><TD>0123-456789</TD></TR>
XPath = //TR/TD[2]
CSS-selector = tr>td:nth-of-type(2)

4. Terug naar de parent
Het is verstandig om de identificatie van een element zo dicht mogelijk bij het element zelf te houden. Hoe dichter je namelijk bij het element blijft, hoe kleiner de kans dat wijzigingen in de opmaak een wijziging in je testscript veroorzaken. Als je de vierde rij in een tabel selecteert, begin je daarom bij voorkeur bij het selecteren van de tabel en ga je daarna naar de vierde rij.

Maar stel dat je vanaf het geselecteerde element steeds naar het element kijkt waar dit element een deel van uitmaakt, ook wel de parent genoemd. En daarna weer naar de parent van de parent. En dan naar de parent van de parent van de parent. Soms kunnen al die elementen zo algemeen beschreven zijn en zo vaak voorkomen, dat je een hele lange rij van parents hebt, voor je een uniek element kan vinden. Dan kan het verstandig zijn om niet naar de parent te kijken, maar naar een ander uniek element in de buurt.

Stel dat je bijvoorbeeld een samenvatting van een bon hebt. Deze staat in de tabel weergegeven. Onderaan de bon staat de tekst "Totaalprijs €14,73". De tekst "Totaalprijs" staat in de eerste kolom. Het bedrag in de tweede. Je kan er dan vrij veilig vanuit gaan dat de tekst "Totaalprijs" altijd voor het bedrag zal blijven staan. En de tekst "Totaalprijs" zal waarschijnlijk ook niet zo vaak wijzigen. In je testscript kan je dan het element met de tekst "Totaalprijs" selecteren. Hierna ga je naar de parent van dit element. Vervolgens ga je dan naar het element van de totaalprijs.

HTML-code = <TR><TD>Totaalprijs</TD><TD>€14,73</TD></TR>
XPath = //TD[contains(text(),'Totaalprijs')]/../TD[2]

Blijf proberen

Als je de HTML-structuur kan lezen en de bovenstaande leerdoelen in de vingers hebt, blijf dan proberen de beste identificatie voor je elementen te vinden. Wanneer je op een bepaalde plek veel moet wijzigen, kijk dan eens of de identificatie anders kan. De belangrijkste algemene tips zijn:

1.  Blijf zoveel mogelijk van beschrijvende attributen uitgaan, die een zo klein mogelijke kans op wijzigingen hebben

2. Blijf zo dicht mogelijk bij het element zelf, door zo weinig mogelijk naar een parent te gaan

De oplossing blijft voor elke applicatie anders. Maar er is altijd wel een oplossing.

Het testeiland - Veilig van de Agile eisenwereld

Als tester werk je in de Agile wereld in een Agile team. Of twee of drie of vier. Of soms zelfs in nul teams en je bent adviseur. Je doet je werk in een rol, neem bijvoorbeeld functioneel tester. Of juist in meerdere rollen Je moet kunnen programmeren. Of je moet niet willen programmeren. Je moet andere testvaardigheden hebben, zoals performance testen, keten testen. Of je moet dit vooral aan anderen overlaten. Ik merk dat de rol van tester nu per team en per bedrijf erg sterk kan verschillen. En daarmee ook de eisen waaraan je moet voldoen. Wat is het dan heerlijk als je kan zeggen: "Ik ben functioneel tester van applicatie A, dus wat ik doe is applicatie A functioneel testen. Niets meer en niets minder" Lekker veilig op je testeiland. Wel zo duidelijk!

Ik ben zelf ook van mening dat de invulling van de rol van tester in de Agile wereld een stuk duidelijker kan. Tester is niet de meest eenvoudige rol in een Agile team. Het werk is niet altijd dagvullend. Of is meer dan dagvullend. Voor elk team een tester is niet in elk bedrijf mogelijk en twee vaak al helemaal niet. Ook bij Agile komt het vaak voor dat het meeste testwerk aan het eind ligt, de werkverdeling evenwichtig verdelen blijft moeilijk. En daarnaast heb je nog het terechte streven naar onafhankelijkheid van de tester, onder de noemer "Test niet je eigen werk". Als je in zo'n situatie je testeiland hebt gevonden, blijf je daar het liefst eeuwig op wonen.

Hoe de rol van tester beschreven kan worden, er zijn eerlijk gezegd veel ideeën over. Ik heb zelf mijn eigen ideeën, te splitsen in twee onderdelen: je rol en je kennis. Om te beginnen met je rol: naar mijn mening vervul je die rol maar in maximaal één scrumteam. Je bent in maximaal één scrumteam actief als tester, bij andere teams kan je wel betrokken zijn in een adviserende of begeleidende rol. Dit is vooral om conflicterende belangen te voorkomen. Als twee teams allebei je hulp nodig hebben om op tijd het werk af te ronden en je hebt daar de tijd niet voor, wordt je een impediment. Dan wordt het een situatie "welk team is het belangrijkste". Een situatie waar je niet in wil komen, want teams moeten zonder afhankelijkheid van elkaar hun werk op tijd kunnen afronden.

Ook in een adviserende of begeleidende rol moet je daarom geen impediment kunnen worden. Bij deze rol hoort daarom bij voorkeur geen uitvoerend werk, maar zeker geen uitvoerend testwerk. Adviserend heeft daarom de voorkeur. Maar als je specifieke kennis hebt, die het team nodig heeft, dan moet het werk vooral in de testvoorbereiding of testautomatisering liggen. Testscripts schrijven, die vervolgens binnen het team op het door hun gewenste moment uitgevoerd kunnen worden. Testwerk automatiseren, wat vervolgens binnen het team op het door hun gewenste moment uitgevoerd kan worden.

Wat kennis betreft moet het bij jou en je team liggen hoe jullie daarmee omgaan. Je moet in een Agile team starten met één bepaalde specialiteit, vaak functioneel of technsich tester. Je moet daar als basis beginnen met de kennis die voor die specialiteit nodig is. Dat is je testeiland. Datgene waar het team altijd op terug kan vallen en jijzelf ook.

Maar vervolgens moet je bereid zijn ook andere kennis op te doen of in de praktijk te brengen. En het Agile team moet bereid zijn om te kijken naar de beste oplossing voor de gevraagde kennis. Als je in een team bijvoorbeeld geen performancetester hebt, kan deze taak zowel door een tester als door een programmeur uitgevoerd worden. Het is maar net wie het meest geschikt is. De programmeur heeft bijvoorbeeld weinig werk in zijn specialisatie. Of de tester heeft eerdere ervaring met performance testen. Dit kan bekeken worden tijdens het opstellen van de planning. Of besproken worden bij een evaluatie. Wat het beste bij het team past, als je er maar regelmatig naar kijkt. Wanneer die betreffende programmeur of tester vervolgens uit het team gaat, houdt dit niet in dat de nieuwe programmeur of tester automatisch ook de performancetest moet uitvoeren. De situatie is anders, dus het team moet opnieuw kijken wat de beste oplossing is.

De beste oplossing kan ook zijn dat er leertijd gepland moet worden tijdens de planning. Tijd waarin een teamlid, bijvoorbeeld een tester, nieuwe kennis van bijvoorbeeld een tool opbouwt. Zo kan het best dat je als tester leert om te programmeren, bijvoorbeeld om Unit testen te schrijven. En misschien zelfs om stukjes applicatie te bouwen. Hier moet je mee oppassen, maar moet je zeker niet volledig tegenhouden. Wat in zo'n situatie belangrijk is, is dat er iemand anders in het team geschikt is om het door jou gebouwde werk te testen.

Het belangrijkste is dat het bedrijf niet teveel bepaalt welke rollen en kennis jij binnen een Agile team moet hebben. En bereid is om mensen de tijd te geven zich andere rollen en kennis eigen te maken, als het Agile team hierdoor effectiever kan gaan werken. Het team zelf en alle teamleden los, dus ook de tester, moeten bereid zijn nieuwe kennis op te doen. Ook als deze niet direct in hun specialiteit of rol valt. De beste momenten om hierbij stil te staan zijn planningen en evaluaties. Maar het allerbelangrijkste is en blijft om je niet terug te trekken op je (test)eiland. Hoe verleidelijk en veilig dat soms ook is.

Acceptatiecriteria - Het nieuwe contract?

Eerst had je het functioneel ontwerp, bij voorkeur van punt tot punt vastgelegd en met handtekening eronder. Dat willen we vaak niet meer. Maar toch heb je enige houvast nodig, dus hebben we nu zeer regelmatig acceptatiecriteria. Geen handtekening, maar wel een meetpunt om via een acceptatietest alsnog een definitief akkoord te krijgen. Maakt dit van acceptatietesten de nieuwe handtekening onder een contract? Zijn de acceptatiecriteria het nieuwe contract? En moet je dat wel willen?

Zowel bij programmeurs en testers is heel veel vraag naar duidelijke specificaties. Logisch, de informatie uit het functionele ontwerp heb je ook nu nog nodig om tot een goede applicatie te komen. Ook om duidelijk te kunnen afspreken wat wel en wat niet geaccepteerd gaat worden. Daarom gaan we het volledige FO als scrumteam vaak proberen op te vangen in de beschrijving van de story. En met enige grote regelmaat gebeurt dit via de acceptatiecriteria in de story. Ook als tester heel handig, want je weet zeker dat je alle informatie waarop je moet testen in de story staat.

Maar is de acceptatietest nu eigenlijk wel een acceptatietest? Een acceptatietest heeft in mijn ogen voornamelijk als doel om te bepalen of het opgeleverde werk, vanuit de business en de klant gezien, naar productie kan. Dus de acceptatiecriteria moeten hier een afspiegeling van zijn. En zolang het project op tijd loopt, lijkt dit ook het geval. Totdat er tijdnood komt. Dan blijken veel lijsten met acceptatiecriteria opeens niet zo belangrijk te zijn.

Acceptatiecriteria zijn bijvoorbeeld doorgeslagen in detail. Stel je hebt een invoerveld waarbij het acceptatiecriterium is: "Bij een geldige waarde in het veld moet naast het veld een groen vinkje getoond worden". Stel nu dat er een zwart vinkje is gebouwd. Er is geen tijd meer, dus het invoerveld gaat naar productie of het invoerveld gaat niet naar productie. Het is het enige veld in een scherm, de validatie is verder goed. Er is geen enkele reden om het af te keuren, behalve de kleur van het vinkje. Neem maar van mij aan, het invoerveld wordt naar productie opgeleverd. Zelfs als het hele vinkje niet aanwezig zou zijn, het invoerveld gaat zeer waarschijnlijk naar productie. Want wat wil de gebruiker? De gebruiker wil geen groen vinkje. De gebruiker wil een invoerveld waaraan duidelijk te zien is of de ingevoerde waarde fout of goed is. Of dit wordt aangegeven met een vinkje, met een foutmelding met een rode rand om het invoerveld, de gebruiker maakt het niet uit. Waarom maakt het in de acceptatiecriteria dan wel uit?

Wat ook wordt toegepast in de acceptatiecriteria is de verwijzingen naar andere documenten. Het gebouwde scherm moet voldoen aan het design. Het moet voldoen aan het interactie-ontwerp. Of misschien zelfs voldoen aan het functioneel ontwerp. Tja, vroeger leek datgene wat in productie ging al niet volledig op het ontwerp. Zou dat nu zoveel anders zijn? Ik heb in ieder geval nog geen acceptatietest meegemaakt waarin de acceptatietester het ontwerp tot op de letter of tot op de pixel ging controleren. En bij het eerste kleine verschil zei: "Nee, dit gaat dus niet naar productie"

Het probleem is naar mijn mening dat we graag blijven bij het oude, vertrouwde, veilige watervalprincipe van een contract met handtekening. We bouwen wat voor ons is vastgelegd. Niets meer en niets minder. Als we het niet gebouwd hebben en het was ook niet vastgelegd dat we het moesten bouwen, dan is het extra. Vroeger extra tijd en geld, nu een extra story. Want het blijft dan toch een vooruitgang? Als iemand wilde afwijken was dat bij waterval eigenlijk niet toegestaan. Nu kan je de story gewoon direct prioriteren, je mag dus afwijken. Dus vooruitgang.....

Als gevolg hiervan zie ik ontwikkelaars die al vijfentwintig keer een datum invoerveld hebben gebouwd tot in detail vragen hoe het veld moet werken. Het antwoord "Kan mij wat schelen, als ik maar alleen geldige datums kan invoeren" is vanuit de business vaak het enige juiste antwoord. Maar dat antwoord mag niet. Want zo kunnen we niet bouwen of testen. Hoe moeten we anders antwoorden krijgen? Tja..... bedenk zelf het antwoord? Als je al vijfentwintig keer een datum invoerveld hebt gebouwd of getest, kan je dan niet zelf bedenken welke invoercontroles nodig zijn om aan het acceptatiecriterium te voldoen?

Maar hoe kan je dan weten of het gebouwde in een keer naar wens is? Tja, dat weet je niet. Misschien heb je een zwart vinkje gebouwd en wordt de vraag gesteld "Kan dat vinkje niet groen zijn?" Waar het om gaat is het vertrouwen dat je in je scrumteam en met de business dit soort zaken via overleg kan oplossen. Overleg veel, tijdens de bouw, tijdens de test, tijdens de acceptatietest. Als je eerst te horen krijgt "Maak me niet uit" en later "Ik wil het toch anders", zie dat niet als een nadeel van de methode. Dit is juist een van de belangrijkste redenen waarom we geen functioneel ontwerpen meer schrijven, waarom we meer Agile willen werken. Vaak weet je pas echt wat je wil, als je het voor je ziet en je er werkelijk doorheen kan klikken.

Hoe ga je je hiermee om tijdens een acceptatietest? Overleg vooral goed of het verstandig is de nieuwe wensen direct op te pakken of door te schuiven. De sprint mag niet in gevaar komen. En het blijft: als het gebouwde aan de acceptatiecriteria voldoet, mag een wijziging in het gebouwde niet de oplevering in gevaar brengen. Wanneer dit wel het geval is, gaat het gebouwde zoals het is naar productie. Zonder wijzigingen. Dit klinkt streng, maar eigenlijk willen bijna altijd alle partijen dit. Ieder vanuit hun eigen belang. Mits de acceptatiecriteria een goede weergave waren van de echte wensen.

Maak daarom van een acceptatietest een test waarin de acceptatiecriteria altijd volledig gecontroleerd worden en leiden tot een betrouwbare acceptatietest. Zorg ervoor dat de acceptatiecriteria weergeven wat de business wil. En maak van de acceptatiecriteria geen weergave van wat het scrumteam wil weten. Dit zijn twee verschillende zaken. We moeten dan ook allemaal, hoe moeilijk het soms ook is, leren om deze twee soorten beschrijvingen los van elkaar te gaan zien. En het belangrijkste daarbij is vertrouwen. Vertrouwen dat je er zonder contract met handtekening, maar met overleg, ook wel samen uit gaat komen.

Sprint 0 of "Waarom wil je niet alles automatiseren"

Sprint 0, de start van een nieuw project. Voor mij een net afgerond traject. Tot mijn eigen verbazing bestaat de voorbereiding van een nieuw project voor mij vaak uit het beantwoorden van de vraag "Waarom wil je niet alles automatiseren?" Want juist bij Scrum en Agile wil ik niet alle testen automatiseren. Maar het lijkt wel of zo'n uitspraak in tegenspraak is met alles waar Scrum en Agile voor staan.  Heb ik dan echt zo weinig kennis van Agile en Scrum dat ik die verwachting voor testautomatisering nergens terug kan vinden?

Bij de start van een nieuw project is het altijd verstandig om stil te staan bij welke testen je wil automatiseren en welke niet. Performance gaat al snel naar automatisch testen. Testen van vormgeving vaak weer niet. En bij alle testen geldt ook voor mij: bij voorkeur automatisch. Maar dan moet het wel een meerwaarde hebben. Ik blijf er bij: het automatiseren van testen is geen doel, het is een middel om goede software te bouwen en te behouden. Levert het daaraan niet of nauwelijks een bijdrage, dan automatiseer je niet.

Dat is makkelijker geschreven dan bedacht. Want levert testautomatisering niet altijd een bijdrage aan het bouwen van betere software? Nee, naar mijn mening niet. Om een extreem voorbeeld te gebruiken: je kan vijfentwintig keer in een testcase testen of een knop de gebruiker van scherm 1 naar scherm 2 brengt. Maar als dat het enige is wat je test, heeft de test geen meerwaarde. De meerwaarde is er wel als de knop je van een invoerscherm naar een controlescherm brengt, waarin de ingevoerde gegevens opnieuw getoond worden. En elke testcase voor een bepaald invoerveld bijvoorbeeld een minimum of een maximale waarde test.

Dit kunnen de meeste testers zelf wel bedenken. Maar hoe zit het in deze situatie? Stel je hebt al een test, waarin je controleert of de waarde van een veld na de klik op een knop in het volgende scherm goed wordt meegegeven.  Heb je dan de testcase "Als de gegevens correct zijn, wordt na een klik op de knop het controle scherm getoond" nog wel nodig? Als aan deze eis niet voldaan wordt, zal ook het controleren van de waarde falen. Dat maakt de test overbodig. Een reden waarom ik nauwelijks testcases opstel en zeker niet automatiseer, die de navigatie tussen schermen controleren.

En stel nu dat je de vormgeving van een applicatie nog handmatig test. En het genoemde scherm krijgt bijna elke sprint  wel extra velden. Dus bijna elke sprint worden het invoerscherm en het controlescherm bij het handmatig testen van de vormgeving meegenomen. Neem maar rustig van mij aan, dat het niet uitmaakt wie het scherm test. Iedereen zal het laten weten als na een klik op de knop het controlescherm niet verschijnt. Automatisch testen voor de eerder beschreven testcase heeft in die situatie nauwelijks meerwaarde. Die paar keer dat het scherm in een sprint niet wordt aangepast, kan je hem wel handmatig testen.

Toch zijn er situaties waarin dubbel automatiseren wel een meerwaarde heeft. Als al tijdens het programmeren kan worden vastgesteld dat de knop niet meer werkt, kan de programmeur dat direct aanpassen. En dat heeft zeker voordelen. Maar vervolgens kan de knop best wel eens alleen werken in Firefox en niet in IE. Of de knop werkt ten onrechte niet, als het invoerveld "Geboortedatum" is leeg gelaten bij de persoonsgegevens. Vaak omdat de programmeur een foute aanname heeft gemaakt. Een aanname die herhaald is in zijn eigen automatische testen. In alle beschreven gevallen heeft de testcase dubbel automatiseren een meerwaarde. In het ene geval test je nu in een andere "omgeving", namelijk IE. In het andere geval is de automatisering om het werk te laten testen door een persoon die het werk niet gebouwd heeft. Een testprincipe wat ook bij testautomatisering erg belangrijk is.

Met een eenvoudig voorbeeld klinkt het misschien allemaal zo simpel en begrijpelijk. Ik heb in ieder geval mijn best gedaan om het zo begrijpelijk mogelijk op te schrijven. Maar zeker aan de start van een project is het dat niet, de te testen functies zijn zeker niet altijd zo simpel. Probeer het wel. Bedenk welke overlap de testen hebben. Sta stil bij de directe testen, maar ook de indirecte testen, zoals het klikken op knoppen bij het controleren van de vormgeving. Bedenk of het dubbel testen, al of niet automatisch, een duidelijke meerwaarde heeft. En maak je niet teveel zorgen over fouten. Als je te veel of te weinig meeneemt in je automatische test, je project is Agile. En dat betekent dat niet alleen de business, maar ook jij van mening mag veranderen.

Regressietesten in een Scrum traject

Als je testen volledig geautomatiseerd zijn, is het regressietesten in Scrum niet zo'n groot probleem. Dat gaat automatisch. Je moet alleen een plaats vinden voor de bevindingen. Maar wat nou als de testen niet geautomatiseerd zijn? Hoe ga je dan met regressietesten om? Ze kosten tijd en gaan over meerdere story's, dus een onderdeel van de story is niet eenvoudig. In deze blog wil ik beschrijven welke opties er zijn, want de keuze ligt in dit geval vooral bij jezelf.

Basisprincipes

Het belangrijkste is om een aantal basisprincipes aan te houden en af te spreken met het Scrumteam

1. Bevindingen worden zoveel mogelijk toegekend aan een story
   Wanneer uit de regressietest een bevinding komt, moet je altijd proberen om te achterhalen welke story deze veroorzaakt heeft. Dit geeft een beter zicht op het Scrum traject, doordat alle informatie rond een story bij elkaar blijft. Dus ook de bevindingen die tijdens een story ontstaan zijn. Daarnaast kan een bevinding beter gefixed en gehertest worden, als de bouwer de story kent en de tester weet wat de oorspronkelijke wens was. Zodat je rekening kan houden met het geheel, in plaats van de gehele bevinding.
2. Regressietesten moeten door iedereen in het team uitgevoerd kunnen worden
   Juist bij regressietesten moet je flexibel kunnen zijn. Veel keuzes in de aanpak vragen om de mogelijkheid dat ook andere teamleden meehelpen in de regressietest. Daarnaast kan er bij een regressietest snel tijdsdruk ontstaan, doordat dit vaak een van de laatste testen is. Dan is het handig als je extra handen kan inschakelen. En als je de enige tester bent: jij wordt ook wel eens ziek of gaat op vakantie!

Regressietest opnemen in een sprint

De regressietest kan je op verschillende manieren een plaats geven in de sprint. Alle varianten hebben zo hun voor- en nadelen. En ze zijn of meer geschikt voor handmatig testen of voor meer geautomatiseerde testen. Combinaties zijn natuurlijk ook mogelijk.

Regressietesten niet in de sprint backlog opnemen

Je kunt de regressietesten buiten de sprint backlog laten. In dit geval neemt de productiviteit van het team aan de sprint backlog af, waardoor je minder storypoints of uren in een sprint beschikbaar hebt. Je regressietest zal niet meegenomen worden bij de planning en standup, waardoor het volledig jouw verantwoordelijkheid is. Dit is tegen het idee om het hele team verantwoordelijk te maken voor het hele ontwikkelproces. Maar het grote voordeel is wel dat deze methode altijd kan. Hoeveel ervaring je ook hebt en hoeveel handmatige testen je ook hebt. Ook bij tegenstand vanuit het team of de organisatie om de regressietest een vast onderdeel van de sprint te maken.

Regressietest als aparte story opnemen

Om van een regressietest een aparte story te maken, heb je in ieder geval enig inzicht nodig hoe vaak je de regressietest uit gaat voeren. Je kunt altijd starten met een keer aan het eind van de sprint. Afhankelijk van de doorlooptijd van de regressietest kan je besluiten deze meerdere keren per sprint uit te voeren. Zorg in ieder geval voor een aparte taak per uit te voeren regressietest. Het voordeel is dat je een losse story kan plannen en bij de standup mee kan nemen.

Maar voor een losse story is veel draagvlak nodig in de organisatie en in het team. Want losse story's kunnen uit de sprint geschoven worden. En een regressietest kan daarmee als onnodig of onbelangrijk uit de sprint schuiven. Iets wat je als tester niet wil. Probeer daarom de regressietest zo hoog mogelijk in de sprint backlog geplaatst te krijgen. Neem hiervoor bijvoorbeeld het argument: "We vinden het als team het heel belangrijk dat het opgeleverde product minimaal dezelfde kwaliteit heeft als daarvoor. Daarom willen we dit testen en de bevindingen die deze kwaliteit verminderen altijd snel oplossen."

Regressietest binnen bestaande story's opnemen

De regressietest binnen bestaande story's opnemen is het meest ideaal. De regressietest gaat mee in planning en standup. En je hoeft niet bang te zijn dat de story uit de sprint schuift. Daarnaast is met deze wijze veel eerder duidelijk bij welke story een bevinding hoort.

Maar om dit voor elkaar te krijgen moet je heel goed kunnen inschatten wat voor regressietesten er voor een story nodig zijn. Voor een kleine aanpassing wil je geen regressietest van 8 uur moeten uitvoeren. En daarnaast kan in een regressietest vaak meerdere story's getest worden. De beste methode is om per story te bepalen of je de regressietest uit wil voeren. Bekijk daarna op basis van risico en je eigen ervaring welk deel van de regressietest je uit wil voeren. Kijk hierbij bijvoorbeeld naar regressietesten waarin het binnen de story aangepaste scherm gebruikt wordt. Of regressietesten waarin voorgaande of achterliggende processen van het applicatiedeel van story getest worden. Het kan in het begin verstandig zijn om aan het eind van de sprint als vangnet nog een volledige regressietest uit te voeren.

Kies je eigen methode

Er is geen standaard ideale oplossing. Alle oplossingen hebben hun voor- en nadelen. Kijk goed naar de doorlooptijd, naar je eigen kennis, naar je team. Als je het niet weet, begin gewoon zonder de regressietest in de sprint op te nemen. Kijk of je er een losse story van kan maken en probeer dat een sprint uit. En ga voor jezelf na of je het ziet zitten of de regressietest in de bestaande story's op te nemen. Weet je niet hoe, laat deze variant dan zitten. Het belangrijkste is dat de regressietest uitgevoerd wordt, de methode is van ondergeschikt belang.

Testen van een onbekende applicatie

Het mag niet. En toch komt het voor. Een applicatie testen waarvan je niet weet hoe die werkt. Ook in de Agile wereld. Want Agile wordt soms gebruikt om geen documentatie te schrijven. Tenslotte is werkende software belangrijker. Met als gevolg dat je als tester geen idee hebt wat je moet testen. Kan je dan wel testen?

Het beste voor het testen zou zijn als je zou weigeren. Als je totaal geen informatie hebt over de applicatie, dan is goed en betrouwbaar testen eigenlijk niet mogelijk. Maar weigeren is niet altijd een optie. Soms houdt weigeren in, dat een applicatie zonder getest te zijn naar productie gaat. Of je bent in een organisatie waar ze de informatie misschien wel willen geven, maar niet kunnen geven. De kennis is in de organisatie niet meer aanwezig of erg verspreid over verschillende mensen. Dan kan het verstandig zijn om toch te testen. Naar beste kunnen gezien de omstandigheden en garantie tot de deur. Maar toch, testen is dan de beste optie.

Hoe pak je dat aan? Het belangrijkste is je insteek als tester. Waar je anders test wat je weet of op papier hebt staan, moet je nu op een meer lerende manier testen. Je test wat je weet, maar zorgt er tegelijkertijd voor dat je via vragen meer te weten komt. De door mijzelf ontwikkelde aanpak bestaat uit vier stappen:

• Testen
• Noteren
• Informeren
• Doel bepalen

Testen

Als je niets weet, begin je met testen. Dit klinkt vreemd, maar er zijn testen die je altijd kan uitvoeren. Tijdens deze testen leer je de applicatie kennen, waardoor je leert welke vragen je moet stellen en welke onderdelen je uitgebreider moet testen.

Hieronder drie voorbeelden van testen die je altijd uit kan voeren

Navigatie-items test
Klik in een menu elk menu-item of klik in een knoppenbalk elke knop aan. Test voor zover je kennis nu reikt. Hoewel bij deze test de testwaarde minder is, is het een ideale manier om voor het eerst kennis te maken met de applicatie.

Twee test
Voer in elk veld twee waardes in. Vul elke tabel met twee rijen en elke verzameling met twee waardes. Bekijk elk getoond gegeven met minimaal twee waardes. Twee is hierbij belangrijk. Hiermee voorkom je dat je fouten mist, waarbij in een functie steeds dezelfde waarde wordt gebruikt. Of dat er in een verzameling of tabel slechts 1 item wordt getoond of opgeslagen.

Leeg test
Begin bij het invoerscherm met een volledig leeg scherm. Klik op Opslaan en vul vervolgens alleen de gevraagde waarde(s) in. Klik hierna weer op Opslaan. En ga hiermee door tot de invoer geaccepteerd wordt. Als je dit al weet of kan voorspellen, ga dan naar andere schermen, waar de ingevoerde gegevens gebruikt worden. Op deze wijze kan je nagaan of de applicatie goed kan omgaan met lege waardes. Worden deze goed getoond? En kunnen deze ingevoerde gegevens later nog goed gebruikt worden.

Noteren

Het verstandigste is om het noteren vrij vlak na het testen te doen. Het kan zelfs verstandig zijn om tijdens het testen al kort aantekeningen te maken. Het doel van het noteren is om vast te leggen waar je nog kennis te kort komt. Ongeacht of je hier antwoord op kan krijgen of niet. Als je antwoord kan krijgen, kan je later verder testen. Anders dient het als basis om anderen te informeren wat je niet hebt kunnen testen. En later om aan te kaarten over welke onderdelen er een kennisgat is.

Bij het noteren zijn er onderdelen die bijna altijd om meer kennis vragen

• Berekende gegevens
• Beslissingsprocessen
• Verdwijnende en verdwijnende velden

Informeren

Informeren is twee-ledig. Het belangrijkste deel is het verkrijgen van informatie over de genoteerde onderdelen. De vragen over deze onderdelen kan je het best stellen aan gebruikers of andere niet-IT'ers die kennis hebben. Dat is het meest objectief. Daarna komt de groep IT'ers die de software niet gebouwd hebben, denk hierbij vooral aan Functioneel Ontwerpers of andere functies die de software ontwerpen of bij het ontwerpen betrokken zijn. Maar je kan soms bijvoorbeeld ook heel veel kennis bij een helpdesk vandaan halen. En als derde kan je altijd de ontwikkelaar vragen hoe het moet werken. Dit is het minst objectief en zal dan ook voornamelijk tot doel hebben de bestaande applicatie in beeld te brengen. Toch kan je ook op deze wijze fouten ontdekken, omdat een ontwikkelaar ook als hij weet wat hij wil bouwen, regelmatig toch net iets anders bouwt.

Als het niet meer mogelijk is meer informatie te achterhalen, wordt het tijd om je teamleden en eventuele andere betrokkenen te informeren. Laat aan de hand van je notities weten wat je wel en wat je niet hebt kunnen testen. En bespreek met je team en eventueel met andere betrokkenen of dit voldoende is. Zo nee, kijk dan of zij nog een mogelijkheid zien of hebben om meer informatie te achterhalen.

Doel bepalen

Na het informeren heb je meestal meer kennis van hoe de applicatie moet werken. Vervolgens moet deze kennis weer omgezet worden in testen, b.v. met testtechnieken of checklists. Je zet de nieuw verkregen kennis dus om naar nieuwe testdoelen, om vervolgens de cyclus weer opnieuw in te gaan.

Tot slot

Ideaal blijft het niet om een onbekende applicatie te testen. En het blijft goed om ernaar te streven dit te voorkomen. Maar als het toch moet kan je door te testen ontdekken wat je niet weet. Vervolgens kan je dit vastleggen en ernaar informeren. Waarna je kan bepalen hoe je verder test. Op deze wijze kom je nog vrij ver. En je hebt een beter beeld van welke kennis je niet hebt. Beide zijn waardevol, voor nu en in de toekomst.