S02·006Paul de Witt en Bas Dijkstra over Testautomatisering
Paul de Witt en Bas Dijkstra vertellen hun ervaringen en advies rondom Testautomatisering
Paul de Witt en Bas Dijkstra vertellen hun ervaringen en advies rondom Testautomatisering
- ▸Wat testautomatisering inhoudt en waarom kwaliteit cruciaal is
- ▸Hoe je testdesign niet mag onderschatten bij automatisering
- ▸Waarom developers en testers samen moeten werken aan testen
- ▸Hoe je shift-left strategieën toepast met unit- en integratietests
- ▸Wat object-georiënteerd denken betekent voor test automation
We hebben het deze aflevering over Testautomatisering. Onze gasten, Paul de Witt en Bas Dijkstra, zijn beiden werkzaam als Testautomation Engineers. Paul is een IT entrepreneur at heart, testautomation specialist, trainer, DJ, en vader van 3 kinderen. Bas Dijkstra kennen de meeste test automation developers van zijn testautomatisering trainingen op github en youtube. Hij is 14 jaar actief in de testautomatisering.
Transcript
Ja, en volgens mij is het uiteindelijk ook gewoon vooral iets dat moet gebeuren.
En, ja, wie moet dat dan doen?
Dat maakt me niet zoveel uit als het maar gebeurt.
Al is het de schoonmaker die de performance test uitvoert.
Heel plat gezegd.
Dat gaat niet gebeuren, maar...
Welkom allemaal weer bij een aflevering van CodeKlets.
Dit keer zitten we alweer in aflevering 6 van seizoen 2.
En vandaag heb ik weer twee hele leuke gasten bij ons op verzieten.
En die houden zich vooral bezig met testautomation.
Onze eerste gast is een goede kennis van mij die ik heb leren kennen tijdens een project bij team Meulenhof.
Paul de Witte, welkom.
Hoi, goeiedag.
Hoi.
Ik zal je proberen te introduceren, maar vul me vooral aan, hoor.
Hoe ik jou ken.
Je bent echt een IT-entrepreneur.
Dus ja, je houdt daar recht van.
Valt mij op.
Eén bedrijf naar het andere bedrijf ben je aan het oprichten volgens mij.
Dus echt een entrepreneur by heart.
Ik ken jou ook als echte testautomation specialist.
Ja, je geeft ook vaak trainingen.
En ja, je bent ook een dj, hè?
Ja, nog steeds inderdaad, ja.
Super, super.
We moeten nog steeds even een keertje wat inplannen trouwens.
Maar goed.
Ja, we moeten doen.
En ja, je bent de father of three.
Je hebt alweer drie kids.
Klopt ook.
We houden het erbij.
Oké, oké.
Huis vol, auto vol.
Dan is het klaar, hè?
Ja, precies.
Ik zal verder ook niks over.
En ja, je bent een echte creator at heart.
Dus welkom Paul.
Leuk dat je er bent.
Ja, dankjewel.
Ja, onze tweede gast is ook een specialist op gebied van testautomation.
Ja, de meeste testautomation developers kennen hem van YouTube.
En ja, nog net geen radio geloof ik.
Of wel?
Ben je wel een keer op de radio geweest?
Bas Drijkstra?
Nee.
Nee, niet dat ik weet in ieder geval.
Nou goed, Bas Drijksstra.
Die kennen we natuurlijk van de verschillende trainingen die hij geeft.
En natuurlijk de mooie blogs en alle conferenties waar hij regelmatig spreekt.
Welkom, Bas.
Ja, dankjewel.
Leuk dat ik aan mag schuiven.
Ja, zeker.
Ik bedoel, deze episode gaat over testautomation.
Aan wie moet je dan denken?
En als je gaat googlen natuurlijk, dan zien we jouw naam in het Nederlands.
Dus wat dachten we je nodig uit?
Nou, tof.
Leuk.
Ja, zeker.
Nou, was ik goed.
Nou, om even gelijk te beginnen.
Ja, het is heel normaal binnen CodeKlets dat we iedereen even kort bevragen over hoe ze begonnen
zijn met hun carrière of misschien wel daar eerder.
Zal ik eerst even met Paul beginnen?
Hoe is het allemaal begonnen bij jou?
Is testautomation echt heel snel begonnen of had je iets anders?
Ja, ik ben eigenlijk na informatica-studie een beetje automatisch in het testvak gerold.
Ik ging werken bij een dediceringsbureau als functioneel tester.
En ja, eigenlijk van daaruit, zeg maar, op een gegeven moment die transitie gemaakt
richting automatisering en dat had eigenlijk mee te maken.
Ik had toen een klein dediceringsbureau en een aantal van mijn mensen die werkte inderdaad
die begonnen er net mee in de tijd dat selenium net opkwam en secoolie echt nog
een ding was voor orkoformzachtige applicaties.
En ik vond het ook heel erg leuk en ik ben me toen in gaan verdiepen.
En eigenlijk vanaf dat moment ben ik me eigenlijk volledig er ook op gaan richten
op een gegeven moment.
Dus dat is denk ik nu een jaar of 6, 7 zo ongeveer.
Ah, nice. Ja.
En heb je daarvoor ook nog wel, voor je schooltijd of misschien wel tijdens je schooltijd
nog een beetje aan het code geweest?
Ja, ik had tijdens mijn studie Java als programmeertal, daar is daar veel mee gedaan.
En toen ik op een gegeven moment begon zat ik op een opdracht waar Java de voertal ook was.
Toen heb ik ook mijn Austria gehaald inderdaad.
En dat was eigenlijk een beetje mijn startpunt.
Ah ja, dus jij weet echt alles van objectoriteerd programmeren dan?
Ja, alles is een groot woord, maar we komen ver.
Ja, precies. Oké, mooi.
Bas Dijkstra, hoe is het bij jou allemaal begonnen?
Ik denk toen ik een jaar of 12, 13 was of zo, nog niet zozeer met testautomatisering hoor.
Ik had geen idee wat het was toen, maar toen riep ik al van, ik wil later programmeur worden.
Nou, dat is mooi mislukt.
Ja, dat is behoorlijk mislukt.
Ja, maar dat was nog in de tijd dat je naar de bibliotheek ging.
Ik weet niet of ik jullie moet uitleggen wat dat is.
Ik denk dat je daar boeken ging halen.
En dus het waren gewoon boeken, gewoon letterlijk papieren boeken,
vol met listings die je dan ging overtypen om te kijken wat het doet.
En dan krijg je uiteindelijk een vierkantje stuiterend over je scherm.
Dat je iets in BASIC, GW BASIC, gemaakt.
Dat vond ik supercool.
En ik ben daarna ook, ik riep op mijn twaalfde te zelf, die richting wil ik op.
Ik heb ook informatica gestudeerd.
Wel grappig dat jij zegt dat je dat ook hebt gedaan, Paul.
Want ik heb ook nog steeds een beetje het idee dat wij in Testland een beetje een uitzondering zijn.
Ja, ik snap wat je bedoelt inderdaad.
Na mijn studie ben ik eerst anderhalf jaar iets doen wat niet zoveel met testen te maken had,
behalve het testen van mijn geduld.
Daarna ben ik bij Societeam begonnen als jong professional.
En ik weet nog dat ik had een klasje van 25 man.
En ik was één van de twee met een informatica achtergrond.
En als CK je spreekt ook wel eens wat mensen van over de grens.
We zijn hier in Nederland best wel uitzonderlijk gewoon in het testvak.
Dat heel veel testers, heel veel goede testers ook, eigenlijk helemaal geen informatica achtergrond hebben.
Ja, dat klopt.
En ook eigenlijk heel vergelijkbaar met jou, Paul.
Heel snel heb ik begonnen als functioneel tester.
Dat heeft bij mij een maand of zes geduurd.
En toen richting testautomatisering gaan.
Maar dat leek toch wel het meeste op datgene wat ik tijdens mijn studio ook had gedaan.
Eerst drie jaar bij Societeam gewerkt, vijf jaar bij een kleine detacheerder.
En daarna voor mezelf begonnen.
En dat doe ik nu een jaar of zeven.
Dus opgeteld zit nu een jaar of 15 in dit vak.
En ja, het blijft nog steeds leuk.
Ja, zeker.
En welke programmeertaal is bij jou zeg maar als eerste waar je ervaring mee hebt opgedaan?
GW Basic, zoals ik zei.
Oh sorry, ja.
Ja, maar daarna in mijn studie was het ook vooral Java.
Ook in 1998 al.
En ja, een beetje C, een beetje assembler.
Oh, assembler ook nog.
Ja, dat leer je.
Ja, dat leer je.
Ja, daarna nooit meer iets mee gedaan.
Maar ja, dat vooral.
En ja, er zijn later een heleboel andere talen bij gekomen.
Ja, dus eigenlijk een beetje van alles een hele grote mix bij jou.
Ja, ja, en het grapje is, als je er een paar hebt gezien en daar wat mee hebt gedaan,
maakt het ook eigenlijk allemaal niet zo heel erg veel meer uit, is mijn ervaring.
Dat klopt inderdaad, dat is precies wat je zegt.
Alles lijkt een beetje op elkaar dat betreft.
En waar blijkt dat uit?
Omdat je dan bedoel je daarmee dat je hetzelfde kan bereiken?
Nou, ik ben niet heel erg goed in een bepaalde taal of zo,
maar ik heb wel, denk ik, een redelijk begrip van object-georienteerd programmeren.
En daarmee is het vrij makkelijk om een nieuwe taal of een nieuwe library of zo op te pikken.
Ik zeg altijd weleens van, ik weet niet precies hoe die daad, maar ik weet heel goed waar ik naar moet googelen.
Ja, precies, het gedachtegoed is een beetje hetzelfde.
En als je bijvoorbeeld naar Java kijkt en zie, is dat bijna ook hetzelfde qua syntax en zo.
Dus dat ligt heel dicht bij elkaar.
Ja, en dan moet ik zeggen dat je tegenwoordig in Tesla natuurlijk heel veel tegen Python aanloopt of tegen Javascript.
En ja, dat zijn natuurlijk veel makkelijkeren talen om te leren.
Maar ook al object-georienteerde gedachten, goede achterkomen, zitten steeds meer.
Ik moet wel zeggen dat ik met Javascript zelf altijd enorme ruzie heb.
Maar dat is meer mijn gebrek dan het gebrek van die taal, denk ik.
En waar blijkt, kan je daar een voorbeeld van geven?
Die zit op een of andere manier.
Maar dit is waarschijnlijk ook gewoon omdat ik er nog niet zo heel veel mee heb gedaan.
Ik zeg, ik heb veel met Java gedaan.
Daar zijn later C-Sharp en Python vooral bij gekomen.
Javascript, nog niet zo heel veel eigenlijk.
Dus dat hele ecosysteem en die constructies die typisch zijn van Javascript,
die hebben ik gewoon iets minder ervaren in mij.
Dus het duurt vaak iets langer voordat ik het juiste antwoord heb gegoogeld.
Dat is het vaak, ja.
Echt, ik zou ook niet weten wat ik zonder Google moet, hoor.
Zonder stackoverflow, volgens mij eigenlijk.
Of dat stackoverflow.
Ja, ja, ja, zeker.
Nou ja, goed.
Leuk dat jullie dat even met ons wilden delen.
Want dan kunnen we gelijk een beetje het niveau inschatten.
Nee, dat is een beetje overtrekbaar.
Ja, ik hoor, het onderwerp test automation is niet zomaar geland hier binnen CodeKlets.
Er zijn wat discussies vooraf geweest over wat betekent test automation nou
en wat voor toegevoegde waarde heeft het.
En ik heb eigenlijk een vraag aan jullie beiden.
En misschien hebben jullie je eigen beeld erbij.
Maar ik hoor toch ook weleens, ja, ook van developers dat test automation
is een beetje een wasse neus aan het worden.
Het geeft een bepaalde, ja, hoe heet dat?
Sense of security.
Die niet altijd, ja, goed hoeft te zijn.
Want heel vaak zeggen developers ook van, ja, het is leuk dat die testen allemaal slagen.
Maar ik geloof er niks van.
Wat is jullie beeld daarbij?
Ja, ik denk dat dat eigenlijk ook heel erg te maken heeft met de kwaliteit van de testen.
Van waar je op focust, wat je moet testen, wat je wil raken.
En het is natuurlijk heel makkelijk om iets te zeggen.
Kijk, je hebt natuurlijk wel verschillende manieren,
verschillend type organisatie test automatisering op verschillende manieren benaderen.
Maar ja, je hebt ook verschillende type test automatiseerders.
De mensen die kunnen coderen en de mensen die het niet kunnen.
Dat zijn allerlei verschillende competenties die bijdragen aan de kwaliteit van de manier waarop je gaat testen.
En erbij is gesproken over welke aanpak je gaat gebruiken, welke technieken je toepast.
Dus ja, die uitdrukking is zelf niet zo heel sterk, vind ik eigenlijk.
Ja, het is een beetje wat je er zelf van maakt ook, denk ik.
Het is mijn ervaring wel, en dat is ook de ervaring uit mijn eigen verleden.
Dat gebruik ik graag als anekdotes ook tegenwoordig.
Het is ontzettend makkelijk om hele slechte testen te schrijven.
Ik zie de laatste tijd, en misschien komt daar dat beeld ook wel een beetje vandaan, van developers.
Ik ben trouwens benieuwd welke developers dat dan zijn.
En wat ze dan zelf beter doen.
Weet je, na de aflevering deel ik de namen en dan gaan we ze opzoeken, oké?
Nee, het gaat niet eens om namen, maar we weten ze te vinden.
Bij heel veel testautomatisering, en dat is ook een beetje het stigma wat om testautomatisering heen hangt af en toe, is het van meer is beter.
Alles moet geautomatiseerd worden.
En wat je ook vaak nog wel ziet is van we hebben al een hele stapel regressiescripts en die gaan we gewoon automatiseren.
En dan als dat klaar is, dan is het goed en dan is het tof en dan is alles, dan klopt het allemaal.
En dat werkt vaak gewoon helemaal niet.
En ja, terwijl je denkt, en dan zie je misschien inderdaad een mooi scriptje wat allerlei groene vinkjes geeft of echt geen idee of ja, wat vertelt dit mij nou eigenlijk?
Dus voor een deel ben ik het er wel mee eens, maar ja, het is wel wat je er zelf van maakt.
Het kan als je het goed doet en ja, wat is dan goed?
Daar kun je er heel lang over praten, maar dan kan het wel degelijk natuurlijk toegevoegd waarde hebben.
Anders zaten wij hier nu niet met z'n drieën denk ik ook hierover te praten.
Ik denk ook dat er een andere kant zit, want precies wat jij zegt Bas, dat is absoluut waar.
Maar het toevallig voor de testautomatisering is dat hij het heel leuk vindt om te automatiseren.
Ik ben er zelf ook schuldig aan. Dus ja, als de testen dan draaien en ze gaan op groen iedere dag
en je hebt gegevens flikky testen die je moet repareren. Ja, dat is niet het leukste werk natuurlijk.
En dan op een gegeven moment wordt het de sport, heb ik ook al vaak gezien,
dat de sport is gewoon eigenlijk om het vlagje weer op groen te krijgen
in plaats van echt naar de kwaliteit te kijken om die test te onderhouden.
Ja, en dan ontstaat die, ja hoe noem je dat, dit soort gezegdens.
Het geeft een false sense of security.
En dan ziet men ook de return on investment op een gegeven moment niet meer.
Nee. Maar dat is ook heel belangrijk, die return on investment.
Dat is natuurlijk iets waar men eigenlijk nooit voldoende bij stilstaat denk ik.
Vaak zie je dat testautomatisering wordt ingevlogen omdat men vindt we moeten dat doen
want het hoort bij de agile werkwijze of we gaan DevOps, dat is natuurlijk nu de trend.
En ja, wat je daar ook ziet is dan gaan we het maar doen.
En dan weet je, dan is het ook vaak van als er wat is, is het goed, weet je wel.
En als het visueel is, is het helemaal fantastisch, want de meeste mensen weten niet hoe het werkt.
Dus ja, weet je, dat sense of urgency is er misschien wel,
maar tegelijkertijd is er nog niet altijd het besef van wat men er echt specifiek mee wil bereiken.
Want het is een heel breed begrip, want je kan testen op features,
maar je kan ook testen op techniek, je kan testen op security.
Maar het kan allemaal geautomatiseerd, dus wat wil je werkelijk hebben op dat moment?
Ja, dat is een beetje een soort van checkbox die je moet hebben in je DevOps transitie, zeg maar.
Eigenlijk wel.
Ik vind zelf die ROV wel een hele moeilijke hoor.
En dat is een beetje omdat het is zo ontzettend moeilijk te meten.
En wat voor metrieken ga je daarbij gebruiken?
En waarom ik het zelf ook een lastige vind?
Ja, het is een middel om iets anders te bereiken.
Ja, zeker.
Om uiteindelijk wil ik, gaat het mij allemaal, gaat het hele testvak over, gaat het om informatie verzamelen.
En testautomatisering helpt je op bepaalde gebieden, op bepaalde manieren,
om die informatie op een efficiëntere manier op te halen.
Maar om daar dan een ROV aan te knopen, behalve de dingen die het mogelijk maakt,
vaker releasen, korte feedback loops, dat soort dingen.
Ik zie nog te vaak van die berekeningen van nou, we spenderen zoveel uur aan dit script automatiseren,
en als we dan al 16 keer gedraaid hebben, dan hebben we het terug verdiend.
Dat is mooi.
Ja, ik heb dat soort sheets vroeger ook weleens in moeten vullen.
Ik denk ook zelf dat, ik heb er een keer een onderzoekje naar gedaan,
dat je die return on investment kan je eigenlijk alleen maar bereiken
als je in een bestaande organisatie al een bewezen testproces hebt,
wat je wilt optimaliseren.
Anders is het altijd van een investering voor een nieuw product,
of een nieuwe feature, of een nieuwe service die gebouwd wordt.
En dat kan je eigenlijk niet in geld uitdrukken, want je weet niet wat je gaat besparen.
Nee, het is een middel om andere dingen voor elkaar te krijgen,
en die andere dingen zijn de dingen die ware opleveren.
Precies, ja.
Ik bedoel, er is nog niemand ooit naar mij toegekomen,
mag ik van u vijf kilo testautomatisering alsjeblieft.
Oh, hé, in kilo's, dat is echt.
Ik heb wel eens gummybeers gebruikt, maar kilo's die vind ik wel echt.
Die vind ik heel sterk.
Ja, het blijft natuurlijk lastig.
Return on investment is natuurlijk een beetje de management taal
die natuurlijk gebruikt wordt om testautomatisering te verkopen.
Alleen, ja, weet je, het blijft gewoon een lastig begrip voor degenen die het leest.
Kijk, zo'n manager die er echt totaal geen verstand van heeft,
die denkt, wow, dat is gaaf, daar kan ik heel veel geld mee besparen.
Terwijl wij misschien de kenners die echt in het vak zitten denken van,
nou, dat is die kosten, die zijn inderdaad misschien het begin een beetje hoog,
of laag, maar heb je weleens nagedacht over wat voor legacy je dan achterlaat.
En vooral als je het ook verkeerd hebt in hebt gezet.
Dus daar bedoel ik mee, wat je vaak ziet is dat men test automation engineers,
zeg maar, naast het team zetten die de boel automatiseren.
En ja, dat leeft natuurlijk een heel ander beeld op.
Ja, dat klopt.
En ik moet zeggen, ik doe vaak trajecten waarbij ik gevraagd word, zeg maar,
om inderdaad het test automation process op te zetten en in te richten.
Dus zowel op process en technisch niveau.
En eigenlijk is dit gewoon echt een verkoopverhaal.
Dus eigenlijk het enige wat je echt duidelijk kan maken,
is de toegevoegde waarde van de testen, van de toetsen, van die kwaliteit.
Welke risico's zijn we nou eigenlijk aan het mitigeren?
Dan kan je praten over financiële schade, over data die je op straat komt te leggen,
over dat soort zaken.
Als je over dat soort dingen praat, is mijn ervaring dat dat leeft binnen bedrijven,
want daar zijn ze gevoelig voor.
En als je daar naartoe kan werken, zeg maar, in je verhaal,
dan over het algemeen kan ik meestal wel overtuigen daarover.
Ja, en soms ook wel, dan moet je ook wel eens het team overtuigen,
want dat is ook soms wat er vaak speelt.
Altijd, ja.
Ja, ook op technisch niveau, maar ook in hoeverre je je proces kan doen aansluiten,
op hun software development lifecycle.
Dat zijn allemaal zaken die je dan inderdaad even moet bewijzen.
En sowieso is geen enkele organisatie hetzelfde,
dus je moet sowieso eerst een soort pot doen natuurlijk,
om te kijken wat werkt en wat niet.
En Bas, wat is jouw ervaring tot nu toe,
om te starten ergens bij een organisatie,
maar ook om je team mee te krijgen hierin?
Ik merk wel, en daar ben ik heel blij mee,
dat de afgelopen, nou zeg een jaar of vijf,
dat het minder vaak in ieder geval de toegevoegde waarde van testen,
van testten, en dat is wat anders dan de toegevoegde waarde van testteurs,
hoeven te verkopen.
Ik vind het wat dat betreft makkelijker dan een aantal jaar geleden,
omdat mensen inmiddels ook wel doorhebben vaak,
en misschien heb ik gewoon geluk gehad bij de organisaties waar ik mee heb gewerkt de afgelopen jaren,
dat zou heel goed kunnen,
maar ik merk over het algemeen wel dat testen volwassener is geworden,
en dat we daar best wel stappen in hebben gemaakt,
en dat dat ook wel makkelijk, het is alleen,
ja het is toch vaak wel nog steeds het eerste wat in de knel komt op het moment dat de tijdsdruk een beetje hoger wordt.
Vandaag ook weer een mooi voorbeeld gehad in een gesprek met een team die zei van ja we willen heel graag,
en ook we willen heel graag meer en beter met test automatisering doen,
maar ja de business loopt van buiten alleen maar op fietsjes te drukken,
daar hebben we nog vaak wel mee dat mensen zeggen we willen het wel,
en ja we vinden het belangrijk dat testen,
en ja we zien ook dat die test automatisering, dat we dat wel nodig hebben voor een stukje continuiteit,
voor een stukje vangnet en voor het versnellen, het verkorten van die feedback loop,
maar zodra je zich het dan gaat vertellen dat je er ook echt in moet investeren,
en niet alleen eventjes, en wat je zegt dat voorbeeld van die externe test automatisering,
dus die volledig buiten het team een set bestaande test gaan automatiseren,
ik kom er af en toe nog tegen, daar word ik altijd wel een beetje verdrietig van,
het is gewoon een investering die je moet doen,
en niet iets waar je op korte termijn grote zakken met geld mee gaat besparen,
het is een lange termijn investering,
dat blijft soms lastig te verkopen,
en niet zozeer het nut van testen en testen automatiseren,
maar het feit dat dat gewoon een lange termijn investering is,
dat wil nog wel eens knellen,
want uiteindelijk vindt iedereen kwaliteit belangrijk,
maar niemand vindt testen belangrijk, lijkt wel.
Ja, dat is een interessante observatie.
Ja, het scheelt ook heel erg per bedrijf, heb ik gemerkt,
want je hebt bedrijven met een aantal softwarebedrijven gewerkt
die echt producten ontwikkelen,
die zijn natuurlijk gewoon echt techniek, dat omarmen ze natuurlijk gewoon,
zit je bij een ING, die noemt zichzelf een IT-organisatie,
dus dan werken ze ook echt DevOps Spotify was de eerste,
ik weet niet of ze dat nog steeds doen op dit moment,
maar zit je bij andere organisaties die misschien wat klassieker zijn,
die willen gewoon mee met de trend, om het even zo te zeggen,
meedoen met de ontwikkeling,
dus we gaan agile, we moeten richting DevOps,
in die term is DevOps ook nooit echt DevOps,
maar is het gewoon een soort technisch stoeltje,
en wat je daar vaak ziet is dat men al dat soort processen gaat inrichten,
maar niet binnen één team bijvoorbeeld,
dat is dat binnen verschillende afdelingen,
onderdelen beleggen van de pipeline zogezegd,
en daar zie je dan ook vaak dat daar ook testen automatiseerd zitten,
die de oplossingen en beslissingen nemen,
die eigenlijk volledig losstaan,
van wat de ontwikkeldeams aan het doen zijn bijvoorbeeld.
Ja kijk, dat zijn allemaal lastige situaties,
en je hebt nu best wel veel te maken met veel bedrijven die in transitie zitten,
richting dat soort veranderingen,
heel veel zijn al richting agile,
nu komt DevOps om de hoek,
dus men gaat die kant echt ontwikkelen,
wat denk ik een hele goede ontwikkeling is,
maar dit blijft altijd een beetje,
inderdaad wat Bas ook zegt,
het komt er altijd een beetje bij, zeg maar.
Ja, een beetje een sausje overheen,
terwijl je toch eigenlijk het wil zien als een soort van een craft in software development,
dus net als hoe je software met bepaalde coding practices,
of met bepaalde coding patronen opbouwt,
zo zou je ook wel willen dat developers,
of in ieder geval iedereen in het team die gedachte draagt.
Ja, dat klopt ook,
en je zei net al in het begin een beetje met mijn introductie,
met mijn bedrijfjes en zo,
ik werk nu elf jaar voor mezelf,
ik heb verschillende dingen geprobeerd,
sommige dingen zijn gelukt, sommige niet,
en overal heb ik wat van geleerd,
maar dat maakt je weleens tot een soort van ondernemersgeest,
en wat ik heel mooi vind aan DevOps is dat men natuurlijk allemaal zelf
eigenlijk een eigen winkeltje heeft met een eigen team, zeg maar,
volledig verantwoordelijk.
En wat ik vaak mis momenteel in teams is juist die ondernemersgeest,
die verantwoordelijkheid, die productiviteit,
om er zelf bovenop te zitten.
Kijk, en dat is natuurlijk een andere discussie dan testautomatisering,
maar ik denk wel dat daar een oorzaak ligt,
eigenlijk, van waarom het niet altijd even goed op de kaart staat,
zeg maar, of wat de impact daarvan is.
Is dat niet ook deels doordat,
dat misschien een aantal jaar terug nog wat traditionele bedrijven
waren die heel erg gewend,
waarbij men heel erg gewend was om van boven afgestuurd te worden,
en nu moet je het beëneend zelfsturend helpen?
Ja, dat klopt, dat klopt.
Dat is natuurlijk een totaal andere manier van werken,
culturele verandering natuurlijk, en dat is enorm.
Ja, inderdaad.
De reden waarom ik dit onderwerp ook een beetje aanstipte was,
continuous delivery of DevOps, geef het een naampje.
Dat zijn allemaal maniertjes om business en IT zo snel mogelijk dichter bij elkaar te krijgen
en de klant natuurlijk zo snel mogelijk te voorzien van zijn behoefte.
En de vraag die ik ook wel eens krijg is van ja, goh, leuk dat je in dat testautomation zit,
maar moeten developers dat nu gewoon niet gaan doen?
Wat vinden jullie daarvan?
Ik zou graag zien dat het meer bij developers komt te liggen dan nu.
Dat nu vaak nog het geval is.
En ik weet het, developers moeten ook developpen.
Dat is namelijk waar ze voor betaald worden.
En dat is uiteindelijk wat ook, en dat is waar klanten uiteindelijk voor betalen.
Dat snap ik ook heel goed.
Maar wat we al een aantal jaren heel erg zien in de test weer ook,
is dat testers richting testautomatisering trekken of geduwd worden.
Dat zie je allebei.
En sommigen willen dat heel graag.
Nou, natuurlijk hartstikke tof.
En er zijn er ook die zeggen van oh shit, de hele wereld gaat die kant op.
Ik moet mee.
En wat ze dan nog wel eens vergeten is,
dat het, ja, je bent nog steeds met testen bezig,
maar je bent daarnaast ook met software development bezig.
En dat is toch best wel een stap voor een heleboel mensen.
En ook niet iets wat je even in een paar dagen oppikt.
Of even met een tutorial in het hoe goed die tutorial ook is en hoe goed die tool ook is.
Alleen een tool beheersen.
Of stekken op flow, inderdaad.
Maar dat is niet genoeg.
En developers hebben die skill wel.
En mijn ervaring inmiddels is dat het makkelijker is om developers die testing mindset bij te brengen dan testers die development skills.
Ja, dan ben ik het wel maar eens hoor.
Want het is niet voor iedereen weggelegd om het te kunnen programmeren.
Niet iedereen is een wiskundeknobbel, niet iedereen is een taleknobbel bij het spreken.
Dat geldt voor programmeren net zo.
En dat is een hele grote stap.
En het testproces in Nederland is in ieder geval altijd een iets heel functioneels geweest.
Ik weet ook bij mijn eerste opdracht ooit.
Ja, dat was mijn meest technische tool.
Het meeste tool die ik had was Excel.
En tot de vele frustraties heb ik daarover gehad.
Maar dat zag je toen heel erg.
En nu zie je dat die trend ontstaan.
Maar wat mij heel erg opvalt is dat je eigenlijk binnen Nederland twee soorten testautomatiseerders aan het krijgen bent.
Als je dan puur praat over die rol los van alle performance testers en zo.
En dat zijn de mensen die dus inderdaad testen zonder enige developmentkennis.
Dus vaak met de tools waar ze workflows kunnen maken of andere manieren.
En de mensen die echt inderdaad ook zelf code kunnen schrijven.
En volgens mij hebben ze op internationaal niveau dat ze die laatste rol tegenwoordig ook anders noemen.
Die noemen ze tegenwoordig software development engineer in test geloof ik.
Maar ja, mijn ervaring is wel.
Kijk, testautomatisering wordt ook vaak gezien als duur.
En het is het ook.
Want het kost vaak, zeker met frameworks als ze dan een beetje veel onderhoud.
Dan moet het allemaal bijgehouden worden.
Testen moeten herschreven worden, moeten aangepast worden.
Dan breekt er weer wat, want je browser is geüpdatet of weet ik veel.
Er zit heel veel tijd en geld in.
En als jij een solution hebt, is mijn ervaring die aansluit op de stack waarop gewerkt wordt.
Dus je test echt werkelijk op de code die ook geschreven wordt, op frameworks die gebruikt worden door de developers.
Dat je ook veel sneller en minder onderhoudbare testen kan schrijven.
Maar dat vergt dus wel voor jou dat je niet alleen kan programmeren,
maar je ook nog eens kan verdiepen in de technologie die gebruikt wordt daar.
Ja, ik vind dat er ook nog wel een verschilletje zit tussen code kunnen schrijven en kunnen programmeren.
Want wat je in tutorials en in basic trainingen vaak leert is een beetje code schrijven.
Het leerde syntax.
Mijn leerde programmaat gaat ook over object georienteerd denken.
In abstracties kunnen denken, in modulariteit kunnen denken.
En dat is vaak nog wel een stapje verder.
En dat red je ook niet in een paar dagen training, zeg maar.
Maar dat is wel wat je nodig hebt om het tot succes te maken.
Naast nog eens, en wat je heel terecht aangeeft,
wat nog steeds een van mijn grootste frustraties in deze hele business is.
Wat ook gestuurd wordt door, en het is allemaal heel verklaarbaar,
door heel veel testers die de testautomatisch heringskant opgeduwd worden.
Die gaan met een tooltje nadoen,
wat ze voor die tijd allemaal zelf met het handje tussen air quotes,
die je nu even niet ziet, gedaan hebben.
En wat je daarvan krijgt is dat mensen inderdaad vaak naar UI-tools
of dat er een is, selenium is het vaak, maar het geldt een beetje voor al die UI-tools.
Wat mensen vaak dan ook niet realiseren, dat denken ze van ja,
of we geloven het niet als het niet op die laag werkt.
Of ja, dat is wat we weten, dus dat is hoe we automatiseren.
En wat mensen vaak niet zien, door dat gebrek aan kennis,
door dat gebrek aan developmentkennis, of door dat gebrek aan lef,
om gewoon eens met een developer erover te gaan praten,
is dat zijn de duurste tests om te schrijven.
Het gaat de meeste tijd in zitten, je hebt de meeste code nodig.
