Testen in een team in overlevingsstand

Stel je voor, je bent tester. Je wilt kwaliteit. Maar als je bugs ontdekt, krijg je ze niet opgelost. En dan hebben we het niet over een spelfout in een stukje tekst. Nee, we hebben het over critical bugs. En als je pech hebt zelfs blocking bugs. Hoe dat komt: je development of scrum team is in overlevingsstand.

Hoe herken je een overlegevingsstand?

Bugs horen als basis geprioriteerd te worden op de ernst: is een bug blocking, critical, major of minor. En deze prioritering hoort gedaan te worden door onpartijdige personen binnen de organisatie. Natuurlijk zijn er uitzonderingen, bijvoorbeeld een belangrijke deadline, maar deze uitzonderingen komen slechts zelden voor. En ook deze uitzonderingen worden bewaakt door onpartijdige personen in de organisatie.

Dus herken je aan het omgekeerde de overlevingsstand. Er wordt zeer regelmatig gewerkt aan minor bugs, terwijl je weet, dat er critical bugs nog op de lijst staan. De persoon, die de prioriteiten bepaalt, mag of wil dit niet onpartijdig doen, maar kiest de kant van de manager, de klant, het project, enz. En beide situaties zijn dus geen uitzonderingen. Nee, het is standaard. Het is soms zelfs helemaal ingeprogrammeerd in de hersens van het team en/of van andere betrokkenen. Hierop wijzen wordt misschien zelfs gezien als iets raars of ongewenst.

Hoe ontstaat een overlevingsstand?

Het volgende lijstje is gebaseerd op mijn ervaringen. Mogelijk zijn er meer oorzaken, maar dit is wat ik in al mijn jaren testervaring ben tegengekomen. En vaak is het een combinatie van meerdere factoren.

Ernstige ondercapaciteit
Het team is niet groot genoeg om de werkvoorraad goed bij te houden. Nu gebeurt het al snel, dat een team meer werk krijgt, dan het aankan. Maar dan is er nog niet altijd sprake van ernstige ondercapaciteit. Ernstige ondercapaciteit merk je aan de "creatie-datum" van het werk dat opgepakt wordt. En de "creatie-datum" is de datum waarop de bug of wens voor een wijziging voor het eerst in de organisatie is gemeld. Als je team meer dan 75% werkt aan bugs of wijzigingen, die minder dan een maand oud zijn, dan is er sprake van ernstige ondercapaciteit. Je werkt te vaak aan nieuwe zaken en kan daardoor niet goed structureel andere problemen oppakken.


Druk
De prioritering of hoeveelheid te besteden tijd wordt niet bepaalt door kwaliteit of kans op falen, maar door een deadline, een manager, een klant, een afdeling, een collega, enz. Deze kwam je al tegen bij de beschrijving van de overlevingsstand. Dat komt, omdat dit een van de meest eenvoudige is om te herkennen. En deze is bijna altijd van toepassing, als een team in overlevingsstand is. De bugs worden voornamelijk geprioriteerd op grootte van klant, deadline van het project, afwijken van een standaard, enz. Het grote gevaar is, dat dit vaak niet raar wordt gevonden. Want moet je met die zaken dan geen rekening houden? Natuurlijk wel. Het verschil is tussen reactief en preventief bugs oplossen. Bij reactief oplossen gebeurt het oplossen van bugs grotendeels in opdracht van iemand, die eigenlijk qua functie niet verantwoordelijk is voor de prioritering. Je bent dan meestal mensen tevreden aan het stellen of crisissen aan het bezweren. Bij preventief bugs oplossen, los je bugs op op basis van de prioriteit, zoals bepaalt door de persoon of personen, die in zijn functie heeft staan "Bepaal de prioriteiten van het op te pakken werk". En deze persoon maakt  of deze personen maken wel gebruik van anderen, maar is of zijn vrij om de mening van ieder ander naast zich neer te leggen. En ze doen dat ook. Als je vraagt: "Waarom pakken we dit op", is het antwoord dan ook bijna nooit "Omdat X dit wil". Dit geeft rust en geeft daarnaast ook weer de tijd om goed structureel andere problemen op te pakken.

Kennisgebrek
Men wil wel, maar men kan niet. De kennis van de applicatie is zo weinig geworden, dat bugs fixen of wijzigingen inbouwen ongeveer gelijk is aan schieten in het donker. Het is duimen, dat er niets vergeten wordt of er geen nieuwe bugs ontstaan. Dit is de meest ingewikkelde om te herkennen, want niemand kent de hele applicatie uit zijn hoofd. Maar ikzelf herken hem aan het aantal keren waarop de code het antwoord moet geven op functionele vragen. Natuurlijk, als ik een heel gedetailleerdere vraag stel: "Wat gebeurt er als ik eerst X doe, dan Y en dan Z?", verwacht ik niet dat iemand direct het antwoord weet. Maar als ik vraag "Op hoeveel plaatsen kunnen we een klant invoeren?" of "Hier werkt het op manier A en daar op manier B, wat is correct?", zou het antwoord meestal eenvoudig te geven moeten zijn. En zeker geen uur code analyse moeten vragen. Helemaal duidelijk wordt het, als mensen je vragen verkeerd beantwoorden en ze het zelf niet doorhebben. Natuurlijk, beide situaties kunnen een keer gebeuren, maar als dit (bijna) de standaard is, wordt bijna elke bouwklus aan je applicatie gevaarlijk. En kan daardoor leiden tot ondercapaciteit, doordat bij bouwklussen te regelmatig nieuw werk ontstaat. Of het leidt tot druk, omdat anderen de problemen van het bouwresultaat moeten ontdekken.

Hoe ga je er als tester mee om?

Het allerbelangrijkste advies aan testers bij een team in overlevingsstand? Ga zelf niet in overlevingsstand. Natuurlijk, je werkt wordt erdoor beïnvloedt. Je kan niet genoeg testen, de bugs, die je vindt, worden niet voldoende opgelost of je hebt te weinig informatie voor een betrouwbare test. Maar blijf zelf in ieder geval goed prioriteren. En het belangrijkste advies: prioriteer zelf! Prioriteer zelf je testwerk: wat moet het eerst getest worden, wat het tweede, wat het derde. En bepaal ook van deze taken het testbelang: welke testtaken zijn must haves, omdat ze blocking bugs voorkomen en welke zijn would haves, omdat ze trivial bugs voorkomen. Prioriteer ook zelf de bugs: welke zijn critical, welke major, enz. Leg die prioriteiten vast en leg ze zo vast, dat je ze later terug kan vinden.

