Zondebokken zonder zondebokken

Stel, je hebt een machine. Op deze machine zit een knop. Hier staat met grote letters bij "Niet op deze knop drukken". Als je namelijk op deze knop drukt, leg je de hele machine stil. Toch zijn er steeds opnieuw weer mensen, die op de knop drukken. Wat doe je?

De reden dat ik hieraan denk, is door zaken waar ik de laatste tijd zelf veel tegenaan loop. Ik vind het belangrijk om problemen te benoemen. En ja, dat komt regelmatig neer op: collage x deed y en daardoor is probleem z ontstaan. Regelmatig kom ik mensen tegen, die daardoor automatisch ervan uitgaan, dat ik de schuld bij collega x neerleg. En ja, soms doe ik dat ook. Meestal echter niet. Ik wil de situatie beschrijven, het probleem beschrijven. In mijn ogen zijn we nog lang niet toe aan het aanwijzen van een schuldige. Als we dat al ooit zijn.

Stel dat ik als tester een ernstige bug gemist heb. Een die nooit in productie had mogen komen. Hoe ga ik hiermee dan mee om? Voor mij is dan de eerste vraag: "Had ik dit kunnen voorkomen?" Dit is een vraag naar kennis, ervaring en tools. Beschikte ik over de kennis om de bug te voorkomen? Dit kan gebeurt zijn in een scherm, waar nooit iemand me over verteld zijn. Via een programma, waarvan ik het bestaan niet wist. Ook kan het zijn, dat ik het wel wist, maar niet kon testen. Voor dit scherm heb ik namelijk de rechten niet gekregen. Of ik beschik niet over voldoende testdata om die betreffende situatie na te gaan. Bij zulke problemen is het antwoord: "Nee, dit had ik niet kunnen voorkomen". De oplossing gaat dan ook in de richting van meer kennis, betere tools. En soms is het gewoon: "Nu ik dit weet, gaat dit niet nog een keer gebeuren". 

De volgende vraag is een stuk moeilijk: "Had ik het moeten voorkomen?". Ik werk 40 uur per week en deze tijd moet ik verdelen over al mijn werk. Daarom moet ik keuzes maken in wat ik wanneer test en hoe. Waar ik mijn tijd aan besteed. Stel ik heb scherm A minder heb getest, omdat ik scherm B beter wilde testen. Vervolgens heb ik door het testen van scherm B 5 ernstige bugs voorkomen, was dit dan een verkeerde keus? Zelfs als later blijkt dat in scherm A alsnog een grote fout zit? En wat als ik inschat dat de kans op een fout in scherm A zeer klein is, maar in scherm B groot. Vervolgens test ik scherm B beter en vind niets. Was dat een foute keuze, als scherm A later een ernstige bug blijkt te hebben? Want wat als ik zeg "Ja" en ik kies dan scherm A beter te testen, maar later blijkt mijn inschatting juist en hierdoor gaat scherm B naar productie met 5 ernstige fouten?

Deze vraag heeft te maken met risico inschatting. En hier is een goed besef nodig van het volgende: ook als het verkeerd uitpakt, kan de risico inschatting goed zijn geweest. Daarom is van belang niet naar het resultaat te kijken, maar naar het proces. Hoe is het risico bepaalt? Want ja, regelmatig blijkt dat het risico niet goed is ingeschat. Omdat een aanpassing toch meer code raakte dan ik dacht. Of omdat een proces belangrijker was dan gedacht. Maar het antwoord kan ook zijn: de risico inschatting was goed, ongeacht het ongewenste resultaat. De kans was 1 op 1000 en dat was bekend. Helaas was dit de 1 op 1000.

Wat het verschil is met de eerste vraag? Ja, ik heb nu misschien ook kennis gebrek, maar met de kennis, ervaring en tools die ik had, had ik de bug wel kunnen voorkomen. Ik besloot echter tot handelingen, waardoor de bug gemist is.

Als beide vragen "Ja" zijn, komt de laatste vraag: "Waarom heb ik de bug niet voorkomen?" Waren er teveel testen, waardoor ik op de automatische piloot ging werken? Waren er te weinig testen, waardoor ik zaken vergeten ben? Was ik te druk, waardoor ik niet geconcentreerd genoeg was? Lette ik op teveel zaken tegelijkertijd, waardoor ik niet meer 100% kon geven? Als ik de oorzaak weet, dan kan ik op zoek naar een oplossing.

Waarom dit hele verhaal? Omdat een veelgebruikte of veelgenoemde oplossing hier niet tussen staat: tegen mij zeggen dat ik de volgende keer beter moet testen. Zelfs niet: tegen mij zeggen dat ik de volgende keer scherm A moet testen, omdat deze een ernstige bug bevat. Waarom niet? Om twee redenen:

• Ik ben ervaren genoeg om te weten dat dit niet nog een keer mag gebeuren. Over het algemeen hoef je me dat niet te vertellen.

Maar wat voor mij nog veel belangrijker is:

• Door zulke opmerkingen suggereer je dat ik iets fout heb gedaan, iets beter had kunnen doen. Puur alleen om het feit dat er iets fout is gegaan. En hoewel je gelijk kan hebben, kan je net zo goed ongelijk hebben. Puur het feit dat door mij een fout in productie is gekomen, zegt nog niet dat ik de bug had kunnen of moeten vinden.

Ik hecht veel belang aan het goed evalueren van een probleem of bug. En ik weet dat de enige die me daarbij kan helpen collega x is. Daarom, als ik zeg dat collega x door y probleem z heeft veroorzaakt, bedoel ik: we hebben collega x nodig om dit probleem in de toekomst te voorkomen.

