Privacy en testdata aan de hand van een vingerafdruk

Waarom zou je privacy en testen bespreken aan de hand van een vingerafdruk? Niemand ontkent dat de vingerafdruk persoonlijk is en niet zomaar overal vastgelegd zou moeten worden. Over het algemeen wordt de vingerafdruk gezien als een goede manier om een persoon te identificeren. Tegelijkertijd heeft een vingerafdruk zulke kenmerken, dat deze niet zo eenvoudig te anonimiseren of te simuleren is. Omdat het testen aan de ene kant sterk rekening moet houden met privacy, maar de eisen aan testdata steeds ingewikkelder wordt, zie ik de vingerafdruk als een goed voorbeeld van de testproblemen nu. Maar een vingerafdruk geeft, in mijn ogen, ook een goede kijk op de problemen van de toekomst. Wat zijn die problemen?

Privacy en gebruiksvriendelijkheid

Het gebeurt met enige regelmaat dat de vingerafdruk gebruikt wordt als (deel van) een identificatieproces. Het wordt over het algemeen beschouwt als een vrij veilige manier van identificatie. En het heeft als voordeel dat een gebruiker geen code, wachtwoord o.i.d. hoeft te onthouden. Nu een persoon ook altijd zijn of haar vinger bij zich zal hebben, is het voor de gebruiker het toppunt van gebruiksgemak. Waardoor ook de tester vingerafdrukken zal moeten gebruiken bij het testen.

Systemen zijn steeds vaker gericht op gebruikersvriendelijkheid en op het voorkomen van fouten. Toen ik begon met testen, was een adrescontrole vaak niet meer dan "een postcode bestaat uit 4 cijfers en 2 letters". Nu zijn er steeds meer applicaties, die op basis van postcode en huisnummer het adres al volledig voor je invullen. Een stap verder en er wordt straks zelfs nog gecontroleerd of het woonadres juist is. Wat waarschijnlijk in zal houden, dat ik heel veel woonadressen zal moeten vinden, bij voorkeur zonder adressen uit productie te gebruiken. Een uitdaging, die ik nu nog niet aan zou kunnen.

De eisen, die aan testdata van persoonsgegevens gesteld worden, komen door de behoefte aan gebruikersvriendelijkheid en uitgebreide foutcontrole, steeds hoger te liggen. Goede bronnen om geschikte data te vinden, zijn echter niet altijd beschikbaar voor testers. Niet elke tester heeft vaardigheden als SQL, om in een tabel data op te zoeken. Als dit al mogelijk is. En als dit niet juist de privacy in gevaar brengt. In een tabel kijken met alle geldige adressen in Nederland is misschien nog wel een optie. Maar als deze er niet is, is kijken in de tabel met alle adressen van klanten geen goede variant. En als de data nog wat ingewikkelder is: niet elke tester weet de bronnen te vinden om bijvoorbeeld geschikte, niet bestaande, bankrekeningnummers, BSN-nummers, credit card nummers, enz. te vinden.

Privacy en externe systemen

Stel dat een vingerafdrukcontrole extern wordt uitgevoerd of dat een extern ontwikkelde applicatie hiervoor gebruikt wordt. Wat gezien het belang van een goede controle zeker niet vreemd zou zijn.  De wijze waarop gecontroleerd wordt, kan best wel eens, zeker bij een vingerafdruk, onder de bedrijfsgeheimen vallen. Waardoor je deze niet weet. Daarnaast is er een grote kans, dat een applicatie als deze geen testdatabase heeft. Ook zal je zeker niet vrij in hun productiedatabase kunnen zoeken naar bestaande vingerafdrukken. De enige manier om te testen zou dan zijn, om zelf vingerafdrukken in de database toe te voegen en deze vervolgens voor je testen te gebruiken.

Applicaties vormen steeds meer een onderdeel van een hele systeemketen. En daarnaast maken steeds meer bedrijven gebruik van componenten of andere onderdelen, die ontwikkeld zijn door een gespecialiseerd bedrijf. Je kan als bedrijf tenslotte niet van alles kennis hebben. Dit houdt wel in, dat de manier van testen steeds sterker afhankelijk wordt van de mogelijkheden, die externe systemen of componenten bieden. Wat nu als je echt wel zonder productiedata wil testen, maar de leverancier van een component daar geen mogelijkheid voor biedt?

Privacy en veiligheidseisen

Het is niet vreemd om een veiligheidscontrole te versterken door de vingerafdruk toe te voegen. Bij een goede vingerafdrukcontrole wordt de vingerafdruk zo gecontroleerd, dat fraude bijna onmogelijk is. Maar het feit dat fraude bijna onmogelijk is, maakt ook dat een tester geen gebruik kan maken van niet bestaande data. Want hoe kom je aan een nepvinger, die deze strikte controle doorkomt?

Juist door het belang van privacy, maar ook door het steeds grotere belang van veiligheid, neemt de behoefte aan goede, strenge veiligheidseisen steeds meer toe.  Hier zie je al snel een tegenstrijdigheid met testen. Hoewel je bij testen behoefte hebt aan overduidelijke nepdata, waarmee je kan testen, zonder persoons- of productiegegevens te gebruiken, is deze nepdata tegelijkertijd een bron voor fraudeurs. Want als deze nepdata werkt voor een tester, werkt die ook voor een fraudeur.

Maar dan ga je er in ieder geval van uit dat een tester nepdata kan maken. De controles zijn vaak geheim. En zelfs als ze dat niet zijn, zijn ze zo beschreven, dat een gemiddelde tester ze niet zal snappen. Er zijn denk ik weinig testers, die zelf een geldig bankrekeningnummer kunnen bedenken. Een die voldoet aan alle controles, die banken eraan geven. Nu de veiligheidseisen steeds vaker een stuk hoger liggen, dan de eisen van een bankrekeningnummer, hoe verwacht je dan dat een tester aan goede testdata komt?