En als laatste: gebruik deze prioriteiten om feedback te geven op de situatie. Geef deze feedback minimaal aan je manager en aan je team. En blijf deze feedback geven, ook als het geen effect heeft. Blijf melden, als je belangrijke testtaken niet uitgevoerd krijgt of als ernstige bugs niet opgelost worden. Maar (en dit geldt niet altijd, maar wel bij een team in overlevingsstand) meldt niets als je al je must have taken hebt kunnen uitvoeren en je alle bugs hoger dan major zijn opgelost. Dit laatste is om over te komen als iemand, die zich inzet voor belangrijke zaken. En niet als iemand, die altijd wel iets te klagen heeft. Juist in een team in overlevingsstand is hoe je overkomt heel belangrijk. Je omgeving moet begrijpen waar je voor staat. En bij voorkeur hier respect voor hebben, ook als ze je mening niet delen. Serieus genomen worden is je enige kans op verbetering.

Manieren om aan namen, adressen en andere gegevens te komen voor testdata

De beruchte adrescheck. Je moet een postcode invoeren, die werkelijk in Nederland bestaat. En het liefst nog in combinatie met een huisnummer ook. De oplossing: iedere tester heeft zijn eigen postcode en huisnummer, die steeds weer opnieuw gebruikt wordt. Elke test opnieuw. Want hoe kom je elke keer op een nieuw adres? Zeker in een tijd, waarin je ook nog eens geen werkelijke gegevens mag gebruiken? Eigenlijk weet toch iedere tester, dat elke keer dezelfde gegevens gebruiken je testen niet betrouwbaarder maakt?

Fake name generators
Er zijn websites gespecialiseerd in het creëren van valse gegevens. Deze zijn handig voor snelheid, maar hebben vaak nadelen. Zo zullen ze voor telefoonnummers in Nederland vaak 06-nummers tonen. En, als ze als postcode en huisnummer combinaties geven, zullen deze niet altijd in werkelijkheid kloppen.

Voorbeelden:
https://www.fakenamegenerator.com/gen-random-nl-nl.php
https://www.fakeaddressgenerator.com
http://www.naamgenerator.com/

De eerste twee zijn het meest uitgebreid. Ze bevatten namen en adressen en kunnen zelfs internationaal gebruikt worden. De laatste is voor Nederland het beste. Het netnummer klopt en de postcode lijkt te kloppen met het huisnummer. Al komen de namen me niet erg realistisch over. Maar dat is eigenlijk bij alle drie het geval.

Ook voor andere data zijn generatoren te vinden, bijvoorbeeld deze twee voor IBAN en BSN codes:
https://cyberwar.nl/elfproef.html
https://www.mobilefish.com/services/bankaccount_bsn_numbers/bankaccount_bsn_numbers.php?lang=nl

Top X lijsten
Om variatie te hebben in voor- en achternamen, kan je ook gebruik maken van de populaire top X lijsten op het internet. Zoek eens op de 100 populairste voornamen en de 100 populairste achternamen. En je bent zo weer 100 personen verder. Juist omdat dit veelvoorkomende namen zijn, zijn ze vaak realistischer. Maar bijzondere gevallen zal je hierdoor juist weer missen.

Bestaande sites met databanken
Om aan namen of adressen te komen, kan je ook gebruik maken van bestaande databanken. Wel is aan te raden om, als je namen gebruikt, de voornaam van de ene en de achternaam van de andere persoon te nemen. Maar het meest simpel is dit voor adressen. Denk hier aan sites, waar huizen te koop of te huur staan. Denk aan willekeurige zoekacties in Google, bijvoorbeeld "Winkel Haarlem". Wissel hier wel af in bronnen, zeker als je veel testdata gebruikt. Voor namen kan je denken aan zoekacties op nieuwsberichten. Zoek bijvoorbeeld eens op "Directeur" in de nieuwsberichten en combineer een voor- en achternaam van twee verschillende directeuren. Andere mogelijke termen zijn "Manager" of "Dominee". Ook regionale bladen bevatten vaak veel namen. Fantaseer er zelf maar op los voor meer variatie. Het voordeel is, dat je bij bestaande sites eerder een goede verhouding krijgt tussen de verschillende namen en adressen. Het is echter wel meer werk dan de bovenstaande methodes. En je moet meer letten op de anonymisering

Het verband tussen kwaliteit en klantgerichtheid

Testen is een activiteit gericht op het verbeteren van de kwaliteit van het product. Sommige testers zien misschien een groot verband met de uiteindelijke klanten en gebruikers, anderen misschien nauwelijks. Maar het is er wel. Uiteindelijk zijn het de eindgebruikers, en daarmee vaak je klanten, die het definitieve oordeel over de kwaliteit van je product vormen. Maar hoe kan je daar als tester mee om gaan? En hoe moet je er vooral NIET mee omgaan?

De situatie in het algemeen

Een applicatie wordt gebouwd voor klanten en eindgebruikers. Doel is ervoor te zorgen, dat zij tevreden zijn en tevreden blijven. Het eerste kan je nog wel achter komen. Als je klanten en eindgebruikers niet tevreden zijn, krijg je dat via een of ander kanaal vanzelf wel te horen. Tevreden blijven, is waar het probleem zit. Hier gaat het om een moeilijker terrein: hoe gaan nieuwe klanten je applicatie gebruiken en hoe gaan je bestaande klanten in de toekomst je applicatie op een andere manier gebruiken? Juist in deze tweede situatie kan je als tester veel betekenen. Wat zijn de kwaliteitsaspecten voor onze applicatie en welke zijn van belang voor onze klanten?

Wat vindt de klant belangrijk?

Het is van belang te weten wat voor je klant belangrijk is. Over het algemeen wordt bij zogenaamde kantoorapplicaties de layout niet zo belangrijk gevonden. De mogelijkheid om snel en eenvoudig gegevens in te voeren, wordt vaak veel belangrijker gevonden. Liever een snel, dan een mooi scherm. Op websites, waar thuisgebruikers gebruik van maken, is layout en vormgeving daarentegen vaak een van de doorslaggevende factoren. Als je concurrent een betere eerste indruk maakt, zullen veel klanten naar de concurrent gaan. Maar als je wat gebruikssnelheid inlevert voor gebruikersvriendelijkheid, zal daar niet snel over geklaagd worden. Het kan zelfs pluspunten opleveren.

Elke tester moet erbij stil staan welke kwaliteitsaspecten belangrijk zijn voor zijn of haar applicatie. Hoe belangrijk is gebruikersvriendelijkheid, vormgeving, performance, gebruiksgemak, leerbaarheid, enz? Als je klant zou moeten kiezen, welke aspecten zouden blijven en welke zouden overgeslagen worden? Van je testtijd moet zeker 75% besteed worden aan de belangrijkste kwaliteitsaspecten. Als dit niet het geval is, is het tijd om je teststrategie eens onder de loop te nemen. Zeker als je klanten klagen over deze kwaliteitsaspecten.

Betrouwbaarheid

