Waarom consistentie vaak zo moeilijk is

Consistentie. Officieel zal iedereen het natuurlijk belangrijk vinden. Binnen een product moet functionaliteit altijd gelijk werken, ongeacht waar het aangeboden wordt. Binnen een team moeten mensen op een soortgelijke manier werken. Waarom is consistentie dan zo moeilijk? Consistentie vraagt om "verder kijken dan je neus lang is". Consistentie vraagt om kijken naar de hele applicatie, als je bezig bent met 1 functie. Kijken naar het hele team, als je bezig bent met testen. Kijken naar het gehele proces, als je bezig bent met jouw applicatie. Kijken naar de hele organisatie, als je werk doet voor jouw team.

Waarom? Laten we beginnen binnen het team. Stel je hebt al een bestelproces gebouwd. In dit bestelproces was het mogelijk een adres in te voeren. Dit adres is opgeslagen in het klantaccount. Nu wil je de klanten de mogelijkheid bieden om hun adres te wijzigen. Qua consistentie houdt dit het volgende in: in beide schermen moeten dezelfde gegevens staan. Als je bij het bestelproces kon invoeren, dat je op kamer 784 3e etage woont, moet je dit op het te bouwen scherm ook kunnen wijzigen. Als je in het bestelproces een bezorgadres kon invoeren, moet je deze op het te bouwen scherm ook kunnen wijzigen.

Consistentie binnen een ontwikkelproces zal niemand onbelangrijk vinden. Om binnen testen te blijven: als een tester de regressietest belangrijk vindt, moet een ontwikkelaar het fixen van regressietestbugs ook belangrijk vinden. Er moeten afspraken zijn over de invoer ervan bugs, zodat een ontwikkelaar de informatie heeft, die nodig is om het probleem op te lossen. Enz., enz.

Samenwerken als een team en werken aan een product in plaats van een functie is voor te veel teams al moeilijk genoeg. En dan is het voor veel bedrijven niet eens voldoende als je consistentie op orde hebt in een team. De consistentie moet op orde zijn tussen teams onderling. Tenminste: als deze teams werken aan producten, die met elkaar verbonden zijn.

De argumenten zijn niet anders. Stel je hebt binnen je website het invoeren en wijzigen van een adres precies gelijk. In beide kan je aangeven dat je op kamer 784 3e etage woont. Maar vervolgens belt een klant naar de helpdesk om het adres te laten wijzigen. Een ander systeem, dus een ander team. De helpdesk vraagt het adres op om het te controleren. Dan zegt de klant "Dat adres is niet compleet. Ik woon op kamer 784 3e etage". Bij het bouwen van het helpdesk systeem was niet gekeken welke adresgegevens er bij het bestellen werden ingevoerd.

En vergeet consistentie in het proces niet. Neem nogmaals een bestelproces in de webshop. De artikelen worden beheerd in de backend. Dus in team A. Dit team heeft "Artikelen" als hoogste prioriteit en bouwt het, zodat team B deze straks kan tonen op de webshop. Team A is klaar en levert het werk op. Vervolgens krijgen ze een andere eerste prioriteit, tenslotte is het werk af. Team B gaat vervolgens de artikelen in de webshop tonen. En hierbij ontdekken ze een bug in het onderdeel "Artikelen". Maar bij het melden aan team A is het antwoord: "Artikelen heeft voor ons nu geen prioriteit. Dus je zal moeten wachten".

Consistentie heeft als grote probleem, dat niemand het belang ervan ontkent. Maar als je aan "Klantgegevens wijzigen" werkt, sta je er vaak niet bij stil dat "Product bestellen" hier een belangrijk raakvlak mee heeft. Het zijn tenslotte twee hele verschillende processen, die los van elkaar staan. En als je geconcentreerd aan het testen bent, kan je wel eens vergeten dat ontwikkelaars de informatie in gevonden bugs later ook moeten gebruiken. Het lijkt op dat moment niet belangrijk. Testen is nu tenslotte prioriteit 1. En datzelfde geldt breder. Als deel van het "helpdesk" team lijkt het "webshop" team nu niet echt belangrijk, niet hun product en niet hun proces. En dat maakt consistentie nu zo ontzettend moeilijk. Je moet stil staan bij belangrijke zaken, die voor jou op dat moment eigenlijk niet belangrijk zijn. Veel succes!