De toekomst

Met alle nieuwe privacy wetgeving is privacy van persoonsgegevens een belangrijk probleem. En er wordt niet ontkent dat privacy en testdata een probleem is, dat aandacht verdient. Wat je nu echter ziet, is dat de verantwoordelijkheid hiervoor bij testers wordt gelegd. Er zijn echter steeds meer redenen, waardoor testers niet de kennis en/of de middelen hebben om op de beste manier met persoonsgegevens om te gaan. Vele testers zullen doen wat ze kunnen, maar niet elke tester zal slagen.

Zoals ik hierboven heb beschreven, zal dit probleem in de toekomst alleen maar groter worden. Hoe meer we eisen qua controles, netwerken en gebruiksgemak, hoe moeilijker het wordt om te testen zonder echte, bestaande persoonsgegevens (al of niet direct te relateren aan een echte klant of gebruiker).

Ik hoop dat we veel meer aandacht gaan besteden aan dit probleem. En dat bedrijven en andere betrokkenen bij privacy gaan beseffen dat testers deze problemen niet alleen op kunnen lossen. Zelfs als testers willen, zullen ze niet altijd kunnen. Neem ze dat niet kwalijk, maar help ze!

Verkeerde zelfstandigheid geeft verkeerde kwaliteit

Met vormen als Agile en Scrum staat zelfstandig werken steeds meer centraal. Ook, en zelfs zeker ook, bij het testen. Als een tester goed zelfstandig kan werken, kan dit zeker de kwaliteit verhogen. Maar als de zelfstandigheid verkeerd gaat..... gaat de kwaliteit dat ook.

Zelfstandige mensen en teams worden gewaardeerd. Ze kunnen werken, zonder dat ze je hulp nodig hebben. Als je met ze praat, laten ze precies weten wat ze willen. Ik heb niets tegen zelfstandig werken. Maar het feit dat een persoon of team zelfstandig mag werken, betekent nog niet dat iemand dat ook kan. Ik heb te vaak gehoord, als ik vraag naar een "Waarom doen jullie dat zo?", dat mensen zeiden: "Dat is wat X wilde." Puur het feit dat X een tester is, is voor mij te weinig om de manier van werken te accepteren.

Iemand, die zelfstandig kan werken, neemt besluiten op basis van argumenten. Argumenten, die niet alleen uitgaan van de kennis en vaardigheden van de persoon zelf, maar ook van de wensen en behoeftes van het bedrijf. Natuurlijk, elke tester heeft zijn eigen voorkeuren in testen. De een test meer handmatig, de ander wil het liefst zoveel mogelijk automatiseren. De ene gebruikt zoveel mogelijk testtechnieken, de ander gebruikt vooral eigen ervaring. Het feit dat je je testen aanpast op wat je goed kan en leuk vindt, is zeker verstandig. Maar het is niet het enige wat telt! Als het voor je bedrijf heel belangrijk is, dat de kwaliteit van het gehele product goed is, is er vaak behoefte aan veel testautomatisering. Ongeacht of je het leuk vindt of niet, dat werk moet dan gewoon gedaan worden. Als je bedrijf echter veel laatste moment wijzigingen heeft, zal je juist veel handmatig moeten testen om bij te kunnen blijven.

Daarnaast zijn er ook standaard kwaliteitsargumenten. Zo gaat "een niet getest onderdeel testen" altijd voor "het testen van een onderdeel verbeteren". Ook moet er altijd tijd zijn voor het onderhouden van bestaande testautomatisering of bestaande testscripts. Meestal niet de leukste taak, maar als je hier nooit tijd voor vrij maakt, kan het testen je later een onmogelijke hoeveelheid tijd gaan kosten.

Iemand, die zelfstandig werkt, maar dat niet kan, neemt vaak alleen beslissingen op basis van persoonlijke voorkeuren. Hij of zij kiest wat hij of zij kan en vaak ook leuk vindt. Wat hij of zij doet, wordt dan ook zeker goed gedaan. Dat maakt ook, dat het moeilijker is de nadelen hiervan te vinden. Daarvoor moet je kijken naar wat niet gedaan wordt. Wat zijn de gevolgen daarvan?

Ik heb gezien en gehoord dat onderdelen van een applicatie niet meer te testen zijn, omdat de kennis en de tools daarvoor niet meer aanwezig zijn. Ik heb gezien en gehoord, dat belangrijke testen niet uitgevoerd werden (b.v. betrouwbaarheid van gegevens), omdat de tijd ergens anders aan werd besteed. Dus niet door tijdgebrek of tegenwerking van collega's of managers. Maar gewoon, omdat de tester dat heeft besloten.

Zelfstandigheid mag nooit leiden tot het niet testen van (een deel van) een applicatie. Zelfstandigheid mag niet leiden tot het verwaarlozen van waardevolle automatische testen of geschreven testscripts. Zelfstandigheid mag niet leiden tot slechter of langzamer testen. Ik hoop dat iedere lezer snapt, dat dat de kwaliteit niet ten goede komt.

Hoe zelfstandig een tester ook is, ik blijf het recht nemen om te vragen "Waarom?". En ik blijf geen genoegen nemen met het antwoord "Zo wil X het" of "Dit is nu eenmaal hoe ik werk". Naar mijn ervaring hebben echte zelfstandige mensen ook geen moeite met deze vraag. Het zijn meestal mensen, die open staan voor nieuwe ideeën en tegenspraak. Want ze zijn vaak zelfstandig geworden en gebleven, door regelmatig te luisteren en te leren van anderen. Ik werk daarom graag samen met mensen, die echt zelfstandig werken, want juist zij weten hoe belangrijk samenwerken is!

Testautomatisering en stabiliteit: hoe los je deze problemen op?