Dus die machine met die rode knop? Ik zou gaan praten met alle mensen, die erop gedrukt hebben. Hoe en waarom dat gebeurt. Hoogstwaarschijnlijk zou ik niet de tekst "Niet op deze knop drukken" groter maken. Of elke maand mensen eraan herinneren dat ze goed moeten lezen voor ze iets doen. Waarschijnlijk zou ik kijken of we de knop kunnen verplaatsen naar een minder zichtbare plek. Of de knop afdekken, zodat je er niet zomaar op kan drukken. Want het werkelijke probleem zal waarschijnlijk zijn: het is veel te makkelijk om op de knop te drukken voor een knop, die bijna nooit nodig is.

Iedereen mag fouten maken en daarom.... mag iedereen fouten vinden

Iedereen maakt fouten. En daarom zijn er testers. Om fouten van anderen te vinden. Maar er is meer. Dit houdt ook in dat de tester fouten maakt. Ja, er is tegenwoordig steeds vaker de houding van "Iedereen mag fouten maken", de tester is daar geen uitzondering op. Maar ik mis de vervolgstap. Voor mij, als iedereen fouten mag maken, mag iedereen ook fouten vinden.

Als je kijkt naar redenen voor fouten, zijn de gebieden waar ik aan denk: informatiegebrek, kokervisie, verkeerde prioritering, miscommunicatie, zaken vergeten, zaken gemist, enz. Sommige van deze problemen kunnen opgelost worden met een tweede paar ogen. Al of niet een tester. Sommige niet. Kokervisie is daar het meest duidelijke voorbeeld van. Dit doet zich vaak voor bij een groep personen. Bijvoorbeeld de testers in een bedrijf of de team werkend aan een product. Neem de groep testers. Deze kan bijvoorbeeld heel erg gefocust raken op regressietesten. En alle tijd en aandacht zo ongeveer daaraan besteden. Maar door deze extra besteedde tijd kan het gebeuren, dat de validatie van gegevens opeens veel meer fout gaat. De tijd voor de regressietestverbetering moet tenslotte ergens vandaan komen. Dit wordt echter niet gezien, want de focus ligt nu op de regressietestbugs. En de validatiebugs vallen daar niet onder. Dan heb je een niet-tester nodig, die bijvoorbeeld zegt: "Hoe kan het dat we opeens heel veel problemen hebben met ongeldige gegevens in onze database?"

Waarom is dit van belang voor een tester? Als tester ben je vaak het tweede paar ogen, waardoor anderen fouten mogen maken. Een belangrijk paar ogen. Daarom moet je beseffen dat ook dit paar ogen af en toe een fout maakt. En dat je er als tester naar moet streven om dit te voorkomen. Wat betekent dat je open moet staan voor fouten, die gevonden worden door anderen. Niet alleen andere testers, maar ook andere collega's, misschien wel van andere teams of afdelingen. En misschien zelfs wel van andere bedrijven. Om dit te promoten is het belangrijk dat je als tester een omgeving creëert, waarin mensen zich vrij voelen bugs te melden. Hoe doe je dit?

Beoordeel bugs zo objectief mogelijk

Wat ik vaak zie en hoor is dat de bron van de bug zwaar wordt meegenomen in de beoordeling. Of een bug in productie is, of hij van de manager afkomt, of hij van een tester afkomt, of de bug geëscaleerde is. Nee, ik ga niet schrijven dat dit totaal niet uitmaakt. Als je twee major bugs heft en 1 is in productie, los je diegene in productie op. En ja, als je twee critical bugs hebt, kan het verstandig zijn die van de manager eerder op te lossen.

Waar het om gaat is dat je de beoordeling van blocking, critical, major, minor, trivial niet laat afhangen van de bron. Dus als een manager een major bug heeft gevonden, maar aan de lunchtafel hoor je een collega van een heel ander team over een critical bug, dan gaat de critical bug voor. Wat voor criteria je ook gebruikt voor deze indeling, wie de bug gemeld heeft is hiervoor niet van belang.

Waarom is dit belangrijk? Ooit wel eens een probleem verteld en te horen hebben gekregen "Je kan best gelijk hebben, maar dit heeft voor de manager/het bedrijf geen prioriteit". En heeft dit je ooit gemotiveerd om problemen te blijven melden? Voor het melden van bugs werkt het niet anders.; Een argument als "Van deze bug hebben niet al teveel klanten. Daarom geef ik voorrang aan bugs, die meer klanten raken." kan iemand misschien tegenhouden elke bug te melden. Maar als er iets ernstigs is, blijft de kans groot dat je het te horen krijgt. "Ik heb al een lijst met 50 bugs van mijn manager en die moeten eerst" kan elke bugmelding blokkeren.

Leg uit waarom

Als tester prioriteer je misschien naar testverbeteringen. Als expert zal je dan snel de neiging hebben mensen gewoon te vertellen wat je wil. Jij bent de expert, dus jij beslist. En in veel gevallen zal dit geen duidelijke problemen geven. Je zal meestal gevolgd worden. Tot je prioritering of verbetering een fout besluit is. En niemand dat kan zien, want het enige wat ze kunnen zien is dat je doet wat je hebt gezegd.

Als je aan iemand verteld wat je gaat testen of hoe je gaat testen, vertel dan ook waarom. Vertel wat je wil bereiken. Minder bugs in productie, een sneller testproces, meer kennis van de applicatie, het maakt niet uit. Of in het geval van testen: een goed werkende validatie, goede integratie met andere apps, enz. Maar vertel altijd je doel. Naast draagvlak, wat altijd handig is, zorgt dit voor iets anders. Als jij met je ideeën je doel niet bereikt, kan dat ook door anderen opgemerkt worden. Als jij de testtijd verdubbelt om de bugs flink terug te brengen, kan iemand opmerken dat voor een verdubbeling van de tijd 10% minder bugs niet veel is. En dat het aantal grote bugs zelfs bijna gelijk is gebleven. Zodat de vraag gesteld kan worden: is dit wel de juiste weg voor het doel dat je wil bereiken.

