{
  "$type": "site.standard.document",
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreicsf5futjpz3qbrkbee3zsqweuj3rknrs6dqfwalj5r23jdrl7xnm"
    },
    "mimeType": "image/jpeg",
    "size": 59484
  },
  "description": "Paul de Witt en Bas Dijkstra vertellen hun ervaringen en advies rondom Testautomatisering",
  "path": "/episodes/390",
  "publishedAt": "2021-05-18T11:51:30.000Z",
  "site": "at://did:plc:flhrheaiuteqoy65yixudwsv/site.standard.publication/self",
  "tags": [
    "Test automation",
    "Testing"
  ],
  "textContent": "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. Het risico dat ze breken is het hoogste en iedereen begint ermee. Ja, dat klopt. En dan heb je ook nog een keer het verhaal erbij dat de tester zelf niet een onderzoek kan doen waarom iets breekt, maar die is altijd afhankelijk van een developer die er mee moet kijken. Ja, te vaak nog in ieder geval, ja. Ja, dat is een interessante discussie ook, want je hoort toch wel vaker van, wat is nou een goede manier om, ja, ik ga nog maar even, we hebben het over test automation, maar wat is nou een goede manier om test automatisering meer in het team te krijgen? Ja, er zijn een paar kampen, valt mij op, dus dan één is, nou, we gaan alle testers die er nu zijn, die gaan we natuurlijk trainen om hele goede test automatiseerders te worden. Nou, goed, Bas, die weet daar alles van. Dus dat doen we dan vaak. En je hebt natuurlijk een kamp die zegt, ja, maar dat is hartstikke leuk en aardig, maar dat gaat nooit vliegen. Developers die moeten dat maar gaan doen. En op zich is voor alle beide, als ik jullie zo hoor, is wat te zeggen. Maar ik vraag me soms wel eens af of we niet iets te veel van developers vragen, want het lijkt net of aan developers ook vragen van joe, doe dit er maar ook maar bij en oh ja, straks komt ook nog een andere techniek. Jullie moeten ook nog gaan snappen hoe docker werkt en al die containers. Dus wordt dat niet een beetje te veel voor iedereen in zo'n team? Wat is de alternatief? Ja, kijk, ik zit even te denken aan de Agile Manifesto waar natuurlijk de klant centraal staat en happiness en joy met development. En dan ga ik het woord gewoon noemen, multidisciplinair zijn. Ja, maar ben je dat eigenlijk ook niet altijd in de zin van als jij in een team zit, dan ben je, wat ik net al zei, je bent gezamenlijk verantwoordelijk voor een stukje van de solution. Dat kan een feature zijn of wat dan ook. Dus dat betekent dat het op een bepaalde niveau dat je eigenlijk overal alles mee kunt praten. Dus je bent dat eigenlijk altijd wel. En ja, de vraag is zeg maar, wat jij zegt van joe, is dat niet te veel druk op de developers? Ja, heel flauw gezegd nee, want ze moeten natuurlijk sowieso al testen natuurlijk en met heel die shift left movement zie je dat sowieso al steeds meer die kant op schuiven. Maar dat betekent dus ook dat er een verschil komt tussen, of in zwaarheid tenminste, tussen integratietesten en end-to-end testen. Er is veel minder focus op de end-to-end gelegd, wat wij eigenlijk bij de meeste bedrijven die je in Nederland ziet, toch altijd het meeste vanuit de business perspectief het zwaartepunt krijgen. En ook het duur zijn. En dan heb je nog te maken met de type organisatie. Je is een organisatie die inderdaad volledig developer driven is, die een hoog volwassijnsniveau heeft in de teams. En dat is ook een bedrijf dat zelf voldoende inzicht heeft om kwaliteit te kunnen toetsen. Dat zijn allemaal factoren die meespelen bij zoiets natuurlijk. Dus ik denk dat er bedrijven zijn die altijd behoefte zullen hebben aan testers, testautomatiseerders of hoe je ze ook noemt, die gewoon die behoefte hebben aan die extra kwaliteitscheck. Dat heeft natuurlijk te maken met type bedrijf. Zit je bij de overheid, gevoelige informatie, dat soort zaken. Of zit je gewoon bij een bedrijf die gewoon echt heel erg volwassen is, heel erg stoer en durft te zeggen, ik heb gewoon vertrouwen in wat wij doen. Dat zie je ook bij de grote jongens op Facebook. Die vinden testen minder belangrijk. Die heeft zoiets van, wij zijn geen levensbedreigende dienst. Dus als wij een keertje down gaan, dan is dat minder erg dan dat ergens anders gebeurt. Ik was gelezen bij AWS dat ze gewoon op productietesten. Dat zijn wel dingen, dan heb je lef. Dan heb je ook een pat niveau bereikt. Dat zijn wij hier met de meeste bedrijven. Uiteindelijk zit het toch in de meerderheid bij financiële dienstverleners, achter die type organisaties. Die zijn er nog lang niet, natuurlijk. Nou, de risico's zijn natuurlijk ook heel anders. Daar wil je een heleboel natuurlijk ook checken, voordat je in productie gaat. Het risico en de schade zijn daar veel groter. Een mediabedrijf, je noemt Facebook, AWS, de Amazons en de Netflixen, die kennen ze allemaal wel. Die hebben een heel volwassen deploymentproces inderdaad. En die kunnen heel snel in productie meten van, oh, dit gaat even niet goed, oh, dan draaien we het weer terug. We rollen het uit naar kleine stapjes. In kleine stap naar kleine gebruikersgroepen. Dan wordt zo opgereageerd, dan gaan we een stapje verder. En wat je volgens mij zelf net ook al zei, niet ieder bedrijf, niet iedere business leent zich daar ook voor. Misschien moet ook niet iedere organisatie dat wel willen. Dat denk ik ook niet, eerlijk gezegd. Nee, dat is op zich, ja, ik denk ook, de developers met wie ik altijd wel veel samen heb gewerkt aan projecten die ik dan zou mogen inschatten als van, hey, dat is een capabel persoon, zeg maar, en een goede developer. Dat zijn toch wel vaak developers die die risico goed in kunnen schatten. Dus als ik inderdaad een of andere levensbedreigende stuk software aan het schrijven ben of een stuk software waardoor het hele bedrijf voor je het zou kunnen gaan, ja, die gaat eerst wat die gaat vragen die die stelt. Dus, jo, hoe gaan we die testen, weet je wel? Dus ik snap de behoefte inderdaad wel. Ja, ik zie daar ook gewoon de hele developer community voor zover ik daar inzichten heb en waar ik mee gewerkt heb dan. Dat is natuurlijk wel, dat beperkt tot die developers, die groepen en die organisaties waar ik mee heb gewerkt, dat dat besef en dat inzicht ook gewoon heel erg groeit. En dat ze steeds vaker en steeds vaker zelf veel beter kunnen testen. En vandaar dat ik zou graag willen dat nog meer developers dat voor een deel ook doen. Wat je zelf ook heel terecht zei, dat gaan we niet te veel van ze vragen. Maar ik vind dat daar zeker nog wel wat te winnen is. En daar hebben wij als testers denk ik ook nog wel een grote rol in om ze daar mee te helpen. Ja, dat klopt. Want zelfs het schrijven van een unit test is natuurlijk niet voor iedere developer hetzelfde. En het kan moeilijk zijn om bijvoorbeeld een unit test te testen uit een user story van hoe moet je hem doen, hoe moet je hem aanpakken. Het gebeurt me ook wel regelmatig dat ik inderdaad op een project zit en dat ik ook inderdaad gevraagd word om dan training te geven aan developers op bepaalde gebieden van testen die ook rechtstreeks met hun code testen te maken hebben. Dus niet altijd functioneel. En dat valt me op, maar dan kom je echt op de methode uit. Hoe stel je een goed testgeval op? Waar focus je op? Dat zijn dan wel echt de belangrijkste aandachtspunten. Kijk, want die techniek, dat komt wel goed. Dat kennen ze allemaal, dat vinden ze leuk. Daar staan ze mee op en gaan ze met de bet. Maar inderdaad van, ja, hoe ga ik wat precies testen? Daar zit van ons nog een hele belangrijke rol in. Absoluut. Ja, dat is de toegevoegde waarde misschien ook wel. Uiteindelijk komen we terug bij waar we waren. We gaan gewoon weer richting teamheb. Hoi. Hebben jullie allemaal een certificaat? Ik heb een certificaat niet. Niet? Nee, nooit gehaald. Ik heb altijd gedacht dat jij zo'n teamhebber was. Nee, ik heb het certificaat nooit gehaald. Ik heb wel verschillende methodieken geleerd. Veel te moeilijk was die ook natuurlijk, die toets. Die toets zelf, ja, het hele boek uit je hoofd kennen, dat was niet echt een hobby of zo. Nee, inderdaad. Dus nee, maar ik moet eerlijk zeggen dat het een grap is. Weet je wel, dit is de basis voor iedereen. Maar uiteindelijk hebben we ook nog andere methodieken voorbij zullen komen. Kleintjes en grote. Ja, in essentie weet je, je moet gewoon de dingen eruit halen dat die voor jou van belang zijn. En, nou ja, Bas zei het aan het begin, toen ik begon, toen werd iedereen weer tester. Ik zat in een team en de een was holistisch hele geweest en de andere was chiropractor geweest. Ja, serieus. En het was allemaal hele leuke mensen waren dat. En die werden we borstjes ingevlogen en we zaten op hele grote afdelingen bij KPN destijds. En, ja, daar ligt het hartstikke goed. Maar op een gegeven moment, toen kwam die crisis natuurlijk, ja, toen stond iedereen op straat, zeg maar. In 2008 was dat. En, ja, weet je, dan zie je toch wel het verschil van mensen die toch wel iets met een soort IT-achtergrond hebben. Die komen er wel mee weg in het vak, zeg maar. Weet je, die snappen wel wat er over gaat en zo. Maar mensen die nog steeds puur vanuit de methodiek handelen. Ja, dat is toch iets, weet je, dat is leuk in het begin om een soort handvaart mee te krijgen. Maar dat moet je ook loslaten. En ik zit nu op een project, daar heb ik ook iemand meegemaakt, die is testcoördinator. En die persoon die, ja, die merkt gewoon, die moet gewoon... Wat Bas net ook als voorbeeld gaf, die wordt gewoon gepusht in de automatisering en die wil dat gewoon niet. Ja, die hangt gewoon heel erg vast aan de team-app-methodologie, die natuurlijk ook veel meer de agile wensen kunnen maken worden is. Maar daarmee staat ze heel erg ver af van de business, zeg maar, weet je wel. En dat is toch wel echt waar het uiteindelijk om wel gaat. Wat is nou jouw toegevoegde waarde voor wat we aan het doen zijn met z'n allen? Ja. Ja, het is pijnlijk af en toe als je dat hoort. Maar goed, ja, blijkbaar zijn er toch wel een hele hoop bedrijven die daar zo mee wegkomen. Of ja, wegkomen, moet ik dat zeggen. Ja, eigenlijk moet het wel zo zijn. Want kijk, weet je, uiteindelijk hou je je de boel natuurlijk wel tegen. Dat klopt, ja. Maar uiteindelijk zijn het organisaties die het zelf ook doen. Want ik denk ook niet dat het heel gezond is als jij mensen van alle richting induwt. Ook al is het niet heel expliciet of wat dan ook. Maar toch dat je die transitie, dan moet je mensen ook kansen bieden, natuurlijk, zeg maar. Om op de kant op te gaan, is het prettiger bijzijn. Precies. En dan ga ik even een quote doen van, ja, het doet even niet toe wie dit nou zei, maar. Testers, die zijn niet meer nodig. Oh, die heb ik van heel veel mensen gehoord de afgelopen jaren. Dat noemen, dat... Ik hoor het meest op de laatste dag van mijn klus. Het is af, het is klaar. Ja, precies. Ja, je contract wordt niet meer verlengd. Ja, alweer. Ik denk dat... Heb je het nu over de taak of de rol, de functie, zeg maar? Ja, precies de rol, de functie, ja hoe noem je dat? De reden waarom je, zeg maar, in een team bent. Dat is dus tester. Ja, gelukkig maar. De taak, de activiteit, die gaat hopelijk niet verdwijnen. Oké, dat we daar even over eens zijn. De rol, ja, hij verandert vooral. Hij verandert al, in ieder geval zolang als ik meedraai, van mensen die nog langer meedraaien, dan hoor ik altijd, ja, voor dat jij begon was het nog weer heel anders. Het verandert heel al, heel veel. En je merkt dat er een populatie is die daar heel goed in mee kan. Of inderdaad de techniek opzoekt. En dan testautomatie, of soms zelfs gewoon, ik ken inmiddels best wel veel testers die developer zijn geworden. Omdat het uiteindelijk heel goed lag. En er zijn ook anderen die gaan meer, misschien de business kant op, of de proces ondersteunende kant noemen. Scrum Master, At Your Coach, PO, dat soort dingen. Maar er zijn ook nog steeds, voor goede testers is overal wel een plek. Maar dat zijn wel de mensen die een stuk breder kijken dan de methodiek. Die mee kunnen praten over techniek, ook al hoeven ze dan, schrijven ze misschien zelf niet de code, dat hoeft helemaal niet, maar die in ieder geval in die term kunnen praten. En gewoon vooral ook hele goede testers zijn. Daar blijft volgens mij altijd wel plek voor. En die hele wereld beweegt natuurlijk. Eerst is het altijd van we hebben het niet meer nodig, want alles wordt geautomatiseerd en developers gaan allemaal doen met die testen. En dan zie je van, die developers weten het dan ook niet. Hoe moeten wij dat nu ineens gaan doen? Help, maar wat moeten we dan doen? Misschien is het toch wel handiger als we goede testen erbij hebben. En dan komt het ineens weer van, oh ja, het verdwijnen gaat het niet. Het verandert continu, maar dat geldt voor heel veel dingen. Het is ook wel grappig, want ik vind zelf dat jullie testrol is toch relatief jong, vergelijken met andere rollen. Ik vond het ook wel heel interessant vroeger, wat ik net al zei, dat het eigenlijk de enige rol was in het technisch vak waar je niks technisch aan zat vroeger. Maar eigenlijk zie je nu pas echt sinds de laatste jaren echt een soort differentiatie in vakgebieden ontstaan. Wat natuurlijk eigenlijk in developers land al jaren gaande is, zeg maar. Dus ja, we zijn gewoon nu pas in een fase beland, zeg maar, qua splitsing en qua andere wegenbegaan, die developers al een hele jaren geleden hebben meegemaakt, bijvoorbeeld. Op andere gebieden weliswaar, maar dat is hetzelfde proces natuurlijk. Ja, want op zich kan ik me wel wat bij voorstellen, dat je dan op een ander pad zou willen kiezen. Maar als je het hebt over continuous, of nee, ik moet eigenlijk zeggen devops, en noem het maar even de new way of working. Waar kan je naartoe groeien dan als tester? Waar kan je naartoe groeien? Nou, weet je wat mij opvalt? Ik heb altijd veel verschillende soorten testen gedaan, ik ben nooit functioneel gestart, maar ik heb ook veel performance testen gedaan. En wat mij heel erg opvalt, is dat ik de laatste tijd ook al gevraagd word om tijdens mijn werk als testautomatisering op een project, naast al het normale, gangbare werk zogezegd, ook bijvoorbeeld al een klein stukje security testen mee te nemen. Dat is bijvoorbeeld geen specialisatie van mij, absoluut niet zelfs. Maar ja, het is natuurlijk wel heel makkelijk om bepaalde, laagdrempige security dingen mee te nemen. Dus wat men ook zeker weet in bepaalde radies, is dat bepaalde zaken toch wel afgedekt zijn. En dan praat je over zaken als SQL-injectie, of juist certificaten erop, dat zijn natuurlijk ook een vorm van security testjes. Je merkt dat men ook steeds meer ziet dat dat soort testen eigenlijk, en je gaat ook verwachten, dat dat soort testen ook bij de testautomatisering hoort. Dus in die zin zie je ook weer een ontwikkeling ontstaan, dat de testautomatisering eigenlijk een specialist moet zijn, en tegelijkertijd ook een soort van brede scoop op verschillende types testen moet kunnen hebben. Ik denk niet dat dat uiteindelijk zal er daar ook weer een splitsing in zijn, en meerdere specialisaties ontstaan. Maar dat is wel een interessante beweging natuurlijk, want het is natuurlijk net als een heel breed begrip testautomatisering, en voor ons is dat tegenwoordig het automatiseren van je technische en je functionele test, zo gezegd, in de sprints. Maar ja, het gaat veel breder dan dat, en dat is voor de buitenwereld niet altijd zichtbaar. Dus dan ziet een stakeholder bijvoorbeeld, een PO, een security test, ze moeten nog iets mee gaan doen, want dat is een beleid. Dus dat moeten we dan ook uitgaan voeren. Oh, we hebben een testautomatisering. Hoe kan je niet alvast wat testjes doen voordat partijen zoals Vox IT invliegen, dat we alvast zeker weten dat we wat dingen hebben, of dat we inderdaad in een pipeline wat standaard dingetjes mee hebben lopen. Dat zijn wel leuke dingetjes eigenlijk, want dat houdt het vak natuurlijk ook levendig en dynamisch, dat je ook op die manier weer uitgedaagd wordt. Dus ik denk wel dat het vooral heel belangrijk is dat je ook echt wel een soort liefde voor het vak hebt. En met vak bedoel ik dan echt wel de materie waar je in werkt, dus de code, de technologie die gebruikt worden. Tegenwoordig als cloud weet je wel dat je een beetje begrip hebt hoe dat in elkaar zit. Dat maakt het juist wel echt heel erg dynamisch. En daardoor denk ik niet dat die rol ooit op een manier zal verdwijnen, het zal eigenlijk altijd blijven gewoon evolueren. En als je het dan hebt over, op een gegeven moment de developers ook, die gaan dus ook meer richting testen, en dat bedoel ik mee, het automatiseren natuurlijk. Denk je dat dan op een gegeven moment, de developers dan op een gegeven moment diezelfde gedachten goed gaan dragen of blijft dat altijd wel een specialisme die iemand anders gaat uitvoeren, bijvoorbeeld performance of security? Ik denk dat het uiteindelijk, als je intiem samenwerkt, dat het elkaar wel versterkt en dat je elkaar ook helpt in die ontwikkeling. Ik maak nu steeds vaak ook mee dat ik gewoon met de developers samenwerkt die echt wel een heel goed idee hebben van hoe zij bepaalde testscopes zullen bepalen of op welke plekken ze wat voor type testen willen inzetten, of ze zelfs al mee kunnen schrijven en ook meesparren over de inhoud, zoals wij dat eigenlijk ook doen vanuit onze testrol met de solution die ze aan het bouwen zijn. En dat is eigenlijk een hele leuke ontwikkeling, want dan zie je eigenlijk dat je op dat moment al van elkaar naar het leren bent en dat je dus inderdaad dan de developers hebt die dus heel goed in een vak zijn en ook al echt heel volwassen aan het worden zijn aan die kwaliteitskant, zeg maar. Ja, en volgens mij is het uiteindelijk ook gewoon vooral iets dat moet gebeuren. En als je het meent, 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 of nou developer A of tester B dat uitvoert, volgens mij is het uiteindelijk en dan draait het natuurlijk sowieso met agile en DevOps dingen. Het is een teamverantwoordelijkheid. En het is aan het team om te zeggen van ja, dit is belangrijk en het is aan het team ook om te zorgen van A dat de benodigde skills in dat team aanwezig zijn en dat het gebeurt ook. En of dat dan specifiek de taak van de testautomatie in is of van de developer of van iemand anders in het team. Ja, dat zal per team denk ik ook een heel erg verschil hebben, uiteindelijk. Wie het leuk vindt, wie die skills heeft, wie die interesse heeft ook vooral. Het is vaak interesse en motivatie vaak nog veel belangrijker dan puur die skillset. Ja, precies. Die verbreding die moet je zeker op willen zoeken als dat inderdaad een noodzaak voor is. Ja, dat maak je ook beter in je vakken, uiteindelijk zelf. Bijvoorbeeld als je straks even over de test op de code... Kijk, als je op de code kan testen, dan weet je ook waar potentiële bottlenecks zullen ontstaan, bepaalde pijnpunten liggen. Ja, dat maak je ook veel sterker in je vak. En het geldt andersom natuurlijk ook als men weet van waar vaak de crux is in de testen. Dan kan een developer daar gelijk al zijn pijl oprichten met zijn eigen testen en dergelijk. Wat vinden jullie ervan om... Stel dat je bij een organisatie werkt en die zegt ik schrap alle titels, iedereen is developer. Of, wat is het, engineer. Zou je dat oké vinden? Ja, geef het beestje een naamje, dat maakt me niet zo veel uit hoor. Nou ja. Same. Eigenlijk wat ik net zei. Wie het doet en wat voor label er aan hangt. Wat diegene op zijn of haar visitekaartje heeft staan. Staat dat nog trouwens visitekaartjes? Moet dat uitleggen aan de luisteraars, wat het zijn? Heel lang geleden. Vroeger al. Maar dat vind ik persoonlijk niet een hele interessante discussie. Wie dat nou. Uiteindelijk, afhankelijk van wat je product is. Welke kwaliteit er aan moet hangen, moet je bepaalde dingen doen. En maak jij ads, zeg jij van. Wij gaan agile werken, wij gaan DevOps doen. Dan is dat team daar voor een heel groot deel verantwoordelijk voor. En dan moeten ze het ook regelen. En wie dat dan doet, maakt niet zoveel uit. Nee, precies. Ja, en zorgen dat je de juiste kennis aan boord hebt. En als je dat dan niet hebt, dan kan je nog experts invliegen. Om op weg te helpen. Maar dan is het dan steeds een team voor verantwoordelijkheid. Ja, want ook die experts invliegen. Vliegt dan alsjeblieft wel de experts in die, en dat is natuurlijk van tevoren heel moeilijk om te bepalen, maar die je meenemen daarin. Dat vind ik ook, ik ben zelf al 15 jaar lang externe overal. Dat heb ik wel moeten leren ook. Maar als ik bij een team kom, ik ga het niet meer voor ze doen. Ik ga ze helpen, ik ga ze een handvaart geven. Dat is meer het coachingmodel waar je het over hebt. Ja, ook daar weer, geef het een naampje. Maar uiteindelijk moet dat team het gaan oppakken. Natuurlijk kun je ze een heel eind op weg helpen, maar zij weten wat er moet gebeuren, zij weten de belang. En een vrij consequente eigenschap van externe is dat ze op een gegeven moment weggaan en wat dan? Ik zeg dat ook altijd als ik bij een nieuwe klant begin. Dan geef ik het ook mee van ja jongens, de bedoeling is dat jullie het een jaar gewoon zelf kunnen. Ik ga het opzetten, ik ga jullie mensen helpen, ik ga ze trainen en begeleiden om de job. Maar na een jaar dan staat alles, hopelijk. En dan wil ik gewoon afswaaien, zeg maar. Dat zouden meer mensen moeten doen. Ja, en ik merk ook inderdaad dat klanten er altijd heel erg positief op reageren. En ik besef me ook echt wel dat dit niet iets is wat iedereen zegt. Maar ik meen het ook oprecht, want ik heb ook al zo'n klus gedaan van drie jaar. Dat was dus mijn eerste klus. Ja weet je, dat soort trajecten zijn niet echt heel leuk. Op een gegeven moment ben je gewoon lopende bandwerk aan het doen. En ja, ik ben wel een creatieve persoon, dus ik vind het heel leuk als ik mee kan denken en ik kan helpen met het solution. Ik geloof er ook echt in. Maar als het dan staat, dan staat het. En dan denk ik dat dan heb ik mijn werk gedaan. En pas ook op het moment dat ze het zelf kunnen natuurlijk. Maar ja, dan is voor mij het hoofdsoor wel afgesloten en dan ga ik verder. Ik denk dat het een hele gezonde houding is ook. Maar dat zouden meer mensen moeten doen. Ja, oké. Maar dat zijn meestal inderdaad als je een consultant of externe bent. Maar er zitten natuurlijk ook nog steeds een hele hoop mensen die gewoon in een bedrijf zitten. Die het vak, zeg maar. En natuurlijk ook nog steeds productie moeten blijven draaien. Dus die hebben natuurlijk niet de luxe om te zeggen van, nou ik zet het neer met performance tests en ik ga weg. Er zijn heel veel organisaties tegenwoordig. Volgens mij hebben ze daar hele mooie termen intrapreneur voor. Oh, die ken ik niet. Dat het ondernemend zijn, terwijl je gewoon ergens bij een bedrijf in loopt. Ah, yes, yes, yes. En ik denk dat daar in heel veel organisaties ook best wel ruimte voor is. En dat die organisaties dat ook best wel af en toe meer zouden mogen stimuleren, dat soort dingen. Weet je wat meer dat gedacht goed? Ja, dat zie je ook wel eens met de titels. Dat je dan op een gegeven moment een principal engineer wordt. Ja, bijvoorbeeld. Ja, senior kan natuurlijk ook altijd. Maar als je dus inderdaad de capaciteit hebt om andere, wat je net zo mooi zegt, mee kan nemen in je kennis. En het ook zodanig kan neerleggen dat het dan op een gegeven moment een fundatie ontstaat en dan door kan naar het volgende. Ja, maar dat is wel een interessant punt wat jij zegt. Ik heb, toen ik uit het testvak ging bij Kalko, heb ik een tijdje lesgegeven aan de Haegens Hogeschool in testen. En ik heb er ook een pedagogische opleiding gedaan. En het leuke daarvan is dat ik echt wel heb geleerd hoe je een training moet geven. En dat is best wel moeilijk. En het is, je hebt mensen die zijn ontzettend goed in een vak. Dat heet Bas ook. Maar iets overbrengen, dat is echt een andere sport. En ja, we hebben nu over testautomatiseringen in zo'n mooiste vorm. We zetten iets neer. Iets van de grond weet je wel. Het moet goed staan. Het moet helemaal aansluiten wat er is. En er moet ook nog eens een overdrager. Je vraagt best wel wat van een specialist op dat moment natuurlijk. En dat is niet voor iedereen weggelegd. En dat maakt het ook zo moeilijk. Niet iedereen is in status om die kennis over te dragen op een goede manier. Ja, helemaal meet. En ik denk dat Bas daar natuurlijk ook ruime ervaring mee heeft. Hoe is het jou afgegaan de laatste tijd? Ik heb de afgelopen jaren heel veel trainingen gedaan. Ik heb daar net weer even een stapje terug in. Ik heb het bijna fulltime gedaan. Een jaar lang. Ja, die behoefte is er wel. Bij heel veel mensen om te zeggen van dat we willen hier toch meer mee. Maar ja, ik heb dat ook moeten leren. Ik heb niet zo... Paul, jij zegt dat jij een pedagogische opleiding gehad hebt. Af en toe denk ik van daar zou ik ook meer mee moeten, wat meer aandacht aan moeten besteden. Maar voorlopig kom ik er nog mee weg. Zonder die wat meer formele achtergrond met trainingen en workshops die ik doe. Maar ja, dat heb ik ook wel echt moeten leren. Ik hoor gelukkig van andere trainers ook dat ze dat ook heel erg moeten leren. En ook gewoon het zelf beseffen dat de eerste keer dat je een training of een workshop doet, dat is niet de beste die je gaat doen. Dat is niet de beste. Dat moet ook groeien en je oefeningen moeten groeien en je verhaal moet groeien. En dat is bij mij nu, dat groeit toch steeds. Elke keer als ik een training of een workshop doe of een presentatie ergens, dan wordt het weer een stukje beter. En wat wel heel fijn is, denk ik, en dat heb jij volgens mij precies hetzelfde Paul, is dat je, je komt wel echt uit het vakgebied. Ik denk dat ik beurt heel vaak met anecdotes of met voorbeelden of met oefeningen uit wat ik zelf eerder bij klanten heb gezien of wat ik heb gedaan. Ja, dat is waar. Ik zal je vertellen. Oh sorry, ik kan me breken. Nee, ga verder. Ja, ik wil zo maar eerst naar binnen. Want ik stel dat even kort. Ik heb dus een tijdje lesgegeven na zo'n school. Dat was echt vooral voor mezelf begonnen. En het leuke was, ik heb daar ook toen gesudeerd vroeger. En ik ging eigenlijk docentschap overnemen van mijn oud docent van vroeger, waar ik toen zelf studeerde. En er was een oud-wiskundige en die man was daar supergoed in. En nou was dat van alles, was dat mijn allerzwakste vakvroeger. En die gaf testen, zeg maar, volgens T-Map. En toen werkte ik helemaal groot nog bezig met testchool. En dat soort dingetjes, dat werd allemaal gebruikt in de klas. En in het begin liep ik met hem mee om te kijken hoe hij dat deed, natuurlijk. En zo. En ik gaf bij Kalko-westen, hij schaf ik al T-Map-trainings en dat soort dingetjes. En de grap was, dus toen zaten we daar in de klas. En hij ging dus alles heel wiskundig benaderen. Logische wiskunde, dat soort dingen. En dan is alles te verklaren. Maar ja, je zag die kopjes allemaal gewoon blank. En als je dan echt gaat... Ja, ik kwam uit het werkveld en met het beetje ervaring wat ik had op dat moment... had ik wel gelukkig voorbeelden die ik kon gebruiken. En ik kon ook aangeven wat soort dingen. Ik dacht, nou ja, dat doen we niet in de echte wereld, zeg maar, weet je. Dus daar gaan we ook vooral heen niet bij stilstaan. En ik heb echt studenten gehad die naar me toe kwamen van... Nou, sinds jij dit geeft nu snap ik eindelijk wat van doen, zij. En dat niks te naleen van die man. Dat was een fantastische docent. Ik heb hem zelf vroeger ook gehad. Alleen, gewoon die begrijpsvorming. Het helpt gewoon echt als je gewoon praat uit werkervaring. Uit situatie waar je in hebt gezeten. Dat maakt het gewoon voor iedereen gewoon begrijpbaar, eigenlijk. Ja, zeker. Dat is zo belangrijk dat je daar steeds blijf kritisch ook blijf kijken... in wat je beter zou kunnen doen. Ja, het is ook een reden dat ik... Het is vorig jaar langzaamaan naar bijna fulltime trainer toegegroeid. Maar we hebben altijd gezegd van... Ik wil nooit die jarenlang fulltime trainer worden slash blijven. Je mist op een gegeven moment gewoon die aansluiting met wat er in het werkveld gebeurt. En dat vakgebied ontwikkelt zich zo ontzettend snel. Je verouderd waar je bij staat. Gewoon dingen blijven doen ook en in organisaties blijven rondlopen. En dat is ook voor trainingen, maar ook voor blogs of artikelen schrijven... of na een presentatie, een conferentie of een meetup of weet ik wel wat geven. Je kunt niet jarenlang datzelfde verhaal, datzelfde trucje blijven doen... omdat die wereld om je heen gewoon zo enorm aan het veranderen is en blijft. Ja, dat klopt. Even kijken. Nou oké, ik stel voor dat we dan dit onderwerp even afsluiten... want er is nog genoeg over te vertellen natuurlijk, maar we hebben het niet de hele avond de tijd. Ik heb even weer een andere stelling. Ja, er is eentje die Bas voor de uitzending had aangedragen. Dat gaat over low-code testautomatisering. Hebben jullie daar ervaring mee? Tot op zekere hoogte ja. En Paul? Ja, een klein beetje inderdaad zelf meegewerkt. Als een van jullie een vertaling zou mogen maken voor onze luisteraars thuis... wat betekent low-code testautomatisering? Voor mij is het eigenlijk... we gebruikmaken van een tool waarbij je een abstractie laag bovenop de code hebt. Eigenlijk. Waarbij je niet zelf de Java of Python of C-Shark code schrijft... maar je test schrijft, modeleert, sleurt en pleurt, hoe je het wilt noemen... hangt een beetje af van de tool... in een abstractie laag daarboven. En soms is dat... en met grafische user interface, denk Postman of Catamom, weet ik veel wat. Noem maar tools. Of met keywords, denk Robot Framework, dat valt voor mij ook onder een low-code tool. Dat is voor mij, dat is wat ik onder low-code tool versta. Ik ben blij dat we hier over low-code hebben. Ik krijg licht allergische verschijnselen als mensen het over no-code tools hebben. Uiteindelijk wordt het namelijk allemaal code. En het is alleen op welke abstractie laag je je test schrijft in de code zelf... of maak je gebruik van een laagje naar bovenop. Dat is voor mij, daar zit voor mij het verschil. Ja, ik sluit me daar volledig bij aan eigenlijk. Dat is precies ook hoe ik het interpreteer. Welke voorbeelden zouden we hierbij kunnen bedenken? Ik heb zelf vroeger een klein beetje ervaring met UFT van HP. Nu tegenwoordig zie je specflow natuurlijk ook wel veel. Ja, die schaar ik dan daar weer net even niet onder, specflow. Maar dat wordt wel een hele lange discussie over. Ik vind dat geen testautomatiserings tool. Ja, het is een tool die je voor testautomatisering gebruikt. Maar het is niet een tool waarmee je direct interacteert met het applicatie die je aan het testen bent. Dus het is een living documentation. Maar goed, voordat we daar in de hele discussie daarover veranderen. Postman, robot framework noemde ik net al even. Sowieso veel commerciële tool vendors die hebben dat soort tools. Valt QCumber daar dus niet onder volgens jou? Ja, hetzelfde verhaal is specflow. Specflow is gewoon QCumber voor dotnet. Nee, omdat niet het primaire doel van die tool is om te testen. En dat is een andere nuance. Uiteindelijk hangen daar acceptatietests onder. Maar QCumber of specflow, die praat niet tegen je applicatie. Heb je altijd andere libraries voor nodig? Denk selenium, denk een API library, denk een database. Noem maar op. Dat soort dingen. Ja, kijk, het is een beetje een breed begrip inderdaad. Ik kan me ook wel wat bij voorstellen als mensen dat als lowcode zouden willen... In die zin, het is ook weer... Nu ga ik mezelf ook gewoon lekker gigantisch tegenspreken, want dat is wat ik doe. Het is een abstractie laag bovenop die testcode. Uiteindelijk, en het is een syntax die niet direct code is. Maar het is een tool die dat voor jou verdaalt naar code. Precies, ja. Zo zie ik het ook. Uiteraard, je zal altijd code nodig moeten hebben. Zoals Cucumber of Robot Framework of... Ja, noem het maar, willekeurige frameworks die iets met tekst moeten doen. En lowcode kan ook bijvoorbeeld een modeleertool zijn. Dus ik heb ook binnen de klanten met wie ik samenwerk, hebben we weleens model-based testing met test automation, zeg maar, toegepast. Dus daar ga je op een gegeven moment een model van het systeem, ga je op een of andere manier vertalen in iets wat iedereen kan begrijpen. En daar bedoel ik echt letterlijk iedereen mee. Dus niet alleen maar mensen die code kunnen lezen. Dat zou mijn vertaling zijn. En ja, je hebt daar ook allemaal no-code oplossingen voor. Maar goed, daar hebben we het nu even niet over. Maar de stelling is hier, is dat iets waar we iets mee moeten, denk jij? Is dat nou iets wat je graag in zou willen verdiepen of niet? Ik vind vanuit mijn eigen rol wel. Maar dat is omdat ik als externe bij heel veel verschillende bedrijven over de vloer kom, verschillende teams werken en die mensen hebben verschillende skillsets. En wat ik het best vind, is eigenlijk niet zo heel belangrijk. Het is wat is de beste keuze, de beste aanpak, de beste soort toeling voor een bepaald team met een bepaald skillset en ervaringen en een bepaald doel. En soms is dat code. En soms past daar een wat meer low-code oplossing gewoon beter bij. En er zijn prima, ik heb niks tegen low-code oplossingen, mids goed ingezet. Daarom breekt het nog wel eens aan, omdat mensen denken van oh het is low-code, dus je hoeft helemaal niks meer van software schrijven te snappen. Het probleem van die low-code tools is dat het je onkundige mensen veel makkelijker maakt om er een zootje van te maken. Ja, dat is waar. Het is inderdaad, zoals ik het vaak ervaren, is dat mensen die inderdaad op bedrijven of op een bepaald moment besluiten iets te gaan doen met testautomatisering, maar vanuit hun eigen rol of achtergrondtechniek toch wel een beetje eng vinden, dat die heel snel neigen naar zo'n soort oplossing. Omdat ze dan het gevoel hebben van een eigen soort vals gevoel van veiligheid, van hiermee kan ik wel uit de voeten en als het technisch wordt, ja dan schakel ik wel iemand in. Maar wat ze inderdaad niet beseffen terecht, is dat er vaak een hele laag tussen zit die puur techniek is, die gewoon communiceert met de applicatie op dat moment, ook met testrunners dat het ook mag zijn. Dus in die zin, ik sluit me verleden aan wat Bas zegt daarin, alleen ik denk wel dat het ook voor mensen op de werkvloer een risico kan zijn als men gaat kijken van wat voor toegang in zit in een organisatie zonder specialisten in te huren om daarover mee te denken, dat men inderdaad heel snel naar zo'n toegang neigen als het als een project bijvoorbeeld heel erg stil gedreven wordt vanuit de business, in plaats vanuit de techniek. Ja, dat is wel iets belangrijks wat ik denk dat nog weleens ontbreekt. Het ontbreekt sowieso gigantisch in alle marketing rondom dat soort tools, vind ik zelf. Het is vooral van kijk eens hoe makkelijk het is om hiermee te werken. Wat ze er achter de kom en daar niet bij zetten, het is van kijk hoe makkelijk het is om er hier een zootje van te maken. Hiermee. En je moet nog steeds wel heel goed nadenken over hoe ga je dit inzetten, hoe ga ik dingen gebruikbaar maken, kan ik bouwblokjes maken. En uiteindelijk, ook met dat soort tools, moet je gewoon objectorienteerd kunnen denken, volgens mij. Ja, precies. En dat ontbreekt er nog weleens te vaak. Ik heb het ook heel vaak over met wat teamgenoten van mij. In plaats van tech-tabbed, maak je text-tabbed. Ja, ja. Mooi gezegd. Ja. Dus ook met al die gurken, en sterker nog ook in de modeleer-tools. Daar zie je ook echt een hele hoop beginners-foutjes in het modeleeren van iets. En ja, dan ga je gewoon echt helemaal nat. Want dan ga je echt enorme, grote, complexe modellen maken, of teksten. Wat op een gegeven moment niemand meer begrijpt. En dan heb je de plank misgeslagen. Dat zegt ook wat over je test aanpakken. Als je van tevoren niet gewoon een goede testcase verzint, dan ga je gewoon lukkiger van alles bouwen, natuurlijk. En dat zie je dus ook vaak gebeuren. Ja, ik denk ook dat een testdesign wel eens wordt onderschat. Ja, absoluut. Steeds meer bij automatisering, eigenlijk. Ja, de ziekte van een heleboel test automatiseren is helaas dat we alleen maar willen automatiseren. Maar dat we het testen. Wat is nou een zinvolle test? Wat is nou een zinvolle informatie die ik naar boven wil halen? Dat ze dat helemaal vergeten. Ja, dat is een mooie brug ook naar een volgend onderwerp. Nu zeggen we dat best wel stellig ook. Dat zien we vaak in het werkveld. Maar hoe kunnen we de wereld een beetje beter maken? Wat kunnen we voor tips geven om beter te kunnen automatiseren in testen? Ja, dat is een goede vraag. Ik denk eigenlijk dat het allerbelangrijkste heel erg persoonlijk wil zijn. Dat het te maken heeft met je eigen doelen. Van welke kant wil je je bereiken? Dat zijn je sterke kanten. Dat is natuurlijk heel breed, heel vaag. Maar wat ik net al zei, niet iedereen is weggelegd voor een stukje techniek. Dus dan zou dat ook een keuze moeten zijn om daar vooral niet in die richting op te gaan. Maar als je er wel voor kiest, dan kom ik toch ook weer terug bij de devils verhaal. Bij de startupgedachte van wees ondernemer. Weet je wel gade voor. Probeer alles te begrijpen wat je kan. Probeer alle informatie te verslinden die je krijgt in je team. Of het nu gaat over AWS. Of gaat over frontend technologieën zoals Angular. Maakt het allemaal niet uit. Probeer het allemaal mee te nemen, allemaal te begrijpen. Alles maar op hoog niveau. Uiteindelijk zou je daar gewoon beter van worden in je vak. En zou je ook beter begrijpen hoe je testen efficiënt kan opzetten. Dat je je onderhoudstijd ook kan beperken, zeg maar. Ja, dat is een heel goed streven. Ik denk dat dat bij elk vakgebied wel een beetje geldt. De kunst van het blijven leren, zeg maar. Ja, die wereld gaat ongelooflijk snel. En als je in de wereld van test staat, maar je zit ook nog eens ergens op die scheidslijn tussen developer en tester. Je zult van allebei het een en ander moeten weten om dit tot een succes te maken. Een goede testatomatiserer is, weet hoe goed testen eruitziet. Een goede testatomatiserer weet ook hoe goede softwareschrijven eruitziet. En er komt daarnaast inderdaad nog eens al die tooling zoals cloud technologie, containers, CI orchestrators, dat er allemaal omheen. De hele engineering tak die dat uiteindelijk allemaal faciliteert. Daar moet je ook iets van weten. Het is best veel wat er uiteindelijk allemaal bij komt kijken. En dat wordt nog weleens onderschat. Ja, zeker, zeker. Dus als ik het een beetje mag samenvatten. Paul, jij begon net met verbreden van je kennis natuurlijk. Dat is sowieso echt altijd goed. Dan hebben we het weer over die vage D-shaped of M-shaped people. Dus dat houden we er altijd in. Dat verwachten we ook wel een beetje de laatste tijd van iedereen. En Bas zegt in feite, zorg ervoor dat je de innovaties lagen gewoon altijd meepakt. Omdat de innovatie natuurlijk blijft groeien. Dat is gewoon een feit. AI komt om de hoek. Machine learning. Dat zijn allemaal dingen waar we wat mee moeten. En ik kan me ook voorstellen dat als je een tester bent. Die misschien wat minder affiniteit daarmee heeft. En dat allemaal een beetje eng vindt. En eigenlijk alleen maar op het communicatie richting stakeholders en dat soort dingen. Want daar heb je ook natuurlijk een hele hoop testers in. Dus zorgen dat je weet wat je moet communiceren richting klanten. Als er iets fout gaat of bug reporting. Want dat soort testers heb je ook nog steeds. We hebben afgelopen in de laatste aflevering hebben we ook daar even over gehad. En wat ik daar zou willen aanraden is zorg ervoor dat je inderdaad gewoon heel goed bent in die testdesign. Zorg ervoor dat je iedereen meeneemt in jouw visie van hoe een goede testcase eruit ziet. Dat is één. Maar ook welke risico's je daarmee meeneemt. En dat je dat afstemt met iedereen. De toegevoegde waarde van je eigen, van wat je doet, kunnen verkopen. Of in ieder geval heel duidelijk over dat je dat over de bühne weet te brengen. Dit is wat ik doe. En dit is waarom dat belangrijk is. Ja, dat is zeker zo. Nou, mooi. Nou hebben we een paar mooie tips. Nou, dan wilde ik bij deze ook dan meteen het gedeelte van test automation even afsluiten. Pas precies op een cd'tje zie ik. We zijn met één minuut 19 aan het opnemen. Mooi, mooi, mooi. Maar jullie zijn nog niet van me af. Ik heb nog een hele leuke rubriek in petto. Ik hoop dat alle luisteraars thuis ook het leukste onderdeel van de podcast vinden. Al dat inhoudelijke gedoe. Precies, altijd onderzoek naar. Even een beetje loskomen. Het is een beetje een slechte naam nu in dit geval. Maar aan de andere kant ook weer wel. Het heet de developer dilemmas. Nou, dan weet ik ook wel dat als je test automation engineer of test automatiseerder bent, dan ben je gewoon een developer. Kom op. True. Don't kid yourself. Dus wat dat betreft, gaan we die doen? Nou, het is eigenlijk vrij simpel. Ik denk dat ik eerst gewoon met Paul zou willen beginnen. Ik ga jou twee stellingen, twee dilemma's geven. En je moet er eentje kiezen. Kom maar op, goed. Oké, hou je vast Paul. Dan komt-ie. Dat is goed, kom maar op. Tabs or spaces? Tabs. Bas? Spaces. Waarom tabs dan? Of we misschien waren op spaces? Leg het eens uit aan elkaar. Ik weet niet, ik doe het automatisch altijd gewoon of zo. Voor mij is het gewoon een bepaalde werkwijze. Eigenlijk. Heel sterk gedachte achter ofzo hoor. Nee, ik snap het. En waarom jij spaces? Eigenlijk een beetje hetzelfde. Niet puur op het zeg van nou dat als Paul dit neem ik dat. Wat ik het meeste zie, wat ik gewend ben. Dus voor mij dat. Ja, ik heb echt met developers op tafel zitten die daar echt bijna oorlog over wilden voeren. Maar ik merk dat dat bij jullie niet zo wordt. Nee, ook daar weer voor zoveel dingen. Maak daar gewoon afspraken over. Laat vooral alsjeblieft iedereen hetzelfde doen. In een team, in een code base. Ik heb ook weleens dat ik gewoon mensen train uit de business om technische testen te schrijven. En dan ben ik al heel blij dat ze iets schrijven. Dus dan ga ik er helemaal niet op letten zo. Nee, daar heb je helemaal gelijk. Behalve en dat ik dan wel altijd even moet uitdagen als ik dingen met Python doe. Dat die dingen wel significant zijn. Dat het wel uitmaakt. Ja, maar ik ben gewend om alles links uit te lijnen. Dat is wel een goed argument inderdaad. Dus als je echt een taal kiest die daar heel gevoelig voor is, zoals Python. Ja, dan ben je natuurlijk nat als je met Spaces komt. Denk ik. Of werkt Spaces ook met Python? Jazeker, als er maar minimaal twee zijn. Ja, dat is waar. Ja, dus mijn tip hierin zou zijn. Zet je tabs zodanig in dat die Spaces doet. Dan gaan we naar de volgende. Bas, wil je er klaar voor zitten? Ik weet het niet. Dat kan ik pas zeggen als ik het heb gehoord. Nou goed, hou je vast. Hij valt wel mee. Unit testing of end-to-end testing? Je moet kiezen. Unit testing. Oké, dat had ik niet gedacht. Dat had jij niet gedacht? Nee, puur vanuit... Ja, ik mocht niet allebei zeggen. Maar puur vanuit het feit dat er in onze... in ons vakgebied... veel en veel en veel te veel geld wordt weggegooid aan end-to-end testen. Hoe vaak ik test zie van... en mensen die een end-to-end test hebben en die zeggen van... Oh, maar dan kan ik ook deze 57 varianten daaronder hangen. Mooi tabelletje met QCumber of Robot Framework. Dat maakt mooi data driven. En dan hebben ze 57 end-to-end testen. Nu ben je onderliggende businesslogen aan het testen... die je ook met u de testen af kunnen testen. Of misschien met een integratietest. Ik zeg, nu heb je hele hele dure inefficiënte tests. Oh. Dus alleen al daarom, omdat ik dat nog te vaak zie... zeg ik, unit testen. Wij als test test test automatiseren... Ga je alsjeblieft daar eens wat meer in verdiepen. Ga met je developers praten van... wat doen zij nu eigenlijk? En waarom niet? Ga kijken wat ze... en ga meer die kant op en daarin verdiepen. Want er is... Je hebt al van die meetings waarvan je dacht... this should have been an email. Ik zie heel vaak end-to-end testen... This should have been a self-reviewing test. En jouw ervaring, Paul? Ja, nou, ik ga er ook in mee. Ik denk... Wat Bas zegt, dat herken ik volledig. End-to-end test is vaak een soort doel op zich... en gelijk de grootste kostenpost... en kost een behoopde tijd natuurlijk. En ik denk eigenlijk dat het doel altijd moet zijn... dat het streven moet zijn dat je de tests zo klein mogelijk... en zo stabiel mogelijk krijgt en zo snel mogelijk. Nou, we kennen allemaal de testpyramides natuurlijk. Maar ik zou eigenlijk willen zeggen... eigenlijk moet je eigenlijk altijd je doel zijn... om een soort van shift left move te maken. Probeer gewoon alles zo veel mogelijk... richting je integratie en je unit testen te brengen. Ik mocht er mij in kiezen. Ik zou ook zo'n integratietest gekozen hebben, eerlijk gezegd. Ja, dat is vaak het beste voorbij de wereld. Precies. En ik moet zeggen, vaak kom ik op... ik zei net al een beetje wat stiepe projecten ik vaak doe... maar het gebeurt dus ook vaak dat een project al van start is... en dat men denkt, oh jee, we moeten live... laten we het maar gaan testen. En dus dan word je ingevlogen. En dan zit ik in het begin altijd wel even op end-to-end... omdat er dan nog niks is en heb je iets. Want je hebt ook niet de tijd om op dat moment... alle unit testen aan kwaliteitscontrole te onderwerpen. Maar dan zet ik wel gelijk in op die move... dat we gewoon langzaamaan naar integratietesten... en naar unit testen gaan werken... om daar gewoon het zwaartepunt op te leggen. En dat moet eigenlijk altijd het streven zijn, denk ik. En ja, nogmaals, ik kom weer terug op het niveau van de mensen... en het kennisniveau natuurlijk. Maar dat vergt heel wat van de mensen zelf op kwaliteitsgebied... natuurlijk ook dat ze dat kunnen. Maar absoluut het doel. Ja, precies. En dat is wat Bas ook zei in het begin... afhankelijk van... ja, het is gewoon een lange termijn investering. Oké, nou, hartstikke mooi. Nou, dan gaan we nu naar de laatste. Ehm... Ik zit even te denken aan wie ik deze het beste kan vragen. Ik denk dat ik Paul nog wel even weer een keertje... Ja, ik ben benieuwd. Ja, ja, ja. Nou, dit is een makkie voor jou, denk ik. Cypress of selenium? Ja, dat weten we allemaal. Dat is Cypress natuurlijk. Oké, en voor de luisteraars thuis... want er zullen best wel een paar niet weten wat Cypress kan... en waarom het misschien wel beter is. Kan je iets over vertellen? Ja, dat is goed. Ik ben inmiddels echt een groot fan van deze tool. Ik probeer hem niet overal in te zetten. Dat hangt heel erg van de opdracht. Maar als men neigt naar een soort seleniumachtige oplossing... dan grijp ik vaak richting Cypress. En het is heel erg een opkomst... omdat het eigenlijk hetzelfde kan als selenium, maar beter. En daarmee bedoel ik eigenlijk dat gewoon het opzetten... en het van je test framework bijvoorbeeld in een kwartier al klaar kan zijn. Je nooit last hebt van issues met browser-updates en dat soort dingen... waar je met selenium natuurlijk al eens tegen aanloopt. Omdat zij een van de weinige testtools in de markt zijn... die hun technologie niet hebben gebaseerd op de webdriver-technologie. En je ziet nu ook dat grote frameworks het ook eigenlijk om armen. Dus bijvoorbeeld Angular, die altijd aanverenigd is. Dat is natuurlijk Protractor als go-to. Maar inmiddels leveren ze ook Cypress uit. Als je op de Vue-website gaat kijken... dan laden ze ook Cypress aan voor end-to-end-test bijvoorbeeld naast Suggest. Het is heel erg opkomend. En ik moet zeggen, ik kan er heel snel heel veel testen mee maken. Ook dynamische testen. Er zitten hele makkelijke mock- en stubfuncties in. API-test heb ik ook ingedaan. Dat werkt ook perfect. En er is laatst zelfs een stukje security-testing. En ik heb bijna nooit flaky tests ermee. En dat heeft uiteraard ook te maken met hoe je test opzet en hoe je ze schaalt. Waar zet je de knip in testen? Hoe maken we ze zo klein mogelijk? Maar het is een ontzettend krachtig tool. En eigenlijk, ik heb dus, wat ik net al zei, ik zit heel veel bij financiële dienstverleners. En daar zie je dus echt nog dat de hele Selenium-moving nog heel groot is. Eigenlijk loopt Nederland er ook een beetje meer achter, denk ik, ten opzichte van andere landen. Maar als je gaat kijken in bedrijven die echt software bouwen, die neigen allemaal niet meer naar Selenium. Die neigen allemaal naar andere tools. En daar zie je dus ook steeds meer wat Cypress wordt gekozen op voor integratie en end-to-end testniveau eigenlijk. Ja, ik ben ook heel erg verbaasd, misschien niet, maar aan de andere kant wel gecharmeerd over security testing met Cypress. Ja, nogmaals, het is hoog over hoor, maar het biedt je de mogelijkheden. Je hebt gewoon interactie met devtools. Ze hebben hele mooie commands zoals Cypress, Intercept. Daar kan je gewoon calls mee onderscheppen, kan je bewerken, kan je x-rays hard headers aanpassen, stubs maken ermee. Het is heel flexibel. En ook heel snel. En ze hebben een eigen syntax, wat eigenlijk gewoon JavaScript is. Maar het mooie is dat het een van hun statements is, want ze hebben een aantal best practices. Zo zijn ze Anti-Pattern, wat natuurlijk Selenium vaak wel voorschrijft. Of het is Selenium, maar dat vaak gebruikt wordt bij Selenium, moet ik zeggen. Maar bijvoorbeeld ook dat ze zeggen, als je echt JavaScript gaat schrijven om je test heen, dan gebruik je dat tool niet goed. Dus daarmee maakt het ook heel laagdrempelig om het zelf toe te passen en ook om bijvoorbeeld zelf commanders aan te maken en toe te voegen. Dus het is een hele veelzijdige tool eigenlijk. En ik ben hem eigenlijk bij toeval tegen het lijf gelopen een jaar of vier geleden. Toen was hij volgens mij net uit de beta. Dus dat was eerst invite only. En toen ben ik hem eigenlijk een keer op proef gaan gebruiken na Selenium, om te zien hoe het ging. En dat was niet alleen sneller, maar ook veel stabieler. En toen ben ik me eigenlijk steeds meer gaan gebruiken en steeds meer gaan verdiepen. En inmiddels staat hij bij mij hoog boven aan het lijstje, eerlijk gezegd. Oké, mooi. Bas, heb jij nog een beetje ervaring met Cypress? Een heel klein beetje. Maar ik hoor hier al dat ik toch mijn Java script skills een beetje moet gaan oppoetsen. Want ik wilde net een landschap breken voor Air Force Selenium. En dat was het alleen maar omdat de tool fantastisch is, maar de mensen die het gebruiken vaak het probleem is. Omdat je er prima hele goede tests mee kunt schrijven. Maar je moet daar wel wat meer werk voor doen dan wat ik gezien heb van Cypress. Wat ik wel heel fijn vind is dat er bindings beschikbaar zijn voor een heleboel verschillende programmeertalen. Dat je dus niet aan Java script vast hoeft te zitten. Ja, dus je bedoelt webdriver in dit geval? Ja, webdriver. Ja, die andere smaak ga ik het niet over hebben. Dus ja, je moet er meer werk voor doen. En ik ben er nooit zo heel erg mee bezig geweest. Omdat het gewoon niet iets is waar ik heel veel mee in aanraking ben gekomen. Ik hoor wat jij zegt, dit verhaal, wat jij vertelt Paul. Natuurlijk ook wel al een aantal jaren in het vakgebied. Maar ik heb zelf te weinig ervaring mee om te zeggen van dit is echt beter. Ik weet wel dat een en ander van selenium, ik werk er al een tijdje mee, over de libraries daar bovenop en daarvoor die mee ontwikkeld. En ik weet dat je er prima hele goede tests mee kunt schrijven. Maar dat het probleem inderdaad vaak is dat de mensen die het gebruiken daar niet voldoende diep in duiken. En dat de kennis daar een beetje ontbreekt. Dat is vaak op wat tutorials afgaan en zeggen van oh ja, nou, het werkt toch niet helemaal. Je moet er toch wat meer werk voor doen. En ik juich het alleen maar toe dat er meer tools op de markt komen die, zoals Cypress, die bepaalde dingen daarin makkelijker maken. Ik moet hier kiezen, dat weet ik wel, dan zeg ik selenium. Ik ga puur om even een beetje tegengast geven tegen dit prachtige verhaal van Paul. Omdat ik denk dat het nog steeds een fantastische tool is. Maar als je een echt antwoord hebt, kies wat het beste past. En ik word een beetje, nee, dit gaat een beetje tegen de natuur van van die developer dilemma in. Het maakt nou allemaal niet zo heel veel uit. Nee, nee, dat snap ik. Ja, ik begrijp je keuze. En soms is het gewoon ook omdat je natuurlijk meer ervaring mee hebt. En dat kan ook natuurlijk een reden zijn dat in mijn geval is dat echt zo. Ja, precies. Nee, helder, helder. Wat ik ook wel interessant vind aan overigens is dat front-end testing ook steeds meer een ding aan het worden is. Een front-end testing bedoel ik dan eigenlijk gewoon dat echt bijvoorbeeld puur de gooie van een web applicatie alleen getest wordt, zeg maar. Er zijn natuurlijk heel veel mooie tools al voor, zoals Puppeteer en dat soort dingetjes. Maar dat is juist eigenlijk toch wel iets wat echt van de laatste jaren sinds de grote frameworks zijn opgestaan echt een ding aan het worden is. En dan, kijk, dan zijn inderdaad dit soort tools weer uitermate geschikt, zeg maar. En dat vind ik ook weer, daar zijn we eigenlijk helemaal niet over gehad, maar dat is wel een leuke ontwikkeling in, vind ik zelf, in het vak. Want dat front-end testing stelt eigenlijk stiekem een beetje voor het voordoen, want dat is natuurlijk de gebruikerservaring, zeg maar, de beleving. Maar daar heb je niet die hele enorme kolossale back-end die daar achter hangt in productie voor nodig. Nee, precies. Ook dat is een inzicht, wat bij heel veel mensen zo... Kan dat dan? Dat ze alleen de applicatie als geheel kennen. Ja, klopt. Hebben we nog wel wat missiewerk te doen hier en daar, denk ik? Ja, absoluut. Dat definiëren van wat een component-test is, of het definiëren van wat een integratietest is, of een end-to-end-test, wat dat betreft. Ik denk dat dat ook wel gaat helpen. Dus als we iedereen meenemen hierin, van wat is het doel van zo'n test, en dat je een component-test ook prima gewoon op een UI kan doen zonder een back-end. Dus dat maakt het inderdaad heel waardevol. En snel natuurlijk, feedback natuurlijk, sneller. Oké, nou, hartstikke goed. Ik hoop het was niet te veel zweten voor jullie, hè? Nee, hoor. Het lukt me elke keer niet. Ik ga gewoon wat betere bedenken de volgende keer. Weet je wel, ik had juist verwacht dat er echt oorlog zou komen. Wat is dit nou? Dat is dus niet gebeurd. Het lukt me elke keer niet. Maar jullie zijn gewoon veel te lief, vind ik. Dat zou het zijn. Ja, precies. Nou, we gaan nu naar het laatste onderdeel van onze podcast. Ja, dat zijn eigenlijk een beetje de tips en tricks die onze luisteraars zou willen meegeven. En we hebben bewust hiervoor gekozen dat het heel breed mag zijn. Maar het mag natuurlijk ook over het onderwerp zelf gaan. Ik heb... Ja, dit keer heb ik eigenlijk geen tips. Dat is een beetje slecht van mij. Normaal heb ik altijd wel een paar achterhand. Maar misschien in de tussentijd kan ik er nog wel even eentje bedenken. Maar Paul, heb jij er misschien eentje waarvan je denkt van... Nou, ik heb dit van de week gezien. Die wil ik even met jullie delen. Ja, dat moet ik even goed nadenken, eerlijk gezegd. Muziek, boeken... Nou, dat geeft niet. Ik had trouwens voor mezelf wel even eentje opgeschreven. Nu zie ik er eentje. Ik heb toch maar even security testing met Cypress opgeschreven. Is daar nog ergens iets over te lezen? Of heb je een blog gezien ergens die daarover gaat? Nee, ik ben een blog aan het schrijven nu toevallig. En ik doe wel eens posten op Medium sinds kort. Ik had het onderwerp even getest en ik had wel leuke reacties gehad op Twitter hierop. Dus ik ben dat nu eigenlijk een beetje aan het voorbereiden en uitwerken. Oh, nice. Oké, dus dan hebben we in ieder geval één tip. Dat is dus jou Medium site en dan zal ik er wel even voor zorgen. Want we hebben ook show notes altijd in onze podcast. Dus zal ik hem daar opnemen. Ja, dat is goed. Ja, leuk man. Ja, super mooi. Nog andere dingen dat je leest tussendoor denk? Ja, ik sta te denken aan een boek wat ik aan het lezen ben. Oké. Eigenlijk. Dat is wel interessant. Je zei net al eventjes. Dat is misschien wel een leuke. We gaan heel filosofisch worden. Dat is altijd goed. Laat op de avond. Maar weet je wat? Ik heb van mezelf gemerkt op een gegeven moment in het leven dat ik best wel een touwistische inslag heb. Dus dat is een beetje, weet je wel. Je hebt natuurlijk vroeger een boekje van touwen van Poer en dat soort dingen. Het is zoals nu. Het is zoals het is. En weet je wel, berustend moment. Maar het meest interessante is eigenlijk vind ik altijd dat er heel veel over flow wordt gesproken. En flow is later natuurlijk ook een heel ding geworden in alles wat je doet. En ik heb vroeger altijd heel verschillende dingen gedaan. Vegsporten en dat soort dingen. Ik heb vroeger jarenlang capoeira gedaan. En dat is natuurlijk veg-sport en muziek samen. Ik dj, wat je al zei. Ik doe ook wel eens liedjes maken. Gewoon puur als hobby. Niet om naar huis te schrijven, maar dat maakt niet uit. Maar weet je, en dat zie je eigenlijk op. Alles heeft een ritme. Alles heeft een bepaalde flow. En die flow, zeg maar, als je dat, wat je ook aan het doen bent, als je dat vastpakt. En dat gaat voor testen. Net zoals voor programmeren. Programmeren is ook een heel goed voorbeeld ervan. Weet je wel, je kan niet even wat gaan doen. Ondertussen even wat anders gaan doen en weer terug. En dat soort dingen. Je presteert gewoon het beste als je gewoon in het moment zit en daardoor heen gaat. En ik ben daar nu een boek over aan het lezen. Dat heet de dingen die je alleen ziet als je er de tijd voor neemt. Dat is best wel een leuk boek. Met allemaal praktische tips ook en zo. En dat is natuurlijk heel filosofisch en diepgelijk. Maar het is ook wel heel praktisch ingesteld over het leven. En ik ben daar puur aan het lezen omdat ik denk dat is echt iets waar je in alles wat je doet komt mee tegen. Of je nou auto rijdt, op de weg zit in het verkeer. Of je aan het dansen bent. Of dat je een sport aan het beoefenen bent. Alles heeft een flow. En dat is iets wat niet heel veel mensen zich voor mij realiseren. Dat heb ik altijd de idee tenminste. Dat weet ik niet. Zeker weten man. Ja, nee, het gaat diep. En ik ga me zeker opschrijven. Hoe heette dat boek nogmaals? De dingen die je alleen ziet als je de tijd verneemt. Wauw, het is eigenlijk bijna een quote uit een testboek man. Ja, dat is ook wel leuk. Want ik kwam er bij toeval tegen, liep ik er tegenaan hoor, eerlijk gezegd. Maar dat was dus geschreven door een zenmonnik. En die was eigenlijk heel erg gegroeid op zijn social media. Dat die mensen oprecht hielp met dit soort struggles. En dat heeft hij eigenlijk gebundeld met zijn verhalen erbij in een boek. En dat is dus dit boek zeg maar. Dus dat zijn ook echt zo'n quote en echt voorbeelden van situatie waar je tegenaan is gelopen en zo. Het is gewoon heel leuk om te lezen. Het klinkt zwaarder dan het is, het leest best wel lekker weg. Maar het is vooral heel interessant vind ik zelf. Ja, nou mooi man. Het heeft in ieder geval mijn interesse gewekt. Ja, want het is inderdaad waar. Je kan het inderdaad overal toepassen. Dus discipline is gewoon, als je echt goed wil worden, discipline, ritme. Jezelf forceren om dat op te bouwen, dat maakt je alleen maar sterker denk ik. Ja, precies. Mooi, mooi man. Nou, we hebben Bas ook even de tijd gegeven om over na te denken. Ja, die had geluk. Ja, ik vind het nog moeilijk genoeg hoor. Maar even inhakend op wat je die laatste opmerking die je net maakte. Ik was gisteravond nog even een avondwandelingtje aan het maken en een podcast aan het luisteren. Dat ging dan toevallig over hardlopen. En over het verschil tussen discipline en motivatie inderdaad. Dat motivatie, daar hebben heel veel mensen het over. Maar het is eigenlijk lang niet zo belangrijk als discipline. Dat motivatie is heel vluchtig. Een discipline, dat als je echt ergens wil komen, is dat een heel stuk belangrijker. Uiteindelijk. Ja, dat is ook wel mooi ja. Ja. Weet je nog welke podcast het was? Ja, dat was Trail Runner Nation. En verder ben ik in het aanraden van dat soort boeken altijd heel erg slecht. Want ik lees eigenlijk vooral heel veel fictie. Oh, mag ook hoor. Ja, maar ook vaak hele simpele. En daar hou ik van. Wat ik wel heel gaaf vind, het laatste boek is volgens mij begin dit jaar of eind vorig jaar uitgekomen. Dat is de Kings Bridge serie. Dat is historische fictie. Het laatste boek, dat is het vierde boek. Dat is een soort prequel. Dat speelt voor die andere drie boeken. Maar het gaat over een stadje in Engeland. Dat spant inmiddels een jaar of 700 of zo. En het zijn dikke pillen. Het zijn boeken van acht, negenhonderd pagina's elk. Maar het leest echt alsof het veel korter is. En die vind ik wel, dat vind ik wel echt. Ik vind het ook echt gewoon leuk om af en toe dat soort dingen te lezen. Je hoeft even iets heel anders te hebben dan vakkenhoudelijke dingen. Dat soort dingen. En dat vind ik wel echt een boek die meer mensen zouden mogen lezen. Nou, als ik u goed. Ik heb hem opgegreven. Ja, precies. Het laatste boek van Kings Bridge serie. Nou, eigenlijk begin je vooral bij de eerste. Ken Follet is de auteur. Wat ik zeg, gaan we er wel even voor zitten. Want met die vier boeken bij elkaar heb je ongeveer drie en een half duizend pagina's door te gaan inmiddels. Maar het is echt heel vlot geschreven. Ik zal niet zeggen je bent zo erheen, want daarvan zijn het wel vrij veel pagina's. Maar het is fantastisch. Ja, zeker mooi. En van het eerste boek is ook een tv serie geweest. Het is niet zo heel bekend. Heet die ook hetzelfde? Ja, nee, de Kings Bridge serie. Pillars of the Earth. Dat is het eerste boek. Zo heette die tv serie ook. Maar die is wel een stuk minder dan het boek hoor. Maar dat geldt eigenlijk voor alle tv series die gebaseerd zijn. Ja, films inderdaad. Ja, films. Ja, dat is wel een aanrader. Klinkt leuk. Nog anderen dat jullie denken van die wil ik nog even delen? Kishen, ik weet dat je altijd heel goed bent in muziektips op Twitter. Ik probeer inderdaad wel als ik was hoor gelijk te delen inderdaad. Heb jij nog onlangs een track? Ja, je was bezig met een mix toch? Ik zag dat je met... Hoe heet het weer van Dr. Dre? Ja joh, dat is voor mij gewoon mijn uitlaat. Ik heb lekker creatief bezig zijn. En soms doe ik dj'en, gewoon mixjes maken en zo. Nog een keer weleens ergens draaien. Als ik toen nog kon zeg maar. Maar ja, ook wel liedjes maken met Ableton vind ik heel leuk. Na een jaar of tien aanklooien met het programma durf ik te zeggen dat ik nu eigenlijk geluid uitkrijg. Maar ja, ik ben inderdaad begonnen. Als grap, want ik zat een beetje... Ja vanavond, ik zat een beetje te spelen ermee. En ik had een liedje gemaakt van mezelf. En ik dacht heel... Ja, ik ben echt wel echt gek op house. Daar doe ik ook het beste mee draaien. Doe ik het meeste mee. Maar ik vind ook altijd hiphop heel erg leuk. Zeker dan die 90's boomweb tijd zeg maar. En toen dacht ik... Ja, dus ik dacht weet je... Ik zat de laatste tijd weer veel te luisteren van deze tijden. Ik dacht, ik ga gewoon eens Still Dre erbij pakken. En kijken of ik een beetje mee kan spelen. En toen kwam er eigenlijk best wel iets uit dat ik dacht... Het is eigenlijk wel leuk om hem verder te bouwen. Dus dat ben ik nu een beetje aan het uitbouwen zeg maar. Het wordt een soort house nummertje. Met echt de keys en de vibe van Scott Torch. Die piano heeft ingespeeld van Dre. Ja, dat is echt super vet. En ik heb een hele gaaf analoge synthesizer naast gekocht. Dus die gaat eronder. Ja, dat is leuk. Dat is gewoon een lekker hobby. Dat is echt lachen man. Ja, dat vind ik wel leuk om te doen. Als je dan over artiesten hebt momenteel. Anders zou ik zeggen Logic. Dat is ook iets voor jou trouwens. Logic? Ja, die ken je ineens nog niet? Nee, die ken ik nog niet. Dat is eigenlijk een hele jonge gozer. Uit Amerika. Die nu een aantal jaar bezig is. En die doet eigenlijk verschillende stijle hiphop maken. Ook Trap heeft die vroeg gedaan. Maar hij doet echt ook die oldschool stijl. Hij is ook heel groot aan het worden. Dus hij doet ook nummers met Eminem. Samen met de Wu-Tang Clan enzo. Dat is echt heel vet. Wauw. Ja. Oké, die ga ik zeker opschrijven. Ik heb hem net even opgezocht op Spotify. Ik zie u even linkjes straks. Ja, en ik zie ook echt inderdaad een jonge kop. Wauw. Die is dus echt... Ja, ik kan me ook voorstellen, ook nu in die corona... Oh sorry, dan gaan we toch over corona hebben Bas. Bijna bijna bijna. Bijna. Even ademen. Almost there. Oh fuck. Nee, maar ook in dit soort tijden denk ik van... Ja weetje, dat is echt heerlijk als je producer bent, denk ik. Gewoon lekker, helemaal tijd voor jezelf. Ja, ja, lijkt mij ook wel mooi werk hoor. Ik zie ook al eens die Tom Holkenberg van Junkic Cell, weet je wel, op Twitter. Die doet dat natuurlijk voor films tegenwoordig, dat ie dat. Oh, oké. En die doet ook filmpjes delen. En die geeft ook vast van die masterclass enzo. Dat is best wel interessant om te zien. Als je dan zijn studio ziet met al die synthesizers en instrumenten enzo. Ja, dat is ook wel een soort kleine jongensdroom, zeg maar. Ja, zeker, ja. Ja, ik volg A-Track. Oh ja, hij is fantastisch. Ja, die is echt, die is gewoon sick. Ja, dat is echt de beste DJ van de wereld, vind ik zelf. Ja, dat denk ik ook. Hij is heel veelzijdig. Echt heel gelukkig, ook qua produce ook heel goed. Ja, hij doet echt van alles. Volgens mij kan hij van een klassiek nummer zelfs een danceplaat maken. Heb ik het idee soms. Maar ja, het is echt geweldig hoe hij dat doet. Nou, oké. Ja, ik denk dat we al best veel tips hebben. Ik heb al bijna een halve pagina volopgeschreven. Dus die komen onze luisteraars kant op. Alsjeblieft bedankt, jongens, voor de tips. Ja, ik geef de wetten graag aan. Ja, nou, dat was hem weer, deze aflevering. Nou, ik wilde ten eerste natuurlijk Paul de Witte en Bas Dijkstra bedanken voor je deelname. Het was echt een hele leerzame les. Dus over test automation in het algemeen, maar ook toch wel wat diepte ingegaan. Over misschien ook een beetje richting de toekomst. En waar we nu staan en wat we ervan vinden. Dus bedankt voor het delen van jullie meningen. Even kijken. Ja, en natuurlijk iedereen leuk dat je hebt geluisterd weer. En we verwelkom je op onze website codeklets.nl. Daar staat een link naar onze Slack kanaal. Want ja, je kan ons echt wat dat betreft gewoon echt opzoeken en feedback geven. Dus op onze Slack reageren we vrij snel. Waardoor je, ja, en daar kan je natuurlijk ook met ons kletsen. Maar ook met andere codekletsers, zou ik zo maar even zeggen. En andere zaken. En verder wil ik ook nogmaals zoveel bedanken voor het mogelijk maken van de online opnames. Want ja, Zemcast heeft ons toch wel gered in deze periode. We kunnen elkaar niet fysiek ontmoeten. Dus hopelijk dat dat snel weer kan. Ik hoor er wel wat positieve geluiden. Want dat het een beetje richting meer vrijheid komt, of niet? Dit is voor Bas. Ja, laten we het hopen. Ik denk dat iedereen daar gewoon heel erg naar uit kijkt. Ja, zeker. Goed. Hey, alsjeblieft bedankt nogmaals. En tot de volgende keer. Doei. Doei. Ja, het was hartstikke leuk joh. Dankjewel. Heel graag gedaan.",
  "title": "Paul de Witt en Bas Dijkstra over Testautomatisering",
  "updatedAt": "2026-02-12T12:09:50.773Z"
}