Je automatische testen moeten bij voorkeur altijd werken. Ongeacht browser, device, snelheid, enz. Ik heb automatische testen gemaakt voor allerlei verschillende soorten websites en applicaties en voor veel verschillende devices en browsers. Maar waar je de testautomatisering ook voor maakt, stabiliteit blijft een van de grootste problemen. En waar je de testautomatisering ook voor maakt, de problemen en oplossingen zijn vaak in dezelfde richting.

Twee veelvoorkomende problemen wil ik hieronder beschrijven:

1. Laadproblemen: een element is nog niet in beeld verschenen of nog niet bruikbaar, waardoor erop klikken of een waarde invoeren nog niet gaat
2. Scrollproblemen: een element valt buiten beeld, waardoor je ernaar toe moet scrollen

Laadproblemen

Om alvast met de deur in huis te vallen: hoe beter je de stabiliteit bij laadproblemen maakt, hoe groter de kans dat de performance van je test achteruit gaat. De beste manier om laadproblemen te voorkomen, is om bij elk nieuw scherm of elke nieuwe pagina minimaal 1 minuut te wachten, voordat je verder gaat. Dit maakt je test echter behoorlijk traag. Juist daarom is een probleem rond het laden van een pagina zo moeilijk op te lossen.

Gelukkig lossen tegenwoordig veel testautomatiseringstools dit probleem automatisch op door bij een klik of een invoerfunctie eerst te controleren of een element gebruikt kan worden. En te wachten tot dit het geval is. Dit zal in de meeste gevallen voldoende zijn. Maar als dit niet voldoende is of deze optie is niet beschikbaar, moet je zelf een wachtloop inbouwen.

Over het algemeen is de beste oplossing om deze problemen te voorkomen: controleer het element, dat je wil gaan gebruiken. Dit houdt in: je zoekt het element op en gebruikt het gevonden element eerst gebruiken om te kijken of je verder kan gaan met je test. Daarna hoef je het element niet opnieuw te zoeken om het te gaan gebruiken voor een klik of invoer. Nu zoeken naar een element vaak de grootste performance problemen geeft, is dit het beste evenwicht tussen tijdgebruik voor controle en voorkomen van extra tijdgebruik voor performance.

Er zijn twee manieren om een element te controleren:

• Controleren op aanwezigheid
• Controleren op "enabled"

Welke keuze het beste is, is afhankelijk van wat je test, je tools en de situatie. Controleren of een element aanwezig is, is vaak de meest eenvoudige optie, maar niet altijd voldoende. Want een element kan wel aanwezig zijn, maar toch nog niet bruikbaar. Denk aan een button, die pas werkt als een volledige websitepagina geladen is. Afhankelijk van de situatie kan je daarom de controle op aanwezigheid aanpassen naar een controle op "enabled", "active" of iets soortgelijks.

Het is echter niet altijd mogelijk het element zelf te controleren. Om deze controle te laten slagen, moet het element unieke "zoekcritetria" hebben. Voor de niet ervaren testautomatiseerders bij het lezen: elementen worden gevonden door zogenaamde "zoekcriteria" door te geven. Deze criteria zijn bij voorkeur zo uniek, dat slechts 1 element op de pagina of het scherm eraan voldoet. Maar veel testautomatiseringstools bieden ook de mogelijkheid om op basis van zoekcriteria een verzameling op te vragen en vervolgens in deze verzameling het eerste, tweede, derde, enz. element te kiezen.

Om het element goed te controleren moeten de zoekcriteria voor het element niet alleen uniek zijn op zijn eigen scherm of pagina. Maar ook niet voorkomen op het scherm of de pagina waar je vandaan komt. Stel je bent in een wizard en je hebt twee stappen achter elkaar een volgende button. Als je nu zou controleren op een button met de tekst "Volgende", hoe weet je of je test de button van dit scherm of van het vorige scherm heeft gevonden?

Als je element niet uniek genoeg is, moet je een ander element op je scherm gebruiken voor de controle. Zoek dus naar een element met unieke zoekcriteria op je huidige scherm of pagina. Maar let erop dat deze zoekcriteria op je vorige scherm of pagina geen resultaat opleveren.

En heel soms (dat is tenminste te hopen) is dit allemaal niet voldoende. Dan zijn er nog twee oplossingen over:

• Controleer of de pagina volledig geladen is (werkt alleen voor websites)
• Wacht een paar seconden

Controleren of een pagina volledig geladen is, is qua performance nog een vrij goed alternatief. Maar een paar seconden wachten is het laatste wat je wil. Als je dit moet gebruiken, is het verstandig daarnaast met de programmeurs te gaan praten om te zoeken naar een andere oplossing.

Scrollproblemen

Het element dat je wil gebruiken, staat niet altijd in beeld. Dit kan, omdat je bijvoorbeeld op verschillende mobiele telefoons wil testen en daarom steeds verschillende schermresoluties hebt. Maar het kan ook dat een webpagina of invoerscherm gewoon heel groot is. Ook hier testautomatiseringstools soms automatisch de oplossing: zij zorgen ervoor dat het element in beeld komt. Is deze optie er niet, dan zal je je eigen scrollfunctie moeten toevoegen.

Wat hier van belang is, is om eerst de volgende vragen beantwoord te krijgen:

• Wat voor scrollfuncties biedt je testautmatiseringstool aan?
• Test je in 1 of meerdere schermresoluties?
• Is het element, dat buiten beeld is, alleen niet zichtbaar of bestaat het element nog niet?
• Kan je een element vinden, dat gelijk is aan het gebied, waarin gescrolled wordt?

Wat voor scrollfuncties biedt je testautomatiseringstool aan