Neem iedereen serieus

Ook als tester kan je verstrikt raken in problemen als kokervisie en informatiegebrek, waardoor je ernstige fouten mist. En als je team of directe collega's dezelfde kokervisie hebben of dezelfde informatie missen, kunnen zij je hier niet bij helpen. Daarvoor heb je een buitenstaander nodig. Die persoon dus, die vaak als lastig wordt gezien, omdat die zich met zaken bemoeit, waar hij/zij geen verstand van heeft.

Als iemand denkt een bug te hebben gevonden en dat wil laten weten, neem daar altijd de tijd voor. Geef altijd een reactie. Als iemand een onbelangrijke of onterechte bug meldt, leg uit waarom. Maar probeer te voorkomen dat je reactie overkomt als "Val me hier niet mee lastig". Hoewel dit misschien de meest logische is, is dit tegelijkertijd de moeilijkste. Als iemand zegt "Waarom heb je die bug niet gevonden?", terwijl je weet dat geen klant die bug ooit zal vinden, krijg je de neiging om te denken "Hoepel even op". En als iemand steeds opnieuw kleine, onbelangrijke bugs meld, of nog erger, onterechte, krijg je de neiging die persoon te negeren. En toch moet je blijven proberen deze personen serieus te nemen. Allemaal. Altijd

Dus iedereen mag fouten vinden, tester of niet

Het belangrijkste is te beseffen dat je als tester anderen nodig hebt om goed te blijven testen. Niet alleen je manager, andere testers of teamgenoten, maar soms ook buitenstaanders. Dit geldt zeker als het aankomt op het melden van bugs, die je misschien gemist hebt. Maar geldt ook voor je testaanpak of je testverbeteringen. Geef iedereen daarom het gevoel dat ze fouten bij je kunnen melden, wat het onderwerp ook is. Geef ze het gevoel serieus genomen te worden. En help je omgeving om je op fouten te betrappen, door ze te informeren over je doelen als tester. Hoewel dit allemaal niet zo eenvoudig is, zal je er uiteindelijk als tester door groeien.

Hoe streven naar tevreden collega's/managers/medewerkers kan leiden tot wantrouwen

We zijn graag aardig tegen elkaar en veel van ons willen daarom graag de ander een plezier doen. Daar lijkt niets mis mee. Maar als je hier te ver in gaat, kan er wantrouwen ontstaan. Omdat, wat een goede daad lijkt, uiteindelijk de persoon/het team zelf en/of zijn of haar omgeving schaadt.

Wat doet dit in een testblog? Ik heb dit als tester met grote regelmaat zien gebeuren. Ik heb het zien gebeuren met testers. Ik heb het zien gebeuren door testers. Het onderwerp is van belang voor testers, omdat hun positie in het bedrijf vaker een minderheidspositie is en daardoor het team tevreden houden een belangrijk onderdeel is. Het onderwerp is belangrijk voor mensen, die met testers werken, omdat testers tevreden houden, zodat ze willen blijven, juist bij testers regelmatig belangrijk wordt gevonden. En omdat hun positie van "aangeven wat er fout is" ervoor kan zorgen, dat je juist hun wil negeren om het team tevreden te houden.

Voor de duidelijk: in deze blog spreek ik van kritiek en niet van het sociaal acceptabeler feedback. Dit is bewust. Feedback is een term, die beter bekend staat, omdat het een combinatie is van wat goed ging en wat fout ging. Kritiek heeft een negatieve naam en kan daarom het idee geven, dat alleen zeggen wat fout ging, altijd verkeerd is. En dat vind ik juist een van de problemen. Om dit beter uit te laten komen, houdt ik daarom dit woord aan.

Streven naar tevredenheid kan, in mijn ervaring, op zeker drie manieren leiden tot wantrouwen

1. Je aanpassen aan de wensen van anderen
2. "Ja, dat doe ik" zeggen
3. Niet geven van kritiek

Je aanpassen aan de wensen van een ander

Het klinkt zo mooi. Een leidinggevende, ondergeschikte of collega, die altijd precies doet wat jij wilt. U zegt, zij draaien. En voor jou is het waarschijnlijk ook zo mooi. Waarom niet? Je krijgt wat je wil. En de andere kant: het klinkt ook zo simpel om mensen blij te maken. Doe gewoon wat ze willen en ze zullen tevreden zijn. Je zal deel uitmaken van het team, gewaardeerd worden. Dat kan toch niet anders?

Bijna altijd is het anders. Mensen, die bekend staan om hun aanpassen aan anderen, staan vaak bekend om het feit, dat ze hun werk niet goed uitvoeren. En mensen, die hun werk niet goed uitvoeren, worden niet gewaardeerd en niet vertrouwd. In veel omgevingen worden dit soort mensen als gevaarlijk gezien, omdat ze producten, projecten en soms zelfs banen in gevaar kunnen brengen. Vooral doordat ze verkeerde beslissingen nemen en fouten of problemen over het hoofd zien of negeren.

Doordat ze zich aanpassen, hebben ze echter vaak mensen, die hun werk wel waarderen. En dat zijn de mensen, die door deze aanpassers geholpen worden hun eigen doelen te bereiken. Als of de aanpasser of de tevreden persoon in een leidinggevende positie zit, kan dit een hele slechte werksfeer opleveren, waarin wantrouwen in het team centraal staat. Want waar kan je nog veilig het functioneren van deze persoon bespreken?

