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!