Elk testautmatiseringstool kan scrollen. Verticaal en horizontaal. Maar soms kan er meer. Kan je bijvoorbeeld het element, waar je naar op zoek bent meegeven? Zodat het scrollen automatisch stopt als het element gevonden is? Soms is er ook de mogelijkheid om een pagina te scrollen. Dit houdt in dat het laatste element op je scherm net niet meer zichtbaar is en het eerste element daaronder nu bovenaan je scherm staat. Dit voorkomt dat je zelf moet uitrekenen hoeveel je moet scrollen. Bestaande scrollfuncties gebruiken is altijd het snelst en meest eenvoudig. Dus als dat kan, doe dat!

Test je in 1 of meerdere schermresoluties

Wanneer je in 1 schermresolutie test, kan je een scrollfunctie gebruiken, waarbij je een bepaald aantal pixels, een bepaald percentage of een bepaald aantal keer naar beneden scrollt. Bij dezelfde schermresolutie zal dan altijd het element in beeld verschijnen. Als je wil testen op meerdere schermresoluties, zal je echter een x aantal keer moeten scrollen, net zo lang tot het element zichtbaar is in je scherm.

Is het element, dat buiten beeld valt, alleen niet zichtbaar of bestaat het element nog niet?

Wanneer de scrollfunctie alleen niet voldoende is en je test op meerdere schermresoluties, zal je zelf moeten controleren of een element in beeld is. Dit klinkt simpel, maar er is 1 probleem. Een element buiten beeld bestaat niet altijd. Soms wordt een element pas gemaakt of gevonden, als het in het scherm op de pagina verschijnt. Om te weten wanneer je moet stoppen met scrollen, moet je daarom eerst weten waar je op moet controleren: bestaat het element of is het zichtbaar. Waarom dit van belang is? Controles op zichtbaarheid falen vaak als het element niet bestaat. Omdat je bij veel testautomatisering alleen van een bestaand element kan controleren of het zichtbaar is of niet. Is het element niet bestaand, dan krijg je een ongewenste fout in je test, waardoor je test ongewenst faalt.

Kan je een element vinden, dat gelijk is aan het gebied, waarin gescrolled wordt?

Als je moet scrollen, kan je standaard een kleine afstand nemen en gewoon heel vaak scrollen. Dit kan echter performance problemen geven. Na elke scoll voer je namelijk ook de aanwezigheidscontrole voor het element uit en dat is vaak niet de snelste controle. Daarom kan het verstandig zijn het scrollen zoveel mogelijk te beperken. Dit kan door een element te vinden, dat gelijk is aan het gebied, waarin gescrolled wordt. Wanneer je de y-coördinaat en de hoogte van dit element weet, weet je waar je kan scrollen. Ik raad alleen aan hier wel een kleine marge aan te houden. Hieronder de twee meestvoorkomende mogelijkheden:

1. Scrollen op coördinaten
   Scroll van "y + 10" naar "y + hoogte - 10"
2. Scroll een bepaalde afstand
   Scroll de afstand "hoogte - 20"

Als het doel-element niet zichtbaar is, maar wel bestaat, kan je dit misschien ook gebruiken om in 1 keer naar het element te scrollen. In dat geval kan je de afstand bepalen door "(y van element +  hoogte van element) - (y van scrollgebied + hoogte scrollgebied) + 20".

Voor de goede kijkers: bij de eerste versie haal ik wat pixels van de werkelijke afstand af. Dit is om zo te scrollen, dat er na elke scroll nog net iets van de situatie "voor het scrollen" in beeld staat. Hierdoor weet je zeker dat het element altijd in beeld komt. Maar in de tweede voeg ik juist pixels aan de afstand toe. Je wil zeker weten dat na het scrollen het element echt in beeld staat. Bij deze optie heb je tenslotte geen tweede kans.

Ben je er dan?

Bovenstaande zal veel stabiliteitsproblemen oplossen. Maar het allerbelangrijkste blijft: als je test een keertje slaagt, vertrouw daar niet op. Draai de test een paar keer en draai hem, indien gewenst, in verschillende schermresoluties. Stabiliteitsproblemen zijn lastig, maar ze zijn altijd op te lossen!

Een andere vorm van waardering

Ik heb gisteren afscheid genomen van mijn huidige baan. Het was een vreemd afscheid, duidelijk anders dan je als buitenstaander zal verwachten. Wel met veel waardering. Maar voor het grootste deel een andere vorm van waardering. Geen verhalen over mijn grote successen als tester. Weinig verhalen over hoe fijn ik was als collega. Betekent dit dat ik geen successen heb gehaald? Dat mijn huidige collega's nooit meer met me samen willen werken? Ik weet wel zeker van niet. Want de waardering voor wat ik heb gedaan was er wel degelijk. Alleen anders.

En van mijn kant was het trouwens niet anders. Ik heb veel waardering voor de collega's en managers, met wie ik in de afgelopen 3+ jaar heb samengewerkt. Toch zal je ook van mijn kant niet veel verhalen horen over succesvolle projecten of gezellige momenten met collega's. Niet omdat ze er niet waren. Ze waren er. Maar de waardering voor een andere kant van de baan was voor mij veel en veel hoger.

Wat ik waardeer in mijn collega's en managers van de afgelopen jaren, gaat voor mij over groei. Ik heb de kans gekregen binnen een groep mensen te werken, waar ik kon groeien. Een groep mensen, waar ik fouten kon maken en vervolgens erop kon vertrouwen toch nog een kans te krijgen. Een groep mensen, waar ik een verkeerd gesprek later nog een keer over kon doen. Waar ik een verkeerde keuze kon en mocht herstellen. Door de fouten, de verkeerde gesprekken, de verkeerde besluiten heb ik het mijn collega's en managers niet altijd makkelijk gemaakt. En dat zijn ze niet vergeten. Dat ben ik ook niet vergeten. Ze vormden een grote bron van verhalen om uit te putten tijdens het afscheid, maar altijd met de bijbehorende boodschap: "Het is goed gekomen!"