Alleen in een team

Als tester ben je met enige regelmaat de enige tester in een team. Dit geeft soms communicatieproblemen, vooral als het gaat om problemen, waar je als tester tegenaan loopt. Je bent de enige met het probleem. Daarnaast begrijpen anderen in het team niet altijd hoe belangrijk of groot een probleem is, als ze het probleem al begrijpen.

Scrum of Agile werkt op dat gebied ook niet altijd mee. Het team staat centraal, dus problemen van een individu kunnen daardoor minder belangrijk worden. Zowel de retrospective als een backlog refinement zijn voornamelijk bedoeld voor communicatie, die voor het hele team van belang is. Niet alleen voor jou als tester.

Deze situatie mag en moet niet inhouden, dat er voor jouw problemen geen plaats is. Tegelijkertijd is het ook niet de bedoeling dat jij "de uitzondering in de groep" wordt. Oftewel de persoon, die gewoon geloofd moet worden als het om problemen gaat. Terwijl de rest van de groep enige overtuigende argumenten moet hebben. Hoe pak je dit aan?

Gebruik teamargumenten

Als het mogelijk is, gebruik dan geen argumenten, die alleen van toepassing zijn op testen. Zeg niet "Dit maakt het voor mij moeilijker om te testen". Zeg "Door dit probleem kan ik minder stories in de sprint testen". Argumenten rond "meer testen in de sprint", "sneller testen in de sprint", "betere kwaliteit van het op te leveren product" of rond andere teamdoelen werken beter dan argumenten, die alleen jou als tester treffen.

Gebruik concrete cijfers

Omdat niet-testers vaak moeite hebben om zich in testproblemen te verplaatsen, kan het zeker handig zijn om te spreken in concrete cijfers. Denk hierbij aan voorbeelden als 

• Als we dit probleem oplossen, kan de test van 4 uur terug gebracht worden naar 2 uur
• Wanneer we dit anders aanpakken, kan ik zeker 25% meer stories in de sprint testen
• Dit probleem kost mij elke dag zeker een uur

Gebruik testargumenten in 1-op-1 gesprekken

Soms is er gewoon geen teamargument. En zijn er geen overtuigende concrete cijfers te maken. Dit kunnen bijvoorbeeld veelvoorkomende, kleine problemen zijn, die je steeds opnieuw 10 minuten kosten. 10 minuten, die je niet kan missen, als je net geconcentreerd met iets belangrijks bezig bent. Maar een tijdsbesteding, die nou niet direct een team kan overtuigen. Of een communicatie, die niet lekker loopt, waardoor je iets 3 x moet vragen, in plaats van 1 x. Niet dat het veel tijd kost, maar het is wel iets wat je steeds in de gaten moet houden. Wat een probleem kan zijn, als je het drukker krijgt.

In elk team zijn mensen, waarmee je over testen kan praten. Vaak de Scrummaster of een teamleider. Maar er zijn in elk team ook mensen, die geïnteresseerd zijn in een goede samenwerking, tevreden collega's, kwaliteit van een product of zelfs in testen. Afhankelijk van het onderwerp kan je je probleem met zo'n persoon bespreken. Dit kan zijn om te kijken hoe je het team kan overtuigen. Maar een concrete oplossing kan ook het resultaat zijn.

Besef ook dat het overtuigen van het team niet altijd nodig is. Veel weerstand tegen het bespreken van "niet belangrijke" problemen, komt doordat het bespreken tijd kost. En niet iedereen kan of wil tijd steken in problemen, die voor hem of haar niet van belang zijn. Als je echter met een concreet voorstel komt, dat je team niet of nauwelijks tijd kost, zal je vaak geen tegenwerking tegenkomen.

Benoem je problemen, ook als je ze niet bespreekt

De neiging kan zijn om je problemen voor je team te verzwijgen. Ze hebben er toch geen aandacht voor. Hoe begrijpelijk ook, dit is niet verstandig. Zorg ervoor dat je team op de hoogte is van de belangrijkste problemen, waar jij als tester tegenaan loopt. Maar geef tegelijkertijd aan, dat dit wat jou betreft niet meteen opgelost hoeft te worden. Bespreken van een oplossing kan op een ander moment.