Hoe komt dit? Een aanpasser past zijn of haar werk aan aan de wensen van een ander. Even voor het gemak uitgaan van een tester, zullen deze wensen vaak niet van een andere tester komen. Dat betekent dat een tester test zoals de leidinggevende, ontwikkelaar, enz. wil. En dat betekent dat er geen gebruik wordt gemaakt van de kennis en vaardigheden, die een tester als tester heeft. Wat hem of haar uniek maakt of kan maken binnen een team. De kennis en vaardigheden, die erop gericht is de problemen in een product te vinden. Te testen op een manier, waar niemand aan gedacht heeft. Bijvoorbeeld meer focus op de integratie, in plaats van op de losse onderdelen.

Als een ontwikkelaar, leidinggevende, enz. goed genoeg zou testen, om zijn of haar wensen als leidraad te nemen voor testen, dan zou er geen tester nodig zijn. Dan kan iedereen testen. Maar als je geloofd dat een tester nodig heeft, moet je ook promoten dat een tester zijn of haar eigen pad bewandeld. Wat inhoudt, dat hij of zij niet altijd zal doen wat jij zou doen. Of wat inhoudt dat jij niet altijd doet, wat hij of zij wil.

Het is niet erg om de ideeën en meningen van anderen mee te nemen, als je je werk doet. Maar wat van belang is, is dat je zelf verantwoordelijk blijft voor de besluiten rond je werk. Op lange termijn zullen mensen meer tevreden zijn, als je je werk goed doet, dan als je ze hun zin geeft. Ze zullen leren vertrouwen op je kennis en vaardigheden, omdat ze zien dat je goed werk levert. En iemand die goed werk levert, levert een bijdrage aan een tevreden team en tevreden bedrijf. En dat draagt weer bij aan tevreden collega's, leidinggevenden en ondergeschikten.

"Ja, dat doe ik" zeggen

Mensen willen elkaar niet teleurstellen. Als iemand iets aan je vraag, wil je daarom niets anders zeggen dan "Ja, dat doe ik". Want dat geeft aan, dat je iemand serieus neemt. Dat je zijn of haar wensen belangrijk vindt. Dat je zijn of haar werk belangrijk vindt. Te veel mensen maken dan de fout om (bijna) standaard "Ja, dat doe ik" te zeggen.

Vervolgens komen ze bekend te staan als onbetrouwbaar. Want ze kunnen al die "Ja's" met geen mogelijkheid nakomen. Door tegenwerkend management, door tijdgebrek, door geldgebrek, door tegenstrijdige belangen. En soms gewoon omdat deze persoon zo'n lange "To do lijst" heeft, dat dingen vergeten worden.

Ik kan hier kort over zijn: wees gewoon eerlijk in wat je kan en wat je niet kan. Niemand wil "Nee" of "Niet nu" horen. Maar "Ja" horen en "Nee" krijgen wordt nog veel minder gewaardeerd.

Niet geven van kritiek  

Een andere soms gevaarlijke vorm van het streven naar tevredenheid is het niet geven van kritiek. Dit heeft een wat slechtere naam, dan het vervullen van wensen van anderen of "Ja, dat doe ik" zeggen, maar komt in de praktijk zeer regelmatig voor. Je hoort dan argumenten als: hij/zij werkt zo hard, hij/zij doet zo zijn best, hij/zij heeft het zo druk, hij/zij bedoelt het goed. En vul dit lijstje maar aan met de andere argumenten, die je kent. Een ander sterk argument is: ik wil niemand de schuld geven. Iemand aanspreken op zijn of haar fouten, kan overkomen als iemand de schuld geven van bijvoorbeeld een probleem in het team of een fout in een product. En dat wil je niet. Dat zou niet terecht zijn.

In een team of organisatie staan mensen, die geen kritiek krijgen, vaak bekend als mensen die keer op keer dezelfde fout maken. Die niet leren van hun fouten. Mensen, die anderen hun zaken op laten knappen, omdat anderen door hun fouten meer werk hebben. Of mensen, die steeds opnieuw in hun omgeving mensen tegen hun in het harnas jagen, door wat ze zeggen of doen. En dat elke keer weer opnieuw. Deze mensen, die fouten maken en er niet van leren, worden niet vertrouwd. Omdat iedereen gewoon wacht op het moment, dat ze hun fout opnieuw maken.

En als je er wat van zegt? Dan krijg je te horen, waarom je het maar moet accepteren. Oftewel waarom deze persoon een uitzondering moet krijgen. Oftewel dat je niet alle problemen op deze persoon af moet schuiven.

In dit geval is de oorzaak vaak simpel. Mensen hebben hulp nodig om van hun fouten te leren. Ze hebben iemand nodig, die ze verteld wat ze fout doen. En meestal hebben ze iemand nodig, om te leren hoe het anders kan. De groep mensen, die in staat is zijn of haar eigen fouten en oplossingen te vinden, is heel klein. Het is daarom aan de omgeving om zo'n persoon daarbij te helpen.

Wat betreft het schuld geven: het is bijna nooit zo dat een probleem of fout door 1 persoon is veroorzaakt, zeker niet als het probleem of de fout aan de grote kant is. Van belang is daarom, dat het geven van kritiek bijna nooit naar aanleiding van 1 incident mag zijn. Er moet sprake zijn van een patroon. Je bespreekt het niet, omdat die persoon dit probleem of dit incident heeft veroorzaakt. Je bespreekt het, omdat je bij deze persoon meerdere keren hetzelfde probleem zag. Dat staat volledig los van het incident.