De waardering van collega's en managers naar mij toe is ook op een wat onverwachter gebied hoger, dan de waardering voor mijn testwerk. Vaak als waardering werd uitgesproken, werd verwezen naar gesprekken, die ik heb gevoerd. Gesprekken waarin het adviseren, kennis overdragen, aankaarten van problemen of gewoon luisteren centraal stonden. En als het daar niet over ging, ging het over de groei, die ze bij mij gezien hebben. Hoe ik met ups en downs mijn groeipad heb afgelegd en steeds ben doorgegaan.

We leven in een wereld, waar waardering voor elkaar heel belangrijk is. Juist omdat samenwerking bij vormen van Scrum en Agile niet kan zonder waardering voor elkaar. Maar waar het bij samenwerking om gaat, is juist ook verder kijken dan de functie. Waardering hebben voor groei en waardering hebben voor de kans om te groeien. Waardering hebben voor de vorm en inhoud van gevoerde gesprekken. Waardering voor samenwerken in plaats van tegenwerken. Ik merk dat dit vaak mist. Daarom hoop ik, dat deze door mijn ontvangen en gegeven vorm van waardering ook voor anderen tot voorbeeld kan dienen.

De eeuwige uitzondering

De eeuwige uitzondering. Dat zou ik omschrijven als een vrij algemeen probleem. Waarom dan in een testers blog? Als er 1 onderwerp is, waar de eeuwige uitzondering vaak op wordt toegepast, dan is het wel: kwaliteit.

Testen kost tijd. Goed testen kost zeker tijd. Bugs fixen kost tijd. Veel bugs fixen nog meer. Als het om kwaliteit gaat, gaat het dan ook vaak om tijd. En als tester moet je begrijpen, dat soms de tijd ergens anders aan besteed moet worden. Dat de tijd soms niet naar kwaliteit kan gaan. Of dit waar is, is een andere blog. Waar het hier om gaat, is dat deze situatie vaak een eeuwige uitzondering creëert.

Als je namelijk aan een bedrijf of een manager vraagt: "Is kwaliteit voor jullie belangrijk?", zal je niet vaak "Nee" te horen krijgen. Officieel ondersteunen bedrijven en managers altijd initiatieven om de kwaliteit te verbeteren. Een goede kwaliteit zorgt voor een betere klanttevredenheid. Opleveren met minder bugs zorgt voor minder onderhoud. Maar als je zo'n initiatief in de praktijk wil gaan brengen, wil er wel eens iets veranderen. Dan moet je soms begrijpen, dat dit moment niet het juiste moment is. Dat de tijd nu even niet beschikbaar is. Dat de prioriteit nu even anders ligt.

Nu kan deze situatie natuurlijk echt een uitzondering zijn. Dus wat maakt een eeuwige uitzondering? Daarvoor wil ik eerst verwoorden wat ik als een echte uitzondering zie. Een echte uitzondering is gebaseerd op tijdelijke argumenten. Als een collega normaal altijd tijd heeft, maar het even druk heeft, is dit tijdelijk. Als er plotseling een project met een hele snelle deadline komt, terwijl de projecten normaal altijd ruim gepland zijn, is dit tijdelijk. Tijdelijke argumenten zijn argumenten, die op een bepaald moment niet meer geldig zijn. En hiermee bedoel ik niet: het argument is opeens niet meer belangrijk. Nee, hiermee bedoel ik: het argument bestaat niet meer.

Dan is de eeuwige uitzondering waarschijnlijk te raden. Als een collega het al jaren druk heeft, is uitstel om de drukte van deze collega vaak een eeuwige uitzondering. Het argument is morgen, over een week, over een maand en over een jaar nog steeds geldig. Wanneer je daarom op dezelfde manier een beslissing neemt, zal het besluit hetzelfde blijven. Een initiatief tot kwaliteitsverbetering wordt hiermee keer op keer een beetje op de lange baan geschoven.

Waarom dan niet gewoon toegeven: "Dit gaat niet lukken"? Je kan en mag eigenlijk geen besluit definitief nemen dat ingaat tegen een "goed doel". Als je weet dat de kwaliteit beter moet, kan en mag niemand toegeven, dat hier geen tijd voor is. Een bedrijf niet, een manager niet en zeker een medewerker niet. Ook al is hier in de praktijk toch echt geen tijd voor. Tegelijkertijd kunnen de argumenten voor de besluiten om de kwaliteit nu niet te verbeteren, niet zomaar veranderen. Je kan niet zomaar zeggen: "Vanaf nu nemen we geen projecten met krappe deadlines meer aan" of "Vanaf nu heeft deze collega tijd voor je".

Wat maakt de eeuwige uitzondering nou zo gevaarlijk, naast het feit dat problemen blijven bestaan? Hij is heel demotiverend en beschadigd het vertrouwen tussen mensen. Als iemand steeds beweert dat hij/zij kwaliteit belangrijk vindt, maar al je voorstellen tot verbetering steeds opnieuw naar achteren schuift, raak je het vertrouwen in deze persoon kwijt. Hij/zij zegt "Ja", maar doet steeds "Nee". En daarnaast motiveert het niet om nog een keer een voorstel te doen. Het gaat toch niet lukken. Tenslotte staan er als X ideeën in de eeuwige wachtrij.

Een extra probleem is, dat eeuwige uitzonderingen moeilijk bespreekbaar zijn. Omdat officieel het streven is en blijft om kwaliteit te verbeteren, kan je niet zeggen "Dit bedrijf/deze manager/deze collega vindt kwaliteit niet belangrijk". Nee, het is officieel het doel de kwaliteit te verbeteren en dat blijft. En staat daarmee niet ter discussie. De besluiten om het niet nu te doen, worden ook elke keer goed beargumenteerd genomen, met een goede afweging van voor- en nadelen. Dus wat voor argumenten hou je over om dit probleem aan te kaarten?