Het benoemen van onbegrepen problemen kan een afstand tussen jou en het team creëren. Maar het verzwijgen van problemen doet dat met 100% zekerheid. Je zal 100% zeker nooit een oplossing vinden en dat feit kan zeker bij jou spanning gaan veroorzaken. Maken dat je niet lekker werkt in het team. En dat zal alsnog een afstand creëren tussen jou en je team. 

Blijf onderdeel van het team, zonder jezelf te vergeten

Zorg ervoor dat je in een team voor jou problemen de argumenten vindt, die je teamgenoten kunnen begrijpen en accepteren. Zoek argumenten, die aansluiten bij algemene team doelen en beschrijf ze bij voorkeur in concrete getallen. Als dit niet mogelijk is, zoek iemand, die je kan helpen. Bespreek het probleem alleen met deze persoon. Een eventuele oplossing kan dan aan het hele team voorgesteld worden. Maar het allerbelangrijkste: verzwijg je problemen niet. Ook al zijn het problemen van jou alleen... elk probleem van jou is uiteindelijk ook het probleem van het team.

Reactief en proactief testen: wat is het en waarom is het beide nodig?

Reactief en proactief testen: het zijn geen officiële testtermen. Toch merk ik dat ze voor mij steeds meer een belangrijk onderwerp worden. Wanneer test je op basis van incidenten, wanneer op basis van strategie? En waarom is beide nodig?

Bij reactief testen test je op basis van "wat moet er nu getest worden". Hierbij moet je denken aan gebouwde story's, gemelde bugs. Maar ook op basis van klachten en zorgen van klanten, managers, helpdesk, collega's. Je reageert met je testen op wat er in je omgeving gebeurt.

Bij proactief testen test je op basis van een strategie. Dit kan een testtechniek zijn, een risicoanalyse, een analyse van de fouten gevonden in de afgelopen maand. Het grote verschil: hoewel de opgeleverde story's en bugs en ook de klachten en zorgen meetellen, zijn ze niet doorslaggevend. Je kan besluiten om een bug niet te testen of een klacht te negeren.

Ik weet: de scheiding is niet zo strikt. Je kan reactief een story testen, maar deze story vervolgens proactief testen met behulp van een gekozen testtechniek. Of je kan op basis van een proactieve risicoanalyse besluiten om alle bugs reactief te testen. Het belangrijkste is: je hebt als tester een andere rol. Bij reactief doe je wat er van je gevraagd wordt: testen wat getest moet worden. Bij proactief doe je wat er van je verwacht wordt: de kwaliteit bewaken.

Je kan niet altijd de hele omgeving negeren als tester. Opgeleverd werk moet getest worden. Bugs moeten gecontroleerd worden. En klanten of managers hebben eisen en verwachtingen. Als de prioriteit hoog genoeg is, kan je niet als tester zeggen: kan best, maar ik test het niet, want het komt niet overeen met mijn strategie.

Maar je kan ook niet altijd zeggen: ik test gewoon alleen wat er van me gevraagd wordt. Waarom? Dat heeft te maken met een vaak vergeten balans. Iedereen kent de balans van tijd v.s. kwaliteit. Als je minder tijd krijgt, gaat over het algemeen de kwaliteit achteruit. Maar zo is er ook een balans tussen kwaliteit v.s. kwaliteit. Je hebt als tester maar x uur in de week. Als je deze aan programma A besteed, kan deze niet naar programma B. Als je deze aan performance testen besteed, kan deze niet naar functioneel testen. En als je minder tijd kan besteden aan programma B of functioneel testen, is de kans groot dat de kwaliteit van deze applicatie of dit onderdeel gaat afnemen.