Wat ook helpt, is bij een situatie niet 1 oorzaak bespreken, maar meerdere. Stel dat een tester een ernstige bug heeft gemist, dan is die vaak ook gemist door de ontwikkelaar. In veel gevallen is de bug ook gemist, doordat de voorbereiding van de wijziging niet goed is geweest. Er miste informatie of er is een invalshoek (b.v. een validatiecheck) vergeten. Al deze kritiek bespreken, voorkomt het zondebok gevoel.

Dus hoe kan je wel streven naar tevredenheid?

Als je je werkomgeving tevreden wil stellen, doe dat dan door je kennis en ervaring op peil te houden. Streef ernaar genoeg te weten, om je werk goed te kunnen uitvoeren. Zorg dat mensen vertrouwen in je krijgen, door je werk, niet door je inzet om andermans wensen te vervullen.

Streef naar afspraken, die je na kan komen. Niet afspraken, die je na wil komen. Zorg ervoor dat mensen erop kunnen vertrouwen, dat je "Ja" ook echt "Ja" is.

Help mee aan een omgeving, waarin kritiek bespreekbaar is. Luister naar problemen en ideeën van anderen. En spreek ook zelf openlijk over je problemen en ideeën. Zorg voor een omgeving waarin mensen vertrouwen hebben, omdat ze serieus genomen worde.

De Definition of Testable

De meeste met ervaring in Agile en/of Scrum zullen de termen Definition of Done en Definiton of Ready wel kennen. De eerste geeft aan, wanneer een story gereed is voor productie. De tweede geeft aan, wanneer een story in de sprint kan worden opgenomen. Maar er is zeker nog een andere belangrijke stap: wanneer kan een story van bouw naar test.

Het zou mij niet verbazen als dit een van de oudste vraagstukken is binnen testen: waar stopt het testen van een developer en waar begint de tester? Als de developer te lang doorgaat, wat is dan nog de waarde van een tester? En als de developer te kort test, wordt de tester dan niet misbruikt om als developer slecht werk te kunnen leveren?

Om dit duidelijk te krijgen, is het verstandig om eerst goed te kijken wat het verschil is tussen het testen van een developer en van een tester. Een developer heeft bij het testen als voornaamste doel zijn/haar eigen werk te controleren. Dit houdt in dat de gebouwde story moet voldoen aan de acceptatiecriteria en de binnen het bedrijf of product geldende standaarden. Een tester heeft vaak twee aparte doelen: de second opinion en de testuitbreiding. Bij de second opinion test de tester vaak hetzelfde als de ontwikkelaar, om te controleren of de ontwikkelaar inderdaad het juiste gebouwd heeft. Dit is heel simpel met de reden: iedereen maakt fouten. De uitbreiding van het testen is een ander verhaal. Dit kan per bedrijf verschillen, maar het gaat hier om testen waarvoor binnen het bedrijf geen standaarden zijn. Naast een regressietest, vat hier in ieder geval ook een integratie test in. Een test, waarbij de wijziging niet alleen los wordt getest, maar ook binnen een geheel proces. Of zelfs binnen een keten van applicaties. Maar ook zaken als gebruikersvriendelijkheid, performance, security, enz. kunnen hier invallen. Zaken, die belangrijk zijn, maar niet in concrete, algemeen geldende, criteria zijn vastgelegd.

Als dit het verschil is, waar moet een developer dan op testen? Twee punten blijken al uit het vorige:

• Voldoet een story aan de acceptatiecriteria?
• Voldoet een story aan de geldende standaarden?

Maar developer en tester vormen een team. Wat ik hiermee bedoel? Als je uit gaat van een samenwerking, wil je niet dat een developer iets oplevert, wat door de tester niet of nauwelijks getest kan worden. Iets wat bij de tester op het bordje komt en vervolgens binnen de kortste keren weer teruggestuurd wordt. Omdat de tester al vastloopt, voordat de test ook maar enigszins gevorderd is. Daarom vind ik ook deze twee vragen bij de developer test horen?

• Werkt de wijziging in de applicatie?
• Kan de tester de wijziging testen?

De eerste vraag klinkt misschien alsnog als een ketentest. Laat me daarom het verschil uitleggen. Stel je hebt twee applicaties. In de ene doe je de invoer, in de andere worden rapporten gemaakt. Nu is er een rapport voor een adressenlijst toegevoegd. De invoer is al aanwezig. Maar om het de ontwikkelaar makkelijk te maken, zijn de gegevens voor de adressenlijst gesimuleerd. Dan is het niet de bedoeling dat de ontwikkelaar alsnog alle varianten gaat lopen invoeren, om de adressenlijst te testen. Dat is een integratie test. Wat wel de bedoeling is, is dat de developer zelf adressen invoert via de ene applicatie (twee is al voldoende) en kijkt of deze inderdaad in de adressenlijst komen in de andere. Een korte test, om na te gaan of er geen misverstanden zijn ontstaan tussen de verschillende developers of teams.

De tweede vraag is eigenlijk meer een overdrachtsvraag. Als een developer gebruik heeft gemaakt van technische truukjes om te testen, is de kans groot dat de tester problemen gaat tegenkomen. Nu kan je dat probleem natuurlijk direct naar de tester schuiven. Maar ten eerste is dat vaak maar van korte duur. De tester komt meestal bij je terug met de vragen. Daarnaast heb jij al technische truukjes. En deze kunnen regelmatig de basis vormen om de tester bij testen te helpen. Een teamgenoot vragen een probleem op te lossen, wat jij al hebt opgelost, waarom zou je?