Ongeacht de klant, betrouwbaarheid is altijd belangrijk. Getoonde gegevens moeten correct zijn en ingevoerde gegevens moeten goed opgeslagen worden. Maar uit mijn ervaring als tester weet ik, dat deze betrouwbaarheid vaak ter discussie wordt gesteld. Vaak ten behoeve van klantgerichtheid. Om zowel mogelijk te bouwen wat de HUIDIGE klanten NU willen, wordt alles wat daar niet in valt als minder belangrijk gezien. Als er 10 combinaties mogelijk zijn en er worden er maar 5 gebruikt, hoeven de andere 5 niet goed te werken. Dat komt tenslotte de klantgerichtheid ten goede, toch?

Nee! Klantgerichtheid gaat naast snel opleveren van gewenste wijzigingen en fixes, ook om het voorkomen van wensen voor wijzigen en fixes. De meest tevreden klant is vaak de klant die weinig te wensen heeft, omdat de applicatie aan zijn wensen voldoet en volledig naar wens werkt. Het voorkomen van wijzigingen is niet het terrein van de tester. Het voorkomen van fixes natuurlijk wel. Als er 10 combinaties mogelijk zijn, moeten ze alle 10 werken. Zodat nieuwe klanten, die een nieuwe combinatie gaan gebruiken, niet eerst een wijzigingstraject in moet, om de aangeboden functionaliteit ook werkelijk te kunnen gebruiken. En zodat bestaande klanten, die besluiten een andere combinatie te gebruiken, niet eerst contact hoeven op te nemen met een helpdesk.

Waar het op neerkomt:wat je aanbiedt, moet goed werken. En zorg er anders voor, dat je het niet aanbiedt.

Kwaliteit en deadlines

Het halen van deadlines is een van de belangrijkste aspecten van klantgerichtheid. Om deze reden wordt vaak gekeken of de applicatie niet met wat minder kwaliteit opgeleverd kan worden, om een deadline te halen. Hoe vervelend je dit als tester ook mag vinden, in veel gevallen moet je hiervoor open staan.

Maar ook hier moet je je wel in de klant blijven verplaatsen. Hoe blij een klant ook is met een product, dat op tijd opgeleverd is, die blijheid kan snel afnemen. Bijvoorbeeld als de klant vervolgens een ontzettend lang testtraject heeft, omdat de applicatie heel veel fouten heeft. Of als de gebruikers gaan klagen, omdat de applicatie duidelijke fouten heeft of langzamer werkt. Er kunnen talloze redenen zijn, waarom het halen van een deadline uiteindelijk in je nadeel kan gaan werken.

Ook hier is het van belang om te weten wat voor je klanten belangrijk is. Wat zijn ze bereid in te leveren om de deadline te halen? Minder functionaliteit, mindere vormgeving, minder performance? En daarbijhorend: wat zijn ze NIET bereid in te leveren om de deadline te halen? Soms is het verstandiger om de klant om meer tijd te vragen, dan om een product op te leveren waar ze niet blij van worden.

Mijn eigen richtlijn: elk product dat opgeleverd wordt moet een betere kwaliteit hebben dan het product ervoor. Het kan dus zijn dat het product kwalitatief beter is, door de toevoeging van nieuwe functionaliteit. Maar er iets op achteruit gaat, omdat een bestaand scherm wat foutjes bevat. In dit geval zal de kwaliteit van het product over het algemeen als hoger worden beoordeeld. Maar als de kwaliteit toeneemt, doordat een kleine, nieuwe functie is toegevoegd, terwijl je 10 bugs hebt geïntroduceerd, is het de vraag of een oplevering wel een verstandige keuze is.

Dus hoe kijk je naar kwaliteit?

Kwaliteit wordt bepaald door je klanten, voornamelijk je huidige klanten in hun huidige situatie. Maar een eerste indruk bij nieuwe klanten moet zeker niet vergeten worden. En je huidige klanten moeten zonder veel problemen hun gebruik van de applicatie kunnen wijzigen. Van belang is daarom meer te kijken naar de kwaliteitsaspecten, die belangrijk zijn, dan naar bepaalde veel gebruikte functies of invoercombinaties, die belangrijk zijn.

Waar het om gaat, ook onder tijdsdruk, is dat elke nieuwe versie van een product beter is dan de vorige. Beter in de ogen van klant. Maar natuurlijk moet het algehele kwaliteitsoordeel daarmee niet uit het oog worden verloren. Dus gebruik dit niet als excuus om eenmaal opgeleverde fouten niet op te lossen. Voor de korte termijn strategie kan opleveren met een bekende problemen verstandig zijn. Op de lange termijn moet gewoon je hele product een goede kwaliteit hebben, om weer terug te komen in de gewenste situatie. Hoe een klant je applicatie ook gebruikt, je applicatie moet gewoon een goede kwaliteit hebben.

Testen van berekeningen, die niemand meer kent

Misschien ken je de situatie. Berekeningen zijn binnen veel applicaties heel belangrijk. Maar als je vraagt: "Hoe werkt het? Dan kan ik het testen." is het antwoord "Deze berekening is te ingewikkeld. Die testen we niet." Het zou een zeer unieke situatie moeten zijn. Maar ik ben hem verschillende keren bij verschillende bedrijven tegengekomen.

Het probleem is, dat veel uitgebreide berekeningen bestaan uit vele schermen, velden, condities, enz. Velen hebben een deel gebouwd, met als gevolg dat niemand meer alles weet. En als er zoveel mogelijkheden zijn, hoe kan je dan ooit een goede, volledige test doen? Zeker als een groot deel van de kennis niet meer te vinden is?

Misschien zijn er mensen, die nu hopen op een magische formule, die dit mogelijk gaat maken. Om alvast die teleurstelling te voorkomen: die formule heb ik niet. Wat ik wel heb, is een methode, die het testen van dit soort berekeningen kan starten. En ervoor kan zorgen dat, elke keer als je de berekening test, je beter test dan de vorige keer. Testen van dit soort berekeningen is als met vele onderwerpen: je moet gewoon starten met wat je kan. Alles testen is nu een onbereikbaar doel. Maar elke keer meer weten en daardoor beter testen, is zeker de moeite waard. Alles wat je kan testen aan een zeer belangrijk onderdeel van je applicatie is altijd de moeite waard.

Achterhaal wat nog wel bekend is
In veel gevallen is er nog aardig wat bekend van de berekening. Denk hierbij niet alleen aan de berekening zelf. Denk ook aan de schermen, waar gegevens voor de berekening worden ingevoerd. Zelfs als men de berekening niet meer weet, weet men vaak nog vrij goed in welke schermen gegevens voor de berekening ingevoerd worden. Zelfs vaak ook welke gegevens gebruikt worden. Dat scheelt al erg.

Oude documentatie, zelfs al is deze niet meer actueel, kan ook helpen te achterhalen welke gegevens gebruikt worden. Natuurlijk: als iemand een deel van de berekening kent of als deze ergens gedocumenteerd is, gebruiken! Maar anders: zo veel mogelijk achterhalen welke gegevens gebruikt worden en waar deze ingevoerd worden, is een hele belangrijke start.