Om dit te voorkomen heb je een soort basisdekking nodig. Een soort gegarandeerde minimale tijd of dekking, die een test of een programma of een ander los te testen onderdeel nodig heeft. Dit kan letterlijk tijd zijn. Maar ook een groep eisen, die minimaal getest moeten zijn. Een automatische test, die minimaal uitgevoerd moet zijn. Wat er nodig is, zal je als tester moeten bepalen. En, en dit is het moeilijkste, dit zal onder alle omstandigheden moeten plaatsvinden. Ook als het druk is, ook als het je niet uitkomt, ook als hierdoor een deadline in gevaar komt. Je kan altijd proactief besluiten om meer te testen, maar deze minimale dekking moet plaatsvinden. Zo zorg je ervoor dat de balans nooit teveel doorslaat van A naar B.

Waarom is dit nodig? Vooral in drukke tijden ontstaat de neiging om "per dag" te leven. En als een team onder druk wordt gezet, ontstaat de neiging om "per managerswens" te leven. Je test wat wordt aangeleverd en wat je omgeving van je vraagt. En wat niet wordt gevraagd of wordt aangeleverd, test je niet. Totdat wordt opgemerkt dat in deze opleveringen wel erg veel fouten zitten. Dan opeens wordt het werk geconcentreerd op dit probleem. En ontstaat er precies zo'n zelfde situatie op andere plaatsen. Plaatsen waar jij nu niet test. Zo spring je, als je niet oppast, van de ene critical situation naar de andere critical situation. En zou het dan niet veel beter zijn om een volgende critical situation te voorkomen?

Ja, reactief testen is nodig. Wat opgeleverd is, moet getest worden. En in elke organisaties zijn er nu eenmaal prioriteiten, waar je als tester rekening mee moet houden. Maar je moet wel je testersvaardigheden blijven inzetten. Zorg ervoor dat je alles zo blijft testen, dat je een zekere kwaliteit kan blijven garanderen. Dat de kwaliteit van een oplevering niet alleen afhankelijk is van de externe omstandigheden, maar ook van jou kennis en ervaring als tester. Blijf altijd proactief testen. Het zal niet altijd makkelijk zijn, maar uiteindelijk zal het zowel jou als je organisatie meer rust geven.

Hoe groot de afstand ook is - of een probleem is opgelost bepaald er maar één

Op het moment dat ik dit schrijf, zitten we in de Corona crisis. Wat betekent: veel thuiswerkers. Dus ook: veel vaker afstand tussen mensen. Dat maakt het onderwerp "Problemen oplossen op afstand" misschien actueler. Maar voor mij is "Problemen oplossen op afstand" altijd actueel geweest.

Wat is een "Probleem oplossen op afstand"? Dit klinkt misschien simpel. Als de melder van een probleem en de oplosser van een probleem niet in hetzelfde gebouw zijn, is er sprake van een probleem oplossen op afstand. Maar er zijn meer afstanden. Een hiërarchische afstand, waarbij een medewerker van een bedrijf via minimaal 2 lagen managers moet communiceren om een probleem opgelost te krijgen. Een organisatorische afstand, waarbij problemen via managers of afgesproken contactpersonen met andere afdeling of teams gecommuniceerd moet worden. Een communicatie afstand, waarbij melder en/of oplosser niet over voldoende vaardigheden of moed bezitten om rechtstreeks met elkaar te communiceren. En misschien kan je zelf nog meer varianten bedenken.

Nee, deze situaties zijn niet standaard fout. Nee, deze situaties moeten niet standaard vermeden worden. Waar het mij in deze hele blog om gaat is besef. Beginnend bij het besef dat de afstand er is.

OK, dit is een testblog, dus even een relatie met testen. Als tester zit ik regelmatig aan beide kanten. Ik ben als tester heel erg van "Gebruik de tools van het bedrijf". Als dit al niet als eis gesteld wordt door het bedrijf zelf. Dat brengt mij regelmatig in de situatie, dat ik bij het begin van een nieuwe baan, de tools waarmee ik moet werken niet goed ken. Waardoor ik in de "Ik heb een probleem met tool X" situatie terecht kom. Aan de andere kant ken ik als tester het "op afstand problemen oplossen" binnen het "oplossingstraject" ook uitstekend. Ook ik heb regelmatig bugs getest, goedgekeurd en daarna te horen gekregen "Het probleem is niet opgelost". Anders gezegd: zowel als melder en als deel van het oplosteam, dit onderwerp speelt in mijn werk een grote rol.