Kan het niet anders? Natuurlijk wel. Eeuwige uitzonderingen voorkom je door de bereidheid negatieve gevolgen te accepteren en zowel aan lange en korte termijn doelen aandacht te geven. Om met het laatste te beginnen: eeuwige argumenten zijn vaak gericht op korte termijn doelen. Nu een deadline halen, nu de klant tevreden stellen met het opleveren van extra werk, nu extra uren bij een collega voorkomen. Door alleen hier aandacht aan te besteden, zal de situatie niet veranderen. Dus blijven er altijd krappe deadlines, zal de klant altijd om extra werk vragen en blijft de collega het druk houden. Alleen door tijd vrij te maken voor lange termijn oplossingen, kan je dit veranderen. Tijd vrijmaken, om te kijken of het werk van de collega sneller of minder kan. Of misschien dat het werk gedeeltelijk kan worden overgenomen. Tijd vrijmaken om een beter afwegingstraject te maken voor krappe deadlines. Wat zijn de echte kosten? Hoeveel is bijvoorbeeld het kwaliteitsverlies door de krappe deadline in geld uitgedrukt? En soms is het: tijd vrij maken voor een kwaliteitsverbetering in product of proces, waardoor de collega meer tijd over houdt. Of waardoor de krappe deadline opeens haalbaar wordt.Of waardoor de klanttevredenheid toeneemt.

Maar dit heeft nadelen. Als je ergens tijd voor vrijmaakt, dan blijft er ander werk liggen. Wat deadlines in gevaar kan brengen, extra geld vraagt voor extra mensen of klagende klanten geeft, omdat ze minder krijgen. Wanneer je niet bereidt bent deze gevolgen te accepteren, ben je zo weer terug bij de eeuwige uitzondering. Ik heb zo vaak gezien dat de eerste de beste klacht van een collega, klant of manager goede initiatieven weer deed stoppen. Verbeteren heeft nu eenmaal ook nadelen! Waarom je het toch moet doen: als je doorzet zijn de voordelen later groter dan de nadelen nu. En dat zijn ook de enige verbeteringen, die je uit moet voeren. Diegene waar de voordelen op lange termijn groter zijn dan de nadelen op korte termijn.

Een goede lezer heeft door: maar als je dit volgt, zal er niet altijd meteen een kwaliteitsverbetering wordt bereikt. Nee, dat klopt. Soms moet eerst het probleem van te krappe deadlines worden opgelost, voordat er tijd beschikbaar komt voor kwaliteitsverbetering. Het grote verschil? Omdat er nu gewerkt wordt aan een oplossing, is te krappe deadlines wel een tijdelijk argument. Je kan nu zeggen: "Zodra we dit probleem hebben opgelost, komt er tijd beschikbaar voor jouw ideeën." Dit kan zelfs het vertrouwen versterken. Door "Probleem 1" goed op te pakken en net zo lang door te gaan tot het opgelost is, komt er vertrouwen dat, als "Probleem 2" aan de beurt is, dezelfde inzet getoond zal worden. En daarmee de kans op slagen flink toeneemt.

Voorkom eeuwige uitzonderingen. Maar nog belangrijker: herken ze. Besef wanneer de argumenten van nu, later niet veranderen. Tenzij je de problemen, die de argumenten veroorzaken, gaat aanpakken. En besef dat dit niet alleen geld gaat kosten, maar ook andere nadelen oplevert. Accepteer deze, als hierdoor de voordelen op langere termijn groter zijn.

Kwaliteit is belangrijk, ik kan als tester niet anders zeggen. Maar niemand heeft er iets aan als kwaliteit belangrijk is, maar toch nooit belangrijk genoeg om te verbeteren. Als dit kan veranderen, door eerst ergens anders tijd aan te besteden, dan ben ik voor! Mits dit tijdelijk is.

Testdata: Het klinkt simpel, maar wat als het niet zo simpel is?

Je kan zelf geen testdata aanmaken. Je hebt niet de luxe om een database terug te zetten. Je data voor vandaag kan morgen niet meer bruikbaar zijn. Je testdata kan maar 1 keer gebruikt worden en daarna nooit meer. Als je minimaal een van deze situaties herkent, is deze blog interessant voor je.

Testdata management wordt vaak beschreven vanuit de ideale omgeving. Je hebt een database, waarin je de testdata inricht. En vervolgens, elke keer als je de testdata opnieuw wil gebruiken, zet je een kopie van de ingerichte database terug. Daarna kan je al je testdata opnieuw gebruiken. Zelf heb ik nooit gewerkt in een omgeving, waar de testdata zo ideaal was. Zelfs als het mogelijk was een kopie van de database terug te zetten, was testdata in de verloop van tijd niet meer bruikbaar. De testdata lag teveel in het verleden.

Maar goed omgaan met testdata kan onder alle omstandigheden, niet alleen bij het ideaal. Ja, soms is het eenvoudiger, soms moeilijker, maar het is altijd mogelijk om een goed testdata proces te hebben. Mijn belangrijkste criterium: elke testcase moet zeer eenvoudig herhaald kunnen worden, waarbij het herhalen van de testcase hetzelfde testresultaat oplevert. En dit kan alleen met een goede keuze van testdata.

De belangrijkste problemen zijn als volgt samen te vatten:

1. Het is niet mogelijk een database terug te zetten
2. Testdata kan niet aangemaakt worden
3. Testdata heeft een beperkte geldigheid door een tijdsaspect
4. Testdata kan slechts 1 maal gebruikt worden, doordat het te testen proces de data verandert of blokkeert
5. Testdata kan niet aangemaakt worden (2) EN heeft een beperkte geldigheid (3) of bruikbaarheid (4)

Database terugzetten niet mogelijk

