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.