Zoals ik al schreef, het gaat mij vooral om besef. Beginnend met het besef "Er is afstand". Beseffen dat woorden en zinnen, en daarmee probleemomschrijvingen, verkeerd kunnen worden begrepen. Door jou als luisteraar of door luisteraars voor je. Zodat je niet boos of geïrriteerd reageert als je erachter komt "dat het probleem nog steeds niet is opgelost".

Maar het gaat om meer. Het gaat om het besef van het verschil tussen de zinnen "Is het probleem opgelost?" en "Is jouw probleem opgelost?". Wat dat verschil is? Thuiswerken is nu heel actueel, dus ik neem dat als voorbeeld. Als iemand thuis geen internetconnectie heeft en daardoor niet thuis kan werken, dan zal het probleem vaak gemeld worden als "Ik kan niet thuiswerken, want ik heb geen internetconnectie". Vervolgens gaat dit het oplossingskanaal "Internetconnectie regelen" in. Dus het probleem is: "Internetconnectie moet geregeld worden". Dat houdt echter niet in, dat als deze persoon een internetconnectie heeft, plotseling thuis kan werken. Voor hetzelfde geld blijkt nu dat deze persoon geen toegang heeft tot webapplicaties, die voor het werk nodig zijn.

Het probleem: Geen internetconnectie
Zijn of haar probleem: Kan niet thuiswerken

Een ander voorbeeld: een nieuwe medewerker moet 20 applicaties kennen. Maar hij/zij weet maar van het bestaan van 5 af. De rest is niet verteld, want "was nog niet nodig". Nu stelt deze medewerker heel netjes vragen over de 5 applicaties en wordt hierop ingewerkt. Als dit is afgerond en de medewerker heeft geen vragen meer, betekend dat niet automatisch dat deze medewerker ingewerkt is. Dat is pas het geval als de medewerker alle 20 applicaties kent en kan gebruiken.

Het probleem: 5 applicaties onbekend
Zijn of haar probleem: Nog niet volledig ingewerkt

Het allerbelangrijkste besef, waarmee ik terug kom bij de titel van mijn blog, is het besef dat er slechts één persoon is, die bepaald of een probleem is opgelost. En dat is de melder. Hoe vaak ik ook bugs op opgelost zet, ik besef me altijd dat alleen de melder dit echt kan bepalen. En ik doe altijd mijn best om het voor de melder ook echt op te laten lossen.

Een ander voorbeeld: Als ik een probleem moet bespreken binnen mijn team, probeer ik altijd de afstand zo klein mogelijk te maken. Zelfs nu ik thuiswerk, streef ik ernaar dat bij problemen, melder en oplossers elkaar minimaal kunnen spreken én zien. En ik hoop, al is dat ter oordeel van mijn collega's, dat ik altijd even naga of een probleem ook echt is opgelost. Opgelost voor de melder dus.

Het is niet altijd mogelijk of handig dat oplosser en melder direct en goed met elkaar communiceren. Of volledig kunnen communiceren met woord, toon, houding en gebaren. Het besef dat je hierdoor een probleem niet oplost of niet volledig oplost, zelfs als je dat wel denkt (zelfs als je dat echt wil), kan helpen hiermee om te gaan. Een simpele "Is je probleem nu opgelost?" i.p.v. een "Dit probleem is nu opgelost!" kan al helpen. Of een "Als er meer problemen zijn, je weet me te vinden."

Een andere manier om te helpen, is het volgende: Als je meer kennis hebt, dan iemand anders, kan je die kennis gebruiken om problemen te voorspellen. Bijvoorbeeld: als je weet dat er nog 5 applicaties zijn, waar iemand vragen over kan hebben, kan je alvast afspraken maken wanneer deze kennis overgedragen wordt. Of hoe vragen gesteld kunnen worden. En niet afwachten tot de ander naar je toe komt.

Besef dat je door afstand soms het probleem niet goed kent. En daarom niet kan bepalen of het opgelost is. Al kan je wel helpen de kans op niet oplossen te verkleinen, door te helpen het probleem beter in beeld te krijgen. Of helpen door, via de communicatie die mogelijk is, de afstand in ieder geval zo veel mogelijk te verkleinen.

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!