In nog heel veel organisaties zijn er geen volledig professionele testomgevingen. Hierdoor is de mogelijkheid om een database terug te zetten soms niet aanwezig. In dit geval is het belangrijkste, om testdata aan te maken of te vinden, die herbruikbaar is. Het meest ideaal is, om je eigen testdata aan te maken. Maar soms kost dit heel veel tijd of heb je de kennis niet om dit te doen. In dit geval kan je ervoor kiezen om bestaande data te gebruiken. Het belangrijkste is echter: leg vast welke testdata je gebruikt voor een testcase. En leg daarnaast vast waarom je deze testdata hebt gekozen. Met dat laatste bedoel ik: aan welk criterium moet de testdata voldoen?

Waarom is het vastleggen zo belangrijk? Een van de belangrijkste nadelen als je geen testdatabase kan terugzetten, is dat iedereen de testdata kan aanpassen. Mocht dit gebeuren en je test faalt daardoor, dan moet je heel simpel kunnen nagaan of je testdata nog klopt. Maar als je niet meer weet, waarom de testdata gekozen was, wordt dit een hele klus. Stel je hebt een relatie uitgekozen, omdat deze in Duitsland is gevestigd. Iemand anders heeft echter een test, waarbij het land gewijzigd moet worden. Dus zonder dat je het weet, is je relatie opeens naar Frankrijk verhuist. Wanneer je je gegevens goed hebt vastgelegd, kan je bij het falen van je test snel nagaan: "Wacht even. De relatie is niet meer in Duitsland, maar in Frankrijk".

Testdata kan niet aangemaakt worden

Meestal gebeurt dit, doordat testdata van een externe leverancier komt. Soms is het een beperking in de te testen applicatie. Maar er zijn situaties, waar je niet alle testdata zelf kan aanmaken. In dat geval ben je verplicht om te kiezen uit bestaande testdata.

In deze situatie is het heel handig zijn om je testcases in heel kleine testcases te schrijven. Combineren kan later. Dus als je moet testen op relaties in verschillende landen, met wel of geen fax en waarvan al wel of geen contracten bekend zijn, maak de testcases klein. Maak geen testcase voor een bepaald land, met faxnummer en contracten. Nee, schrijf alle varianten los van elkaar uit. Maak een lijst met de landen, die je wil testen. Maak een aparte lijst voor wel of geen faxnummer. En nog een lijst met wel of geen contracten. Kies daarna een relatie. En streep alle varianten af, waaraan deze relatie voldoet. Noteer ook bij de relatie aan welke criteria deze voldoet. Kies daarna nog een relatie. Streep opnieuw af. En ga zo door, totdat je alle criteria hebt gedekt.

Testdata beperkte geldigheid of 1 x te gebruiken

Sommige testdata is erg gerelateerd aan een bepaalde periode. Denk hierbij bijvoorbeeld aan aanbiedingen met een uiterste geldigheidsdatum, contracten met een einddatum, dagplanningen of reisaanbod. Voor deze testdata heeft het altijd de voorkeur om zelf de data aan te maken. Als het mogelijk is, creëer je testdata zo, dat deze heel lang te gebruiken is.

Data, die slechts 1 x te gebruiken is, vraagt eigenlijk om dezelfde oplossing. Het meest duidelijke voorbeeld is hierbij factureren. Als een opdracht eenmaal gefactureerd is, is het vaak onmogelijk deze nogmaals te factureren. Ook deze testdata moet daarom bij voorkeur steeds opnieuw aangemaakt worden.

Als het nodig is de data steeds opnieuw aan te maken, is er 1 ding heel belangrijk: leg genoeg informatie vast. Hierbij gaat het om alle gegevens, die nodig zijn om snel invoeren mogelijk te maken. Als het niet uitmaakt welke relatie je kiest, hoef je dit niet vast te leggen. Maar moet de relatie uit Duitsland komen, leg dan vast welke relatie uit Duitsland je hebt gebruikt. Als het niet uitmaakt, welke datum je invoert, hoef je niets vast te leggen. Maar als de datum minimaal een week in de toekomst moet liggen, leg dit dan vast. Leg je testdata en (indien nodig) de criteria zo vast, dat je zonder veel tijd de benodigde testdata opnieuw kan aanmaken. Maar leg niet vast, wat niet uitmaakt. Dat zorgt ervoor dat overtypen alleen nodig is, als dit voor de test nodig is.

Beperkte geldigheid of 1 x te gebruiken, maar geen aanmaken mogelijk

Heel soms kom je in de situatie, waarin je zowel niet kan aanmaken, maar je testdata ook nog eens beperkt geldig is of niet aangemaakt kan worden. Dit is vooral het geval, als je testdata afkomstig is van externe bronnen, waar je geen invloed op hebt, maar je wel te maken hebt met een wisselend assortiment of een geheel te testen proces. Wat doe je dan?

Dit zal altijd een wat langer proces blijven. Wat hier het belangrijkst is: maak het jezelf zo simpel mogelijk. Probeer zoekcriteria vast te leggen, die het vinden van juiste testdata simpeler maken. Als je een zonvakantie zoekt, heb je in Spanje een grotere kans, dan in Noorwegen. Grote klanten hebben vaker een geldig contract, dan kleine klanten. Maar elk domein heeft zijn eigen zoekcriteria.

Leg deze zoekcriteria goed vast. En leg ook vast aan welke eisen je testdata moet voldoen. Probeer deze eisen zo laag mogelijk te houden, zodat het vinden niet te moeilijk is. Door deze combinatie kan je je testtijd flink beperken. Echt snel is en blijft moeilijk. Maar verbeteren kan zo wel.

Waarom testers soms worstelen met Agile of Scrum

Een van de meest onbesproken onderwerpen binnen de testwereld zijn de worstelingen, die testers ondervinden, als ze gaan werken in een Agile of Scrum omgeving. Waar kan je als tester tegenaan lopen? En is dit op te lossen?