Creëer een lege basissituatie

Wanneer je niet meer informatie over de berekening kan achterhalen, kan de applicatie zelf je de berekening gaan leren. Hiervoor creëer je eerst een lege basissituatie. Wat houdt dit in? Je voert de gegevens zo in, dat de berekening uitkomt op 0. Om van een factuurberekening uit te gaan: aantallen zet je op "0" en bedragen zet je ook op "0". Hier is geen kennis van de berekening van nodig.

Mocht dit je niet lukken, omdat je te weinig gegevens hebt kunnen achterhalen, die de berekening beïnvloeden, start dan zoveel mogelijk vanaf "installatie". Voer alle gegevens in alsof je een nieuwe klant bent, maar voer bij alle getallen de waarde "0" in.

Test de berekeningsonderdelen 1 voor 1
Een uitgebreide berekeningen is vaak onderverdeeld in heel veel verschillende onderdelen. Dit zijn delen van de berekening, die zijn gescheiden door een "+" of een "-" teken. Of methodes, die bepalen of getal A of getal B gekozen wordt. Denk bij dit laatste bijvoorbeeld aan het BTW percentage. Deze is afhankelijk van het gekozen artikel.

In veel gevallen zijn deze onderdelen uit de user-interface te halen. Als je verschillende artikelen aan een factuur kan toevoegen, is de berekening van het artikel waarschijnlijk een lost onderdeel. Wanneer je een onderhoudstabel hebt voor verschillende BTW-percentages, wordt waarschijnlijk ergens bepaalt welke gekozen moet worden.

Ongeacht of je de onderdelen al gedeeltelijk kan raden of niet, de aanpak blijft gelijk. Voer bij een veld, waarvan je weet dat deze voor de berekening gebruikt wordt, een waarde in. Kies voor een waarde, die het eenvoudig maakt te achterhalen hoe de berekening werkt. Bijvoorbeeld "1" voor aantallen of "50" voor percentages. Voer daarna een ander veld in, dat voor de berekening gebruikt wordt. Als je een berekeningsonderdeel weet, kies een ander veld voor dat onderdeel. Als je dit niet weet, kies bij voorkeur een veld op hetzelfde scherm, zo dicht mogelijk in de buurt.

Controleer de berekening en ga net zo lang door, totdat je berekening geen "0" meer als antwoord geeft. Zorg er wel voor, dat elk ingevoerd  veld een unieke waarde heeft. Meestal zal je nu vrij eenvoudig kunnen zien, wat er berekend is. Een optelling of vermenigvuldiging van twee ingevoerde getallen is het meest voorkomend. Anders moet je nog even doorpuzzelen, door weer invoer op "0" te zetten. Als het resultaat van de berekening groter blijft dat 0, blijft dat gegeven "0". Anders voer je weer een waarde in. Waar het om gaat, is dat je een situatie probeert te creëren, waarin zo min mogelijk gegevens de berekening beïnvloeden. Zodat je eenvoudig kan zien, wat de berekening is.

Weet je een berekeningonderdeel, ga dan door tot je alle bekende velden van de deelberekening gehad hebt. Weet je niets, voer de gegevens verder 1 voor 1 in, tot het bedrag wijzigt. En herhaal bovenstaande stappen. Blijf elk veld een unieke waarde geven. Geef desnoods velden weer de waarde "0", om waardes beschikbaar te maken.

Sta tijdens dit hele proces ook bij het volgende stil: "1" is een ideale waarde om de test te starten, maar als je vermenigvuldigd met 1, blijft het antwoord gelijk. Hetzelfde geldt voor "100%" en "1:1". Dit kan dus een goede start zijn, maar wijzig deze waardes op een bepaald moment naar een andere waarde. Mogelijk mis je anders een deel van de berekening.

Niet ideaal, maar beter dan niets
Elke informatie, die je weet te achterhalen, maakt het mogelijk een deel van de berekening te testen. Dus elk gesprek of elk document kan helpen. En door steeds wat meer gegevens in te voeren, kan de applicatie zelf je ook veel leren van de berekening. Besef dat voor zo'n belangrijk onderdeel, als een berekening, betrouwbaarheid vaak zo belangrijk is, dat alle beetjes automatisch waardevol zijn.

Testtools zijn geen doel op zich!

In mijn huidige baan ben ik vooral bezig met testautomatisering. Een baan waar je niet zonder testtool kan. Maar ook buiten de testautomatisering kwam en kom ik regelmatig de behoefte aan testtools tegen. Zeker als testautomatiseerder zou je verwachten dat ik een groot fan ben van het invoeren van testtools. Ik ben het niet. In mijn geval: juist door vele testautomatiseringsprojecten ben ik er alleen maar voorzichtiger mee geworden.

Ben ik tegen testtools? Nee, natuurlijk niet. Testtools, of ze nu zijn om bevindingen vast te leggen, test cases vast te leggen, testomgevingen te beheren of, natuurlijk, testen te automatiseren, kunnen heel waardevol zijn. Ze kunnen het werk van de tester verbeteren, versnellen of vereenvoudigen.

Een testtool lost veel problemen niet op
 
Wat is dan het probleem? Het probleem is dat het testtool als de oplossing wordt gezien. Om het voorbeeld bij testautomatisering te houden: testautomatisering wordt vaak als oplossing gezien om beter en sneller de regressietest uit te voeren. In een organisatie met goede, regelmatig uitgevoerde en goed onderhouden handmatige regressietesten is testautomatisering inderdaad een goede stap vooruit. In een organisatie waar de regressietesten van matige kwaliteit zijn, regressietesten bijna nooit worden uitgevoerd of eigenlijk niet worden onderhouden is testautomatisering heel erg moeilijk.

Datzelfde geldt voor het vastleggen van bevindingen of testcases. Een goede bevindingenregistratie kan heel handig zijn. Maar als men nu de tijd niet heeft of de behoefte niet ziet om bevindingen vast te leggen, gaat een invoer van een tool hiervoor niet helpen. Als de bevinding vaak onduidelijk is of moeilijk reproduceerbaar, gaat een testtool dit probleem niet oplossen. Datzelfde geldt voor testcases vastleggen. Testcases hergebruiken kan heel waardevol zijn. Maar als je nu nauwelijks testcases hergebruikt, waarom zou een testtool voor het beheer van testcases dat veranderen?

Elk testtool heeft zijn eigen eisenpakket

En een ander probleem. Testtools kunnen tijd besparen. Maar ze kunnen ook meer tijd kosten op momenten, dat je dat niet wil. Omdat elk testtool zijn eigen eisen heeft. Bevindingenregistraties verplichten je om meer gegevens in te vullen. Gegevens, die daarvoor niet werden ingevoerd. En misschien wel terecht. Als je altijd test op dezelfde testomgeving, is het bijhouden van de testomgeving niet nodig. Als je direct samenwerkt met een ontwikkelaar tijdens het testproces en daarom de bugs direct overlegd, is een omschrijving van de bug, zelfs het aanmaken van de bug, misschien wel onnodige administratie. En zo heeft elk testtool zijn eigen zaken, die je moet uitvoeren, om met het testtool te kunnen werken. Zijn die zaken voor jou wel echt nodig? Wegen ze op tegen de voordelen?