Nee, bovenstaande is niet in beton gegoten. Want wat veel belangrijker is dan een Definition of Testable is een goede samenwerking. Veel beter dan een DoT op basis van een of ander geschreven blog, is een DoT, die is ontstaan, doordat ontwikkelaars en testers met elkaar praten. Elkaars problemen begrijpen.. Proberen het elkaar zo makkelijk mogelijk te maken. Maar tegelijkertijd in de gaten houden, dat het niet de bedoeling is 8 uur extra development tijd te besteden om 1 uur testen te besparen. Net zo min als je 1 uur development tijd wil uitsparen, door de tester 8 uur langer te laten testen. Gebruik de bovenstaande vragen gerust als startpunt. Maar boven alles: praat met elkaar!

Hoe haal je het meeste uit een Senior tester

Ik weet niet of het omgaan met senior testers veel moeilijker dan met andere senior IT'ers. Wat ik wel weet, is dat ik het vaak mis zie gaan. Senior testers, die onderpresteren. Senior testers, waarbij juist over hun testen geklaagd wordt. Hoe komt dit? En daarmee: hoe voorkom je dit?

Eerst even een belangrijk punt voor deze blog. Wat is een senior tester? Voor wat ik hier schrijf, gaat het niet om de prestaties, die iemand levert. Of de geleverde prestaties van een senior niveau zijn. Waar het hier om gaat is kennis en ervaring vergeleken met andere aanwezige testers. Als testers gemiddeld 5 jaren testervaring hebben, maakt 3 jaar ervaring iemand geen senior. Maar in een bedrijf met voornamelijk beginnende testers, kan dezelfde 3 jaar je een senior maken. En het kan ook gaan om een bepaalde specialiteit. Als alle testers 5 jaar ervaring hebben, maar nog nooit aan testautomatisering hebben gedaan, kan een nieuw persoon met 2 jaar ervaring in testautomatisering toch al een senior tester zijn. En een speciaal, maar belangrijk geval is de "bedrijfservaring". Als je ergens nieuw binnen komt, ongeacht je aantal jaren ervaring, is elke tester, die daar werkt automatisch voor jou een senior. Waarom? Zij hebben meer kennis en ervaring van het bedrijf, de mensen, die er werken, de procedures, die gevolgd worden. En deze kennis heb je nodig om zelf succesvol te zijn. Om ervoor te zorgen, dat wat je wil, ook werkelijk bij de organisatie past. Dus ja, in een groep met testers, kan er voor bijna iedereen wel een reden zijn om senior tester te zijn.

Waar komt het onderpresteren vandaan? In mijn ervaring komt dit voornamelijk door twee problemen: blind vertrouwen en de blinde weg. Bij blind vertrouwen gaat het erom dat de andere testers of meerderen openlijk erkennen, dat ze van testen of een bepaald testonderwerp geen verstand hebben. Ze geven daarom de senior tester de vrije hand om met zijn/haar kennis of ervaring de juiste weg te bepalen. Elke beslissing is juist, want hij/zij is de senior. Er zijn echter weinig mensen, die groeien, als ze op geen enkele manier gevraagd worden om te veranderen. Niet uitgedaagd worden, omdat ze zelf hun doelen bepalen. Niet leren van hun fouten, omdat alles wat ze doen automatisch goed is of niet beter kan.

De andere kant is de blinde weg. Soms is hier sprake van wantrouwen in de kennis en kunde van anderen, maar het is meestal meer een vorm van "we moeten nu eenmaal een bepaalde kant op". Binnen het bedrijf is iemand, die de lijn uitzet. Deze persoon komt, ook of juist op het gebied van testen, zeer overtuigend over. Dit is wat er moet gebeuren. Er ligt veel nadruk op de uit te voeren verbeteringen: we moeten testautomatisering toevoegen, we moeten bugs volgens een template vast gaan leggen, enz. Waarom haalt een zo uitdagende omgeving niet het beste van senior testers naar boven? Soms bewust, soms onbewust wordt het idee gecreëerd dat de input van anderen niet belangrijk is. Het plan is al uitgestippeld, de weg is al bepaald, de oplossing al bedacht. Dus de "ik kan ook wat inbrengen" fase is al voorbij, voordat je ook maar over het plan gehoord hebt. Als je niet bent uitgenodigd voor de voorbereidende fase, zal je input dan waarschijnlijk ook niet welkom zijn. Niet dat dit altijd zo is, maar een zeer overtuigende presentatie van "de weg" creëert vaak wel dat gevoel.

Hoe moet het wel? Je moet een senior tester een weg tonen, zonder de input weg te nemen. Door een doel te stellen, geef je een tester geen volledige zelfstandigheid. Door om input te vragen, voorkom je dat een tester zijn of haar kennis voor zich houdt. Dit doe je door minder de nadruk te leggen op de oplossing en meer op het doel. En het doel heeft bijna altijd een van deze drie begrippen in zich: kwaliteit, tijd of geld. Iets moet sneller, beter of goedkoper worden. Hoewel ik graag zou willen, dat elke senior tester vrij is om helemaal zelf de oplossing te bepalen, weet ik dat dat niet altijd gaat. Dus ja: je kan een senior tester de opdracht geven meer automatische testen te maken, mits je vooral uitlegt waarom. Is het om de kwaliteit te verbeteren? Is het om sneller te kunnen testen? Is het om de hoge kosten van een helpdesk terug te brengen?