Ontwikikelaars
Bij Scrum wordt bijna alleen gesproken over ontwikkelaars. Het Scrumteam bestaat uit ontwikkelaars. Verkeerd vertaalt, houdt dit in dat testers geen of slechts gedeeltelijk deel zijn van het ontwikkelteam. Dit kan verschillende gevolgen hebben. Zo heb ik meegemaakt, dat er met testers geen rekening werd gehouden bij het plannen of bespreken van story's. Ook redenaties, dat in een Scrumteam geen testers nodig zijn, kan ik niet helemaal los zien van deze "Scrum = ontwikkelaars" redenatie.

Voor de duidelijkheid: Een Scrum ontwikkelteam bestaat uit ALLE leden, die bijdragen aan een eindproduct. Het verschil is alleen: binnen Scrum wordt niet gekeken of er een lid is dat kan programmeren, een lid dat kan ontwerpen en een lid dat kan testen. Er wordt gekeken of het team kan programmeren, ontwerpen of testen. Alle leden zijn gelijkwaardig en dienen in alle meetings ook gelijkwaardig behandeld te worden.

Planningspoker
Een veelgebruikte techniek is planningspoker. Hierbij worden story's met elkaar vergeleken op basis van complexiteit. En vaak lijkt de nadruk hier te liggen op de complexiteit van de te bouwen code. Testers kunnen hier zelfs zo van overtuigd zijn, dat ze niet echt meedoen met planningspoker. Ze kopiëren gewoon de waardes van anderen. Want wat kunnen zij nu als testers zeggen over de complexiteit? Of er komt een manier om testen apart te pokeren (eerst alleen code door programmeurs, dan alleen testen door testers), want je kan toch niets zeggen over de andere groep?

De kracht van planningspokeren is het uitwisselen van informatie. Juist door de informatie van twee hele verschillende specialisten (zoals programmeur en tester) bij elkaar te nemen, kan je een goed beeld krijgen van de complexiteit. Een tester kan bijvoorbeeld stilstaan bij de raakvlakken met andere processen, waar de programmeur bijvoorbeeld meer kan aangeven over de complexiteit van de aanpassing in de code. Ook is het zo, dat de complexiteit tussen het testen en het programmeren niet vaak grote verschillen heeft. Als iets 2x zo moeilijk is om te bouwen, is het vaak ook 2x zo moeilijk om te testen. En als laatste argument: een goede programmeur is in staat zijn werk te testen en weet daarom ook hoe complex het testen is. En een goede tester weet in grote lijnen hoe complex code aanpassingen zijn, omdat hij/zij hierbij rekening moet houden met de teststrategie. Ja, als team werkelijk aan planningspoker doen is moeilijk, maar als je het lukt, levert het veel op.

Functionele documentatie
De functionele documentatie wordt steeds vaker teruggebracht. Steeds meer informatie wordt mondeling doorgegeven en besproken. Op zich is daar niets mis mee. Het probleem is alleen, dat deze besprekingen niet altijd met alle betrokken leden zijn. Omdat het vaak de ontwikkelaar is, die het eerst aan het werk gaat, is deze vaak ook de eerste, die gaat overleggen. Met iemand, die antwoorden kan geven, dus niet met de tester. Dat is het meest eenvoudig, snel, enz. Deze informatie wordt vervolgens niet of slecht vastgelegd. En de tester krijgt later de taak om deze informatie alsnog te achterhalen.

Overleggen over de functionele werking moeten bij voorkeur minimaal met de programmeur en de tester gevoerd worden. Als dit niet kan, moet de afwezige direct op de hoogte worden gesteld. Bij voorkeur mondeling, anders schriftelijk. En dit moet gebeuren op een waarneembare manier. Dus niet met een wijziging in een stuk bestaande tekst. Maar met een duidelijke "dit is gewijzigd" mededeling.

Het eind van de sprint
Het meest beruchte deel van Scrum voor testers is misschien wel het eind van de sprint. Met de grote vragen:

• Is het testwerk eerlijk verdeeld over de sprint of is het meeste aan het eind?
• Tot wanneer mag het team in de sprint functionaliteit toevoegen?
• Gaan andere leden van het team mee testen of niet?
• Wat doen de teamleden, die niet mee testen, met de rest van hun tijd?

Als de tester pech heeft, leidt deze fase tot veel werk aan het eind van de sprint, door teveel testwerk. Of door de vele begeleiding, die nodig is om anderen ook te laten testen.

Ik heb mijn voorkeuren, maar waar het hier vooral om gaat, is samenwerken. Als je als tester te maken hebt met anderen, die ook testen, moet je als tester ervoor zorgen, dat je hun testwerk vertrouwd. Dit kan door eenvoudig te testen werk het eerst bij anderen neer te leggen of door via testscripts/testcases alvast het belangrijkste voorbereidingswerk te doen. En heb je zelf veel werk aan het eind, bespreek dan hoe je je hier zo goed mogelijk op kan voorbereiden. Bijvoorbeeld door eerder de informatie te krijgen, die nodig is voor de voorbereiding. Waarmee je tijdens de uitvoering tijd kan besparen.

Samenvatting

Scrum en Agile zijn niet tegen testers, al lijkt dat soms wel. Het grote probleem is dat zowel Scrum als Agile uitgaan van een samenwerking tussen alle teamleden, ongeacht specialiteit, functie of discipline. Ondanks de jaren Scrum en Agile merk je dat deze samenwerking nog te vaak tussen alleen programmeurs of alleen testers is. Ik ben hier verantwoordelijk voor en jij bent daar verantwoordelijk voor. Sommige testers denken zelf nog zo. Anderen werken in een team, waar deze gedachte nog aanwezig is. We moeten leren als team te denken. Dus een probleem van een programmeur, is ook het probleem van een tester. En het probleem van een tester, is ook het probleem van een programmeur. Want alle taken, en daarmee alle problemen, zijn de verantwoordelijkheid van het team als geheel. En niet slechts van 1 persoon. Ik hoop dat iedereen, tester of niet, dat ooit eens zal leren.