Van doel naar middel

Een testtool is een hulpmiddel bij het oplossen van een testprobleem. En vaak slechts een deel van de oplossing. Toch wordt het al snel een doel, zeker door de manier waarop bedrijven en voorstanders het verkopen. Na de invoering van testtools zal alles beter gaan werken. Wat er nog meer nodig is voor een goede invoering, kunnen of zullen zij je vaak niet vertellen.

Hoe kan je dat zelf controleren. Simpel: testtools verbeteren of versnellen een bestaande testproces stap. Wat ze niet doen: het invoeren van een nieuwe stap in het testproces. Dit kan op detail niveau zijn, zoals het invoeren van bepaalde gegevens bij een bevinding, op wat hoger niveau, zoals het schrijven van een testscript voor een testcase of op een heel hoog niveau, zoals het uitvoeren van regressietesten. Simpel gezegd: alleen als je alle stappen, waar je het testtool in wil zetten, nu al handmatig doet, kan het testtool een doel op zich zijn. Wanneer dit niet het geval is (waarschijnlijk bijna altijd), is je testtool slechts een middel om tot de oplossing te komen.

Een verstandig besluit nemen over de vraag "Wel of geen testtool"

Voordat je over gaat tot invoering van een testtool, is het verstandig om eerst een paar simpele vragen te beantwoorden:

• Welke stappen in het testproces wil ik de testtool laten uitvoeren?
• Bestaan deze stappen nu al? Zo nee, waarom niet?  
• Welke problemen lopen we nu tegenaan bij deze stappen? Gaan deze problemen door de invoering  van het testtool opgelost worden? Of moeten ze opgelost zijn, om invoering zinvol te maken?
• Welke werkzaamheden, die nu al worden uitgevoerd, gaan door de invoering verbeterd of versneld worden? Let op: het gaat dus alleen om werkzaamheden, die je nu al uitvoert, niet om werkzaamheden, die je zou willen gaan uitvoeren.
• Welk extra werk is er nodig, als je gebruik gaat maken van dit testtool? Bijvoorbeeld welke handelingen zijn verplicht om uit te voeren, om dit testtool te kunnen gebruiken of welke extra onderhoudswerkzaamheden zijn nodig om het gebruik zinvol te maken? En is deze tijd ook beschikbaar te maken?

Invoeren van een testtool? Maak de juiste afweging

Een testtool kan een goed middel zijn om een probleem op te lossen. Maar het kan ook uiteindelijk de oplossing niet blijken te zijn. Zeker als je een stap op dit moment handmatig niet uitvoert, moet je je sterk afvragen of het automatiseren van een nu niet bestaande stap, je probleem op gaat lossen. Sta stil bij meer dan alleen de bekende voordelen van een testtool. Sta stil bij de nadelen van een testtool en bij de huidige problemen in je organisatie. Het antwoord op "Invoeren Ja/Nee" kan dan "Ja" of "Nee" worden. Maar als het antwoord "Ja" is, is de kans op succesvolle invoering wel veel hoger. Je weet veel beter waar je aan begint.

Voorkomen dat Scrum de kwaliteit vermindert

Ongeveer drie jaar geleden beschreef ik hoe Scrum de kwaliteit van een applicatie kan verminderen.

http://www.agiletestenbijnee.nl/2015/07/als-scrum-de-kwaliteit-vermindert.html

Dit onderwerp is voor mij zeker niet minder actueel geworden. Er is nog steeds een hoge druk vanuit management en klanten om de beloofde story's in een sprint af te ronden. En nog steeds worden er, om dit waar te maken, shortcuts genomen. Nog steeds liggen deze shortcuts vaak in het testen, zoals korter testen, minder regressietesten of bugs in de applicatie laten zitten. En natuurlijk is het ook nu niet mogelijk om minder werk op te pakken in een volgende sprint, zodat er tijd vrij komt om je testproces goed en volledig afkomt. Want als een team de vorige sprint 20 storypoints heeft opgeleverd, moet dat de vorige sprint ook.

Maar zelf ben ik ondertussen drie jaar verder gegroeid. En waar ik toen alleen het probleem kon constateren, heb ik wat manieren geleerd om dit proces te voorkomen of te verminderen.

Maak afspraken met managers, Scrum Masters, Product Owners en bij voorkeur de klant

De eerste stap is het maken van goede afspraken. Zorg, voordat je deze gesprekken ingaat, wel voor een duidelijke boodschap: "Als we dit proces volhouden zal de kwaliteit van ons product steeds verder afnemen en afnemen. En dat gaat ons vanzelf klanten kosten." Het basisprincipe is simpel: als in elke sprint meer bugs ontstaan, dan worden opgelost, neemt elke sprint opnieuw de kwaliteit van de applicatie af. Als het daarnaast niet mogelijk is op een bepaald moment meer tijd vrij te maken om bugs op te lossen, wat vaak ook echt niet kan, is het eenvoudig te bedenken wat er met de kwaliteit gebeurt. Deze neemt verder af. En hoewel klanten niet snel van applicatie zullen wisselen, komt er een moment dat de slechte kwaliteit voor hun een grens heeft bereikt. Maar pas op dat moment het probleem oplossen zal veel, heel veel tijd kosten. Tijd, die tot nieuwe problemen zal leiden, omdat er veel minder tijd zal zijn voor nieuwe functionaliteit. En ook dat kan klanten gaan kosten.

De belangrijkste minimale afspraak om te maken, is dan ook de volgende: "Elke sprint moet meer bugs oplossen, dan introduceren". De beste afspraak is: "Een sprint mag geen nieuwe bugs introduceren". Een tussenvorm: "Gevonden bugs moeten minimaal in de sprint erna opgelost worden". Kijk hoe ver je komt. Start op de hoogste vorm, maar besef dat elk van deze afspraken al tot een verbetering zal leiden.

En belangrijk: maak deze afspraken met managers, Scrum Masters en Product Owners. Daarnaast, als het ook maar enigszins mogelijk is, maak deze afspraken met de klant. Een manager kan ingrijpen, omdat hij het werk te langzaam vindt gaan. Nu het invoeren van een goed testtraject bijna altijd tot langzamer opleveren zal leiden, is het verstandig dit ingrijpen te voorkomen. Een Scrum Master moet zijn of haar team motiveren te streven naar deze kwaliteit. En ook kunnen uitleggen waarom we het doen. De Product Owner moet bereid zijn te accepteren dat er minder nieuwe functionaliteit opgepakt wordt. En als je het ook uit kan leggen aan de klant, zal deze minder snel druk op de organisatie leggen om toch meer nieuwe functionaliteit op te leveren. Want echt: ook voor de klant is de kwaliteit zeer belangrijk.

Maak statistieken

Na het maken van de afspraken, kan je van 1 ding gelijk uitgaan: deze afspraken gaan gebroken worden. Het besef is er, maar onder druk zal men al snel zeggen: "Maar je moet toch een keer een uitzondering kunnen maken?". Of "Zo ernstig is het probleem toch niet?". Om dit voor te zijn, moet je vanaf het moment van afspraken statistieken bijhouden. Twee statistieken zijn hierbij van belang:

1. Het totaal aantal openstaande bugs in de loop van de tijd
2. Het aantal bugs opgelost in de sprint en het aantal bugs ontstaan in de sprint

Er is altijd een registratie van openstaande bugs. Zorg ervoor dat je minimaal 1 keer per maand telt hoeveel bugs dit zijn en noteer dit. Bij de meeste applicaties is dit nog geen 5 minuten werk.

De tweede vorm van statistieken is iets meer werk. Tel aan het begin van de sprint hoeveel bugs er worden opgelost. Houdt vervolgens tijdens de sprint bij hoeveel bugs er geïntroduceerd worden. Bereken vervolgens het verschil tussen deze twee en leg deze drie getallen vast. Het belangrijkste is het verschil per sprint. Bijna elke sprint opnieuw een toename in bugs maakt wel degelijk indruk, zelfs als dit er maar 1 per sprint is.

Spreek communicatie af

Spreek af hoe de bovenstaande statistieken gecommuniceerd worden.

• Alleen melden als het mis gaat of altijd melden?
• Wie moeten op de hoogte gebracht worden?
• Wie heeft als taak actie te ondernemen om het probleem op te lossen?

Maar het allerbelangrijkste is:

• Hoe laat je weten dat de kwaliteit de verkeerde kant op gaat?

Als je elke maand een mailtje stuurt, zal deze op een bepaald moment nauwelijks meer gelezen worden. Spreek dan bijvoorbeeld af de titel van de mail te wijzigen of een meeting in te plannen, als jij vindt dat er actie moet worden ondernomen. Zorg ervoor dat de communicatie duidelijk en zichtbaar verandert, als de statistieken duiden op een afname in kwaliteit.

In het kort

Om Scrum de kwaliteit niet te laten verminderen, moet je minimaal per sprint minder bugs introduceren dan oplossen. Om dit voor elkaar te krijgen, moet je goede afspraken maken met alle betrokkenen: managers, Scrum Masters, Product Owners en bij voorkeur de klanten.

Maak na de afspraken goede statistieken, die het proces bewaken. Ga er nooit vanuit dat de afspraken alleen voldoende zijn. Er zal, vroeg of laat, door druk van worden afgeweken. Het effect hiervan moet dan zichtbaar gemaakt kunnen worden.

En spreek af hoe deze statistieken gecommuniceerd worden en met wie. Denk hierbij sterk aan het volgende: de communicatie moet, als actie noodzakelijk is, een zichtbaar andere vorm hebben, dan bij de gewenste situatie. Zodat dit gegarandeerd door de betrokkenen opgemerkt zal worden.

Zinvol, snel en eenvoudig prioriteren op een Agile manier

Ook binnen het testen moet je soms prioriteren. Welke testverbeteringen voeren we het eerst door? Wat voegen we het eerst aan een automatische test toe? Welk testdocument werken we het eerste bij? En Agile zou inhouden dat je dit niet in je eentje doet. De praktijk houdt in dat je juist alleen het prioriteren snel kan laten verlopen en je je einddoel beter kan bewaken. Maar er is een tussenweg.

Het probleem van prioriteren is, dat iedereen andere zaken belangrijk vindt. En dan bedoel ik niet de te prioriteren zaken, maar de zaken waar je de prioritering op baseert. Zaken als: hoe vaak, hoe belangrijk, hoe risicovol. "Dit gaat vaak gebeuren" wordt naar beneden gehaald met "Maar er is nauwelijks risico". En "Dit niet belangrijk" wordt tegengesproken met "Maar we doen het wel veel". En zo ontstaat een discussie. Het probleem is, dat je eigenlijk meerdere zaken tegelijk bediscussieerd. Niet alleen hoe vaak en hoe belangrijk en hoe risicovol iets is, maar ook hoe deze zich tot elkaar verhouden. De truck: maak er meerdere kortere discussies van.

Elk van de onderstaande stappen kan op twee manieren worden aangepakt. Er kan van tevoren een voorstel worden gedaan, waar de betrokkenen op kunnen reageren. Maar de stap kan ook gezet worden zonder voorstel. Dit laatste is beter voor het draagvlak, maar mijn ervaring is, dat sturing door een voorstel zeker niet standaard verkeerd is. Er is vaak een einddoel wat je wil bereiken. En een vorm van sturing door een voorstel, kan daar een middel voor zijn. Deze keuze is sterk afhankelijk van de eisen, die je zelf (of je bedrijf/manager) stelt aan de uitkomst. Hoe minder eisen, hoe vrijer je een meeting kan inrichten.

Stap 1 Bepaal de te prioriteren items

Bepaal de items, die je wil prioriteren. Let er hierbij wel op dat je niet alvast met prioriteren begint. Dus geen discussies over "Is dit wel belangrijk?" of soortgelijke discussies. Die komen later.

Stap 2 Bepaal de weegfactoren
Bepaal op welke factoren je wil prioriteren. Vaak zullen dit varianten zijn op "Hoe vaak", "Hoe belangrijk" en "Hoe risicovol". Maar dan wel wat beter uitgewerkt. Bijvoorbeeld "Hoe vaak gaan we dit gebruiken?", "Hoe risicovol is dit voor de organisatie?", "Hoe belangrijk is dit voor de kwaliteit van ons product?".

Stap 3 Bepaal de weegverhouding
Als je de weegfactoren hebt bepaalt, bepaal je de weegverhouding. Hoe verhouden de weegfactoren zich tot elkaar? Bij drie weegfactoren kan dit 1:1:1 zijn, maar het kan ook juist 5:2:1 zijn. Om alvast iets vooruit te lopen: de waarde die een item op de lijst bij het prioriteren krijgt, wordt vermenigvuldigd met de verhoudingswaarde. En uiteindelijk vormen de totalen van de "waarde x verhouding" berekening de eindwaarde, op basis waarvan de uiteindelijke prioritering bepaalt wordt.

Stap 4 Bepaal de weegwaarde
Je kan prioriteren per groep waarbij bijvoorbeeld "5" het zwaarste is en "1" het lichtste. Je kan ook de hele lijst prioriteren, waarbij de weegwaarde de positie op de lijst is. Dit hangt sterk af van hoe eenvoudig het prioriteren is. In groepen is eenvoudiger, maar het risico is groter op een "Gelijk spel". Helemaal prioriteren is moeilijker, maar de eindprioritering zal vaak eenvoudiger zijn. Meestal zal prioriteren in groepen voldoende zijn. Het gaat vaak niet om een uitkomst, die 100% geprioriteerd is, maar meer om het proces, dat zorgt voor meer draagvlak en meer controle door een groep als geheel.