Van een senior tester mag, nee moet, je daarna verwachten dat deze of met oplossingen komt of de gegeven oplossing verder invult. Mocht voor dat probleem of die oplossing de kennis of ervaring niet aanwezig zijn, dan is het in eerste instantie aan de tester om dit aan te geven. En het allerbelangrijkste: het is aan de tester om te bewaken of het doel behaald wordt. Verbetert de oplossing inderdaad de kwaliteit, vermindert het de kosten en/of de tijd? Maar: het is aan "wegbepaler" om hiernaar te vragen. De "wegbepaler" blijft verantwoordelijk voor het succes van de weg. De senior tester is "slechts" verantwoordelijk voor het bewaken van het doel. Als de oplossing volledig door de tester bepaald is, is het bijsturen van de oplossing volledig de verantwoordelijkheid van de tester. Anders is de tester slechts verantwoordelijk voor het bijsturen van zijn of haar input in de oplossing.

Waarom zo'n ingewikkelde constructie van verantwoordelijkheid? Ik ben realistisch. Bedrijven moeten doelen stellen. Tegelijkertijd moeten senior testers vertrouwen krijgen. Wat je in deze constructie doet, is de tester medeverantwoordelijk maken voor de doelen. Dat maakt, dat een tester uitgedaagd kan worden nieuwe, onbekende paden te betreden. En daarnaast aangesproken kan worden als doelen niet gehaald worden, zonder dat deze dit gemeld is. Tegelijkertijd geef je met deze afkadering de tester vertrouwen om zijn of haar kennis en ervaring toe te passen.

Maar je kan een tester vaak geen volledige vrijheid geven. Door de "wegbepaler" verantwoordelijkheid te laten houden over zijn of haar eigen beslissingen, blijft er controle. Daarnaast kan een goede "wegbepaler" hierdoor informatie te horen krijgen, die tot de keuze kan leiden de weg aan te passen. Zeker informatie van een senior tester kan je helpen in te zien, dat een bepaalde oplossing toch niet de juiste is.

Senior testers daag je dus uit door doelen te stellen en ze medeverantwoordelijk te maken voor deze doelen. Ze mogen hun eigen input geven om de doelen te bepalen. En zijn altijd verantwoordelijk voor het bewaken van de effectiviteit van de bepaalde oplossing. Maar door ervoor te zorgen, dat ze altijd verantwoordelijkheid moeten blijven afleggen, blijf je controle houden, zowel op je senior testers, als op de weg. Met als doel zowel de testers, als de geplande weg bij te kunnen sturen. Zodat een senior tester een senior tester kan zijn. En de wegbepaler de wegbepaler.

Testen wat niet te testen is

Stel: je hebt in je bedrijf een onderdeel van een applicatie, wat niet getest kan worden. Om wat voor reden dan ook. Zou je er dan tegen zijn als iemand zou zeggen: "Ik ga dit testen"? Nee, niemand zou tegen zijn. Toch is mijn ervaring dat een traject om het niet testbare testbaar te krijgen bijna altijd verloopt van obstakel naar obstakel. Hoe komt dat?

Standaarden

In de IT en in het testvak zijn er veel standaarden, die gebruikt worden om product en proces te verbeteren. Agile, Scrum, Devops, TMap, ISTQB en vul zelf maar verder aan. De ene standaard besteed meer aandacht aan testen dan de anderen. Maar geen enkele besteed aandacht aan het uitbreiden van testdekking. En dat is geen commentaar op de standaarden. Een standaard kan niet alle problemen opvatten en oplossen. Maar het heeft wel een groot nadeel. Het maakt het zo ongeveer officieel dat het testbaar maken van het ontestbare geen onderdeel is van een verbetertraject. En dat maakt het moeilijker een ingang te vinden om dit toch te bereiken.

Normalisering

In veel gevallen is het feit dat iets niet getest wordt al jaren aan de gang. En het is daarmee binnen een bedrijf normaal geworden. Het is een onderdeel geworden van het bedrijfsproces en daarmee van het bedrijf. Een al jarenlang geaccepteerd risico. De nadelen is men al aan gewent en zijn daarmee al van hoog tot laag in het bedrijf geaccepteerd. Daarmee vervalt vaak het belang om het probleem op te lossen. Er is niemand die er nog over klaagt. Zelfs managers niet. Niet testen is in dit geval de norm geworden, de meetlat waarlangs wordt gemeten. Waarmee de reden om te veranderen eigenlijk afwezig is.

Ervaring

Een onderdeel is niet zomaar "ontestbaar" verklaart. Vaak zijn er pogingen gedaan, die mislukt zijn. Mensen hebben er ooit veel tijd in gestoken. Of hebben eens in de zoveel tijd een poging gedaan. Zeggen dat het toch kan veranderen, kan daarmee tegenwerking oproepen. In het beste geval heeft een persoon het gevoel, dat zijn of haar kennis of ervaring in twijfel wordt getrokken. In het slechtste geval wordt het gezien als een directe aanval op iemands  jarenlange werk.

Onbekendheid

Als iets niet getest wordt, maar het is wel mogelijk, is de oplossing vaak onbekend gebied. Het kan een samenwerking zijn tussen personen, die nog nooit hebben samengewerkt. Een tool op een hele andere manier inzetten of zelf een heel nieuw tool invoeren. Of een andere manier van omgaan met testdata. En er zijn nog veel meer mogelijkheden. Maar in mijn ervaring is er altijd een "dat kennen we niet" element. Dit heeft twee nadelen: 

1. Niet iedereen is altijd bereid om iets nieuws te leren
2. Iets nieuws leren of toepassen kost tijd, die je oplossing in eerste instantie vaak duurder maken qua tijd en geld

Gevolg

Officieel zal je bijna nooit te horen krijgen dat je geen poging mag doen om dat wat niet te testen is, toch te testen. Maar er zijn twee zaken, die je in mijn ogen goed moet beseffen

1. Het initiatief op dit traject zal bijna altijd van jou afkomen. Zelfs als mensen niet tegenwerken, zullen ze je vaak niet kunnen geloven (als het kon, was het toch al eerder gelukt?). Of hebben ze gewoon andere prioriteiten (zaken die wel met zekerheid haalbaar zijn).
2. Pas ontzettend op dat je mensen niet tegen je in het harnas jaagt. Je zal je omgeving zeker niet altijd blij maken, omdat je tegen de norm in gaat. Maar probeer te voorkomen dat mensen werkelijk het gevoel hebben dat je hun kennis en ervaring in twijfel trekt.

Waarom toch doen?

Ik heb een hele eenvoudige mening: alles kan getest worden. De vraag is niet: kan je het testen, maar: wegen de testkosten op tegen de baten. Als men werkelijk geloofd dat iets niet getest kan worden, heeft men iets over het hoofd gezien.

Daarnaast, en waarschijnlijk belangrijker voor het overtuigen: hoewel vaak geaccepteerd, zijn de gevolgen vaak wel degelijk ernstig. Ontevreden klanten, terugdraaien van opleveringen in productie, teams die steeds opnieuw onderbroken worden door blocking bugs, slechte relatie tussen development en een of meer afdelingen. Regelmatig ontstaat er zelfs een neerwaartse spiraal: het oplossen van een bug in het niet testbare ondereel veroorzaakt al vrij snel 1 of meer nieuwe.

Als een probleem een van deze gevolgen heeft (en vaak is dat wel degelijk bekend), is het vaak de investering waard om op te lossen. Het is geen makkelijk traject, geen snel traject. En je moet maar net de juiste persoon zijn of vinden om dit onderdeel testbaar te maken. Maar als het lukt, zijn de voordelen ook vrij snel zichtbaar. Juist omdat de negatieve gevolgen dat ook waren. Als men al jarenlang iets slechts gewent is, valt het echt wel op als dat opeens verdwijnt. En dat kan een volgend traject "Testen wat niet te testen is" een stuk eenvoudiger maken.

Simuleren tijdens testen: het kan teweinig en het kan teveel zijn

Simulaties, emulaties, stubs en drivers. Binnen de testwereld krijgen ze een steeds grotere rol. Ze vormen een groep krachtige tools binnen het testen, met een zeer waardevolle toevoeging. En tegelijkertijd vormen ze een heel, heel groot gevaar.

Voor deze blog gebruik ik het woord 'simuleren' of 'simulatie' voor alles waarbij je een applicatie, proces, apparaat, interface, e.d., zoals gebruikt in productie, vervangt door een hulpmiddel. Dit kan een stuk code zijn, maar ook een softwareprogramma, dat als simulatie is ingericht.

Ik hecht een groot belang aan goede simulaties. Simulaties kunnen op verschillende manieren het testen verbeteren. Je kan het mogelijk maken om het onmogelijke te testen. Meestal situaties, die in de praktijk vrijwel onhaalbaar zijn. Zo kan je in het netwerk zaken simuleren, die in het echt moeilijk te vinden zijn. Trage netwerken, haperende netwerken, onderdelen, die uitvallen. Maar denk ook bijvoorbeeld aan GPS testen. Om goed te testen, is een gps coördinaat met een '-' waardevol. Ik denk niet dat veel werkgevers een reis naar het westen of zuiden, om dit te testen, zullen goedkeuren.

Daarnaast is het een krachtig tool om afhankelijkheid van externe leveranciers of beperkte databases op te lossen. Als je zelf kan bepalen welke gegevens je binnenkrijgt, kan je eenvoudig veel meer varianten testen. En testen op meerdere varianten in gegevens geeft vaak een betrouwbaardere test.

Als laatste kan het tijdwinst opleveren. Ik heb zelf testen geschreven, waarbij je langer met de voorbereiding bezig was, dan met de test. Vaak zijn dit tijdgebonden testen, waarbij de gegevens binnen een bepaalde periode moeten vallen. Denk aan een route, die door een monteur gereden moet worden. Hiervoor moeten misschien wel 20 afspraken ingevoerd zijn, om dit goed te kunnen testen. Als je deze invoer snel kan simuleren, in plaats van werkelijk invoeren, heeft dat grote voordelen.

Dus waarom zou je het laten? Nou, volledig laten hoeft wat mij betreft nooit. Dit kan er zelfs toe leiden, vooral als het gaat om testen van situaties of varianten, dat je test niet genoeg dekking heeft om betrouwbaar te zijn.  Het kan echter ook teveel zijn. Als je volledig gaat vertrouwen op simulaties, test je de werkelijkheid niet meer. Want hoe goed een simulatie ook is, er is altijd een kans dat de simulatie verschilt van de werkelijkheid.

Simulaties moet je gebruiken om je test aan te vullen of om een deel van je test te vervangen. Maar als je iets in de werkelijkheid kan testen, doe dat altijd minimaal 1 keer. Ik zie geen enkel bezwaar om, als je 10 testen hebt voor een interface, er 9 te simuleren en 1 echt uit te voeren. Ook kan je ervoor kiezen om een speciale "niet-simulatie" test uit te voeren. Denk hierbij bijvoorbeeld aan een ketentest, waarbij over het algemeen simulatie bewust niet wordt gebruikt.

Aan de andere kant: als je situaties alleen via simulatie kan testen, ontwijk de simulatie niet. Kan je iets niet in de werkelijkheid testen, heb de moed om te kijken of het via simulatie wel kan. Er kan vaak veel meer dan je denkt. Zeker als je zelf kan programmeren of de mogelijkheid hebt een ontwikkellaar in te zetten. Zoek eens op het internet, als je denkt dat iets onmogelijk is. Regelmatig zal je verrast worden, omdat er vaak andere mensen zijn met hetzelfde probleem. En de oplossing daarom allang aangeboden wordt.

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!