Stap 5 Prioriteer de items per weegfactor
Na alle voorgaande stappen kan het echte prioriteren starten. De items kunne nu volgens de bepaalde weegwaardes per bepaalde weegfactor ingedeeld worden. Vervolgens kan de totale waarde berekend worden. Zoals al eerder beschreven, krijg een item per weegfactor een waarde "waarde x verhouding". Vervolgens worden de waardes per weegfactor bij elkaar opgeteld en deze lijst levert een totale lijst op.

Waarom niet in 1 stap?
Een fout, die veel mensen maken, is dat 1 stap "Een meeting organiseren voor prioriteren" vaak minder werk lijkt dan 5 stappen. Maar het is makkelijker om een groep op 1 onderwerp op 1 lijn te krijgen, dan op vele onderwerpen. Uiteindelijk bespaar je juist tijd, door eerder overeenkomst te hebben. Daarnaast kan je bepaalde onderwerpen in kleinere groepen bespreken, waardoor je elke stap kan nemen met personen, die echt input kunnen en willen leveren. Dit levert niet alleen snellere meetings op, maar ook minder tegenzin tijdens de meeting van de deelnemers. Omdat het een onderwerp is, waar ze over mee kunnen en willen praten, zijn ze automatisch gemotiveerder.

Probeer het eens uit. Speel ermee. En als je wil, bedenk je eigen variant. Het belangrijkste is: "1 onderwerp tegelijkertijd".

(Geen) Testverbetering: Als SMART doelen niet SMART zijn

Als je aan de gang gaat met verbetering, kom je al snel op SMART. Om na te gaan of je je doelen bereikt, moeten ze specifiek, meetbaar, acceptabel, realistisch en tijdgebonden zijn. En dat geldt dus zeker ook voor testverbeteringen. Je wil na kunnen gaan of je je doel bereikt op een duidelijke en objectieve wijze. En je wil ze communiceren, zonder al te veel kans op misverstanden.

Op zich dus niets mis mee. Maar regelmatig loopt het opstellen van duidelijke doelen uit op een teleurstelling. De SMART goals zijn gehaald, toch is het eindresultaat een teleurstelling. Wat kan er mis gaan?

Het checklist effect

Stel je wil het aantal bugs, dat door de klant gebracht wordt terugbrengen. Als een van de onderdelen om dit te bereiken, wil je je testtraject verbeteren. Je wil daarom je regressietesten uitbreiden, de testdekking vergroten, unit testen invoeren en de kennis van je tester uitbreiden. Op basis van deze doelen voor testverbeteringen maak je een mooi plan met hierin elk onderwerp beschreven als een volledig correct en SMART doel.

Vervolgens gaat iedereen met het plan aan de gang. Elk doel wordt gehaald. Een jaar later krijg je opnieuw de statistieken over het aantal bugs van klanten onder ogen. En ondanks het uitstekende gevoerde plan, is het aantal bugs niet gezakt. Wat blijkt? Het grootste percentage bugs bevindt zich in de rapportages. En in geen enkele van de aanpassingen is de test van de rapportages verder uitgebreid.

Wat hier gebeurt, is dat het uiteindelijke doel uit het oog is verloren. Men heeft een lijstje met doelen gekregen en dat lijstje is een doel op zich geworden. Dit kan al gebeuren bij slechts 1 doel. Maar zeker als het er meer zijn, is de neiging groot om niet meer te weten wat het echte doel eigenlijk is. Soms wordt het je niet eens meer verteld. Het is tenslotte niet van belang, je weet op basis van het SMART doel toch wel wat je moet doen?

Wat zou moeten gebeuren, is het volgende:
Er wordt niet alleen gekeken naar het netjes geformuleerde SMART doel. Nee, er wordt ook gekeken naar het hogere doel. Breiden we de testen uit op een wijze, die werkelijk de bugs van klanten terug kan brengen? Melden klanten bugs over de applicatie onderdelen, die we willen aanpassen? En zo ja, hoeveel en hoe vaak dan? Het SMART doel gecombineerd met het kijken naar het hogere doel leiden vervolgens tot een goede aanpak en een goede testverbetering.

Zorg er ook voor dat je dit hogere doel objectief kan controleren. Er moeten minimaal statistieken zijn, die dit hogere doel meten en die je regelmatig kan controleren. Dit geeft je de optie je aanpak tussendoor te evalueren en eventueel aan te passen.

Ieder zijn deeltje

Neem nu 1 item van deze checklist: het uitbreiden van de regressietesten. Deze taak komt bij een tester terecht. Deze vraagt vervolgens: "Welke testen moet ik uitbreiden?". De maker van het plan was er heilig van overtuigd, dat dit toch wel door de tester bepaalt zou worden. Maar de tester is van mening, dat dit al uitgewerkt had moeten zijn in de taak. Beide hebben een manager, die ze gelijk geeft: ze hebben het al druk, ze moeten geen onnodig werk op zich nemen.

Hoeveel mensen je ook in een SMART doel neerzet, uiteindelijk moet er 1 hoofdverantwoordelijke zijn. Deze heeft als doel, ongeacht wie, wat of welke afdeling, ervoor te zorgen dat vragen beantwoord worden en problemen opgelost worden. Je kan niet alles in een SMART doel vastleggen. Tenslotte is het verstandig zo'n doel qua tekst niet al te lang te maken. Maar juist daarom hoort iedereen te weten, bij wie je terecht kan met vragen en problemen. Want hoe SMART een doel ook is, alleen dan is deze ook werkelijk haalbaar.

Het beloningseffect

SMART doelen zijn ideaal om mensen te beoordelen en te belonen. Waarbij ik belonen nu even ruim zie: zowel met complimenten voor goed werk als financieel. Er is een probleem: het is zeer moeilijk om een SMART doel op te stellen, wat zich niet tegen de opdrachtgever kan keren. Als iemand de opdracht heeft het aantal testen te verdubbelen, kan hij de bestaande testen splitsen in tweeën. Als iemand de opdracht heeft het aantal gemelde bugs te verminderen, kunnen bugs plotseling "Change requests" worden. Tenslotte is het een wijziging op de huidige werking, waarmee ze akkoord zijn gegaan. Toch?

Maar de SMART doelen kunnen ook in het nadeel van de uitvoerende werken. Iemand kan oprecht het aantal testen willen verdubbelen, maar vervolgens te horen krijgen, dat hij te weinig tijd besteed aan concreet testen. Of werkelijk de bugs willen verminderen, maar niet de tijd krijgen om de bestaande bugs te analyseren.

In beide gevallen kan de situatie ontstaan, dat een persoon bestraft wordt voor het doen wat het beste is voor het bedrijf of het gehoorzaam uitvoeren van een opdracht. En het is zelfs mogelijk dat een persoon beloond wordt voor het leveren van slecht werk. Dit kan "verstandige" testers dan ook nog eens stimuleren om bij de "onverstandige" testers te gaan horen. Die worden tenminste wel beloond.

SMART doelen werken alleen als de opdrachtgever en de uitvoerder(s) elkaar vertrouwen. Het vertrouwen dat beide partijen het beste willen halen uit het testen en de doelen kunnen behalen, maar tegelijkertijd beseffen dat doelen kunnen wijzigen. Beiden moeten bereid zijn om de doelen aan te passen, als dit noodzakelijk is. En, misschien een klein extra detail, ook zelf het recht hebben om tot deze aanpassing over te gaan.

Moet je SMART ontwijken?

Als je dit alles leest, zou je bijna de SMART doelen gaan ontwijken. Maar SMART doelen hebben ook hele grote voordelen, zoals in de inleiding al genoemd. Het grootste probleem is, dat juist een SMART geformuleerd doel stimuleert om niet verder te kijken dan je neus lang is. Want het doel is al zo ontzettend duidelijk, dat meer niet nodig lijkt. Toch moet je blijven kijken naar het grotere geheel en met elkaar blijven praten, om op 1 lijn te blijven. Als je dat niet vergeet en je weet ook nog eens als team, maar met leider, de situatie SMART aan te pakken, is er absoluut niets mis met SMART.

De verboden bugs bij regressietesten

Bij het maken van een regressietest, al of niet geautomatiseerd, gebeurt soms iets, wat eigenlijk niet zou moeten kunnen. Je komt een bug tegen, die nog niet gevonden is. Dit zou een zeer uitzonderlijke situatie moeten zijn, omdat de functionaliteit eerder getest moet zijn. Maar het opstellen van een regressietest gaat vaak samen met het verbeteren van het testen in het algemeen. Daardoor kan de kwaliteit van de test tijdens de regressietest veel hoger zijn dan de kwaliteit van de test, waarmee de functionaliteit hiervoor is getest. En hierdoor kunnen bugs naar boven komen, die nog niet eerder gevonden zijn.

Iets wat je vlak daarna vaak zal horen: maar de bugs zijn niet gemeld door onze gebruikers of klanten. Ook deze gaat meestal niet op. Als er behoefte is aan kwaliteitsverbetering in testen, is dit vaak omdat gebruikers en klanten te veel bugs melden. En juist in zo'n situatie concentreren klanten en gebruikers zich vooral op de belangrijkste. Ze hebben de tijd niet beschikbaar, om je alles wat ze tegenkomen te laten weten. Zeker niet als ze regelmatig bugs tegen komen. Dus je weet eigenlijk niet of deze bug al eerder ontdekt is door een klant of niet. Alleen dat er voor de klant in ieder geval belangrijkere bugs zijn.

Maar dan kom je in de volgende situatie: hoe ga je om met deze "verboden" bugs bij het opstellen van regressietesten? Als je dit leest, voor je begint met het invoeren of verbeteren van regressietesten, is de beste actie in de voorbereiding. Vertel je opdrachtgever of leidinggevende, dat je onbekende bugs kan tegenkomen. En leg uit waarom dit het geval is. Begrip is de basis. En maak meteen afspraken over de afhandeling van deze bugs. Ook achteraf, als de bugs al gevonden zijn, is dit een verstandige stap om alsnog te doen.

Er zijn twee belangrijke argumenten om deze bugs op te lossen. Ten eerste het algemene streven naar een kwalitatief goed product. Ten tweede het streven naar een goede, betrouwbare regressietest. De tweede vraagt misschien wat toelichting. Een regressietest moet testen of de applicatie nog steeds goed werkt. Hiervoor bepaal je een bepaalde dekking. Je test bijvoorbeeld alle velden in een scherm of alle situaties, die voortkwamen uit een bestaande testtechniek. Maar een bug maakt een goede dekking onmogelijk. Je kan niet alle velden of situaties goed en volledig testen, zonder de test elke keer te laten falen. Want je moet om de bug heen testen, waardoor je niet alle velden en situaties test. Of je moet de bug accepteren als goed, waardoor je niet echt test of de applicatie goed is. Of je moet de test steeds laten falen, waardoor de regressietest niet goed meer uitgevoerd kan worden.

Als je slechts 1 bug vindt, is dit nog wel overkomelijk. Maar hoe meer bugs, hoe beschadigder je regressietest wordt. En je krijgt uiteindelijk twee hele verschillende regressietesten: een niet bestaande, die zou testen hoe de applicatie goed werkt en de bestaande, die test rekening houdend met de gevonden bugs.

Het algemene streven naar kwaliteit lijkt een stuk simpeler. In de praktijk is juist dit het minder sterke argument. De bug komt niet van een klant of gebruiker af en zit waarschijnlijk al vrij lang in de applicatie. Dus zelfs als je de bug wil oplossen, zullen er altijd belangrijkere bugs zijn. Namelijk de bugs, die wel door de klant of gebruiker zijn gemeld. Zelfs als tester kan je tegen dit argument weinig inbrengen.

Van belang is dan ook om beide argumenten goed naar voren te brengen. De reden om toch deze bugs op te lossen, zit namelijk in de combinatie. Om goed te testen moet je een betrouwbare regressietest kunnen opstellen. Een, die niet om de fouten heen werkt. En als bedrijf moet je streven naar een kwalitatief goed product, ongeacht of de klanten alle bugs melden of niet. Ook bij niet gemelde bugs is het van belang goed te kijken naar de andere zaken, die prioriteit bepalen: hoe vaak kan de bug in de praktijk voorkomen en hoe groot zijn de gevolgen van de bug. Anders gezegd: hoe groot is de kans dat gebruikers (denk hierbij ook vooral aan nieuwe gebruikers) de bug (alsnog) tegenkomen en hoe groot zijn de gevolgen als dit gebeurt.

Maar ga er niet vanuit, dat alle bugs in een keer worden opgelost. Dit verwachten schept vaak al meteen een jij-tegen-zij houding. Ga voor een afspraak, waarin de bugs meegenomen worden in de planning. Het belangrijkste is, dat eraan gewerkt wordt. Maar hou wel statistieken bij. Hou bij hoeveel van dit soort bugs je hebt gevonden en hoeveel er zijn opgelost. Zeker in het begin kunnen de bugs in aantal zeer sterk groeien, maar het gezamenlijke doel moet zijn de groei te stoppen. Zowel voor jezelf als voor de organisatie is het dan ook van belang om na te kunnen gaan of dit doel gehaald wordt. Zodat je weet of je misschien nog iets harder moet vechten. En als dat zo is, heb je in ieder geval de onderbouwing, via de statistieken, al gestart.