Caroline Geven: Het belang van testen - oftewel - waarom ik het leuk vind om jouw code te sl...
Elk development team heeft tenminste één persoon nodig die graag dingen sloopt en dat betekent dat elk development team tenminste één persoon heeft die paniek veroorzaakt als hij of zij zegt. Weet je, ik test dat wel voor je en als het een beetje een goed team is dan raakt de rest een paniek. Ik zal me eerst even voorstellen, ik ben Caroline. Ik ben technisch applicatiebeerder bij Joost slash product owner van de plugin inderdaad en vier jaar geleden ben ik bij Joost gekomen als junior software developer en toen kwam ik erachter dat ik het eigenlijk veel leuker vond om alles te slopen wat mijn collega's maakten en ik doe dat eigenlijk niet zo heel erg meer op dit moment ben ik vooral bezig met zorgen dat dat de teams voornamelijk bezig kunnen kunnen zijn met de issues om het op te lossen. Maar vandaag leg ik uit waarom het zo belangrijk is om je plugin en je thema of je projecten te testen en ook natuurlijk hoe je de test want ja ik hoop allemaal dat we het belang zien van testen maar hoe je dat dan ook daadwerkelijk goed doet dat is nog even een vraag. Ik heb een paar vragen voor jullie, steek je hand op wie van jullie vindt testen voor je iets released belangrijk en misschien zelfs wel essentieel. Nou, dat is mooi. Wie de test zijn of haar code voor het gepoest wordt of gemurist of wat dan ook. Oké, en wie van jullie laat andere jullie code testen? Oké, en wie het gevoel dat het zijn of haar code goed genoeg is getest voor het live gaat. En als mijn collega's nu de handen niet opsteken dan loop ik hier gewoon weer uit want dan moet ik gaan testen blijven. Oké, nog een vraag. Wie hier durft te zeggen dat welke bug je ook per ongeluk hebt geïntroduceerd, die bug nooit live zal komen omdat jullie huidige systeem zo waterdicht is dat het niet zover kan komen. Nou ja ik dus ook niet, jammer. Ja, kijk, we kunnen concluderen dat niemand de omgeving heeft om maar continu bug's introduceren. Je moet dus secuur zijn. Maar ja, hoe doen we dat? Laatste vraag dat beloof ik.  Wie houdt hier van testen? Kijk, ik had dus gehad dat het 75 procent van de zaal was waar ja, dit was denk ik 5 procent of 10 procent. Ja, ik snap het wel. De meeste developers hebben een gruwelijke hekel aan aan testen en ik had dat ook vier jaar geleden maar dat is één ding waar ik een groter hekel aan had dan testen en dat waren gebruikers die klaagden over bugs die ik echt wel zelf had kunnen vinden. Als ik het product zelf beter had gekend of zelf beter had gekeken. En natuurlijk zijn er altijd bugs die je niet kan vinden vanwege omgevingen of compatibility met andere plugins of thema's, backwards compatibility en al dat soort dingen. Maar we zitten nu helemaal in WordPress dus daar moeten we er gewoon maar mee dealen. Dan heb je waarschijnlijk ook een vraag voor mij. Misschien wil je me vertellen. Ik heb geen bugs of ik wil helemaal. Ik ben gewoon helemaal niet druk bij. In de ideale wereld heb je geen bugs. Ik gebruik iedereen jouw product. De hele wereld snapt het belang van jouw product en heeft het nodig. En dan heb je geld zat om het testen te huren. Nu weet je wat? Je huurt gewoon een hele team van testen. Want jij had het toch geld zat. Maar nu weet je daar gewoon nog niet. Dus dan is je vraag misschien aan mij. Als ik dit nog allemaal niet heb, als ik het geld niet heb om een test team te huren en als ik niet veel gebruikers heb, waarom zou ik dan testen? Dat is een verspilling van tijd en geld. En ik kan mijn tijd als developer veel beter gebruiken. En dat snap ik. Ik ben het totaal niet met je eens. Maar ik snap wat je zegt. En dit zijn echt de smoesjes die ik heb gehoord de afgelopen jaren dat ik developer ben. Ik kan mijn tijd beter gebruiken. Ik heb weinig gebruikers. Dus ja, maakt het uit. En er is geen geld om het testen in te huren. Bij Jozef hebben we meer dan 8 miljoen gebruikers. En logischerwijs vertellen veel mensen aan mij dat wij natuurlijk moeten testen. En als wij dingen breken, dan gaan er natuurlijk starts kapot. En onze impact is gewoon dat klopt.  Maar wanneer je smoesjes verzint om niet te hoeven testen, zeg je dat kwaliteit niet belangrijk is tot je groot genoeg bent. En bij die logica, wanneer ben je dan groot genoeg? Zeg je dat kwaliteit belangrijk is en handelen naar kwaliteit zijn twee verschillende dingen. En dit hier ben ik zelf achtergekomen de afgelopen jaren. Ik heb bij verschillende bedrijven gewerkt en ik heb bij sollicitatiesgesprek altijd gevraagd, gewoon wat vinden jullie van kwaliteit? En dan sprak ik met de manager en hij zei nou kwaliteit vind ik echt zo belangrijk. Wij doen aan per programming. We doen aan acceptance testen. We zullen nooit zomaar live pushen en prachtig. En dan denk ik nou, oké, goed, dit is echt een goed bedrijf hier wil ik werken. En dan kom ik eigenlijk altijd achter dat het de manager is die denkt dat het belangrijk is, maar het team daadwerkelijk anders functioneert. Er moet opgeleverd worden, het moet binnen een half uur af. De klant die het hartstikke oud krijgt het ook meteen. Ik heb developers gehad die aangeven dat ze niet hoeven te testen, want ja, ze hebben maar een half uur of het is een edge case of erger. Deze vind ik echt, echt, echt heel erg. Een klant moet daar gewoon niet klikken. Dat kan echt niet. De klant zal daar klikken, gegaandeerd. Testen is belangrijk om kwaliteit te garanderen. Maar om kwaliteit te weten, om kwaliteit te meten moet je weten wat kwaliteit is. Is dat als er geen bug smear zijn of is het iets anders? Ik denk dat het een deel user happiness is. Een van de belangrijkste redenen om kwaliteit te vergroten is je gebruiker. Als de gebruiker blij is, dan sprijt zich dat. Ik kan een complete talk hierover geven over waarom gebruikers fantastisch zijn en waarom ze te vriend moeten houden. Maar er zijn usability en accessibility experts die daar veel beter in zijn dan ik. Dus ik hou dit kort. User happiness bereik je als het product doet wat de gebruiker verwacht dat het doet. Als alle links werken, als de buttons doen wat ze zeggen dat ze doen, als input fields ze juist een feedback geven. En dit ga ik demonstreren met een voorbeeld. Live demo. Het is niet zo heel spannend gelukkig. Niet zo heel spannend, gaat er wel mis. There we are. Ik heb een input field.  Stel je voor dat je een developer bent en je hebt echt een hele, hele belangrijke taak. Jij moet een tekstveld maken waar iemand een geboorte datum in kan vullen. Nou, oké, ik heb een input field hier en het vraagt naar mijn geboorte datum. Nou ja, eenvoudig, het heeft een placeholder waar het zegt dat ik dag, dag, slash, maand, maand. Ik zou hem even, kan ik trouwens, kan iedereen goed zien of moet ik hem even inzoomen? Ja. Als ik dit noem, dan zien we dus hier dag, dag, slash, maand, maand, slash, ja, ja, ja, ja. Oké, nou dan doe ik dit. Dat is mijn geboorte datum. Oké, klaar. Een aantal voor jullie. Ja, ik ben klaar. Volgens mijn definitie van wat ik moet opleveren ben ik nu gewoon klaar en ik zie al wat mensen willen protoceren en daar ben ik heel blij mee. En als je op dit moment echt tegen mij wil schreeuwen, maar je bent nog niet klaar, dan echt serieus. Goed zo, dank je wel. Dan heb je serieus een tester heel erg diep van binnen. Ik ben echt inderdaad nog niet klaar. Ik heb alleen maar de happy path werkend nu en de happy path is de, is de standaardscenario zonder, zonder uitzonderingen of zonder fouten. Maar ja, wat als je nu Amerikaans bent en je gebruikt een andere date voor het? Wat is het maand, maand, dag, dag, kan ik dat? Oké, nou ik denk maand die en maand die, dag die en oké, dat kan ook. Dus je kan op 12 maand 31 jaren zijn en kan ik ook tekst invullen dan. Oké, dat schiet natuurlijk niet op, hè. Als je geen datacanatisation hebt, dan kan je data of fout zijn of totaal neteloos. En ik geef totaal de user geen feedback over het formaat waarin zijn geboorte datum is ingevuld. Ik kan ook datum schouwens in de toekomst te invullen. Dus ik kan gewoon in feite nu op dit moment even kijken over twee jaar geboren worden. Volgens mij code kan ik op dit moment geboren worden in 2020. Dat is natuurlijk niet heel handig. Even kijken. Wat zijn we er hier? Yes. Je kan niet meer vertellen dat een gebruiker hun geboorte dag op een papierenformuleer moet invullen, soms voor de belastingdienst bijvoorbeeld.  En dan krijgen ze ook geen validatie, kunnen ze ook fouten maken en dat klopt. Maar gebruikers die willen direct een beloning, nu helemaal met het internet. Ze moeten geholpen worden om je producten te snappen. Niemand snapt de belastingdienst, maar dat houdt niet in dat jouw product dan vergelijkbaar moet zijn. En gebruikers zijn ook niet verantwoordelijk om niet dat te doen. En dit veldt natuurlijk een over de top voorbeeld van waarom je niet alleen maar moet focussen op happy path testing. Maar ik wil even demonstreren met een voorbeeld. Wij hebben één keer in het, één keer in de week op bij ons kantoor een dev-presentatie en dan een van de developers die geeft een prestatie aan de rest van de developers. En ik heb een tijdje geleden een prestatie gegeven over testen. We hebben live getest onze belangrijkste feature in de plug-in. Dat is onze snippet editor waarin je ziet hoe het in Google eruit komt te zien. En één van de developers die zei, niet daarop klikken. En binnen één minuut, drie developers, verschillende dingen, niet daar klikken. Alsjeblieft niet dat issue. En oh, ik wist niet dat dat ook kapot was. Ik plaag ze daar, ik stiek hem nog steeds mee. Ik vind het echt heel grappig. Er zit een aantal hiervan in de zaal en ik ga ook gewoon niet vertellen wie, waar ze weten dit zelf wel. En tijdens mijn praatjes, zagen de developers mij als gebruiker. En zo kwamen ze er ook achter hoe gebruikers het product kunnen slopen. Zoals ik net al zei, binnen elk developer zit een tester die wacht om eruit te komen. En dat brengt mij bij het volgende punt en dat is developer happiness. Ik heb gelogen over hoeveel vragen ik jullie zou stellen, maar ik heb een hele goede reden en dit zijn hele makkelijke vragen. Wie houdt van buxies in zijn of haar code? Goed, wat een verrassing. En wie van jullie vond het fantastisch dat ik haar niet aandacht om validatie in mijn veld in te bouwen? En wie wou dat invrijven? Gewoon eerlijk zijn, hè? Ja, precies. Ik zie de testjes al een beetje de handen.  Het voelt ook echt wel heel erg goed om iemand fout te zien maken, toch? Dus ik vind dat eigenlijk altijd wel een beetje leuk om mensen te laten zien, nou weet je, het gewoon een fout gebruikt. En voor een moment, op zo'n moment, denk je ook gewoon als een gebruiker. En voor een moment was je ook na het werken gebruiker. Developers zijn makers. We maken producten. We hebben creatieve omgevingen nodig om die producten goed te maken. Maar we zijn ook heel erg goed om anderen te helpen met het maken. We kunnen anderen alleen niet helpen zonder het maken van ervaringen van onszelf, zonder te weten of ze hebben getest wat werkt en wat niet werkt en wat best practices en wat niet. Veldvalidatie is normaal nu, maar een paar jaar geleden toen dat allemaal net werd bedacht, weet ik echt 100 procent zeker dat veldvalidatie toen nog niet heel normaal was. We konden toen echt lelijke dingen doen met forms, denk ik, aan complete databese drops en javascript injecties. En dat zijn dingen die nu gewoon, als je dat nu nog voor elkaar krijgt, dan heb je ergens een foutje gemaakt, dan weet je zelf ook wel. En de bugs die ik nu zie, zijn ook veel complexer dan 3 jaar geleden bij Joost bijvoorbeeld, omdat we groeien als een team en ook als individu. En dat doen we door te testen. En deze wordcamp is daar bijvoorbeeld, is ook echt het perfecte voorbeeld daarvan. Er zijn verschillende tracks met interessante talks en deze talks zouden er niet zijn als de speakers, de makers dus, niet hebben getest of een talk werkt of de organisatoren niet hebben geleerd wat wel werkt, wat niet werkt. En of dit nu je eerste wordcamp of conferentie is, of je team de of je honderdste, je bent nu aan het testen wat werkt voor jou en wat werkt niet. En we delen onze ervaringen en onze testresultaten ook met elkaar. Het helpt je team en het helpt jou met het groeien als developer. En op deze manier verandert jouk kijk naar de code ook. Je hebt een hekel aan bugs in je code dus, maar je vindt het waarschijnlijk wel leuk om de bugs aan te wijzen die andere maken, omdat je ook kwaliteit wil. En de omgeving waar je werk bepaalt deels je kijk op kwaliteit.  En het maakt je ook een betere of een slechtere developer. Als je werkomgeving zorgt voor de makers, de developers, zul je uiteindelijk beter code schrijven. Maar heel leuk. Ik heb je dus nu echt verteld waarom je moet testen. En ik hoop eigenlijk dat je het gewoon met mij eens bent dat je gewoon moet testen. Maar ik heb wel vaker de vraag gehad bij mij op kantoor. Heel leuk, maar hoe test je dan? Hoe zorg je ervoor dat je al die dingen dan ook echt aan het werkelijk kapot maakt en hoe zorg je ervoor dat ik niet jou aan het eind van de dag aan mijn bureau heb staan omdat er gewoon iets kapot is wat ik zelf had kunnen vinden. Ik zou eerst het handmatig en zowel het automatische testen ook bespreken. Het handmatig testen doe je zonder automation tools. Je hebt een omgeving nodig met het product wat je wilt testen. Misschien een change log of een issue. Je hebt duidelijke use cases nodig. Bij jou's testen we handmatig, dat doen we elke release. En als het goed gedaan wordt, wordt elke nieuwe feature of elke book tenminste vier keer getest door vier verschillende developers of testers. En dat klinkt eigenlijk heel erg veel. Zijn voor dat we dus die birthday field hebben. En dan hebben we de implementatie door een developer en die developers aan het testen. Dat is de eerste keer dat het dus getest wordt. Maar ja, ik vertrouwde het developer die het heeft gemaakt per definitie niet. Dat is niet omdat ik ze niet mag, maar het is gewoon omdat je heel erg diep in context zit. Dan komt er een code review. Dat is een tweede developer die de code helemaal naleest. Die checked, goalsie, gekke dingen. Dat is echt je tweede paar ogen. Ze had twee keer getest nu. Dan heb je de acceptance test. Dat is de derde keer. En bij een acceptance test kijkt een andere developer dan de eerste twee. Of het daadwerkelijk doet wat het zou moeten doen. En dan hebben we de vierde en dan is de tester. En dit gebeurt dus tijdens het releaseproces dat een tester. Dat zijn verschillende mensen bij ons in het bedrijf die de hele plug-in nalopen. Om te kijken of dat werkelijk goed is.  Het nadeel je van is dat je veel developers en testers nodig hebt die het product kennen. Het voordeel is veel groter. Want de meeste bugs zullen gespot worden voordat ze ooit ge-release zijn. Als je ons product gebruikt, heb je ongetwijfeld al een keer een bug gezien. Of misschien zelfs wel ingeschoten op kitten. Ik kan je garanderen dat het echt honderdduizend keer ergens was geweest. Als er geen testers bij ons waren. Een tester kan onderdeel van je proces zijn. Of in je scrum of dat je nu kan gebruiken van andere methode. Dan heb je nog geautomatiseerd testen. En dat willen wij ook heel erg graag bij jou. We vragen ons ook regelmatig af. Kunnen we het proces van dezelfde use cases handmatig testen niet automatiseren. En ja, dat kan. Dat kan met unitests natuurlijk. Onze developers schrijven veel unitests voor elke use case schrijven ze die. En natuurlijk ook door middel van automated testing. We hebben een dedicated tester op dit moment. En daar ben ik heel erg blij mee. Zij schrijven geautomatiseerde testen met behulp van codecept.js. En dat is ook heel erg handig voor competitie met plugins. Met thema's, ouderen versies van WordPress en standalone. Wat zij kan met één test. Als ik dat nu handmatig zou moeten doen, ben ik een paar uur of misschien wel een dag bezig. Omdat je allerlei edge cases heel snel kan testen. Het gaat een stuk sneller in plaats van dat ik met de hand dus plugins moet activeren. En moet deactiveren en bepaalde combinaties mag ik misschien niet vergeten. Dus er is gewoon een veel grotere fout gevoeligheid. Maar je moet wel handmatig kunnen testen om geautomatiseerde testen kunnen schrijven. Je moet weten wat je use cases zijn. Dus we hebben het gehad over het belang van testen. Maar het belangrijkste is nog wel hoe begin je met testen. Ik kan niet naast je zitten om je er doorheen te loten. Als je bij Joost werkt trouwens wel, dan kom ik graag naast je zitten. Maar ik heb vijf vragen die je jezelf kan stellen, terwijl je ontwikkelt of test. En deze lijst is vast niet compleet. Pas hem ook over jezelf aan als je stappen mist. Als je nee op één van deze vragen antwoordt, is het echt betekend dat het een onduidelijk issue is.  Of dat het niet goed ontwikkeld is door de developer of je begrijpt zelf iets niet. Wat de reden ook is, nee, is echt alarmbellen. De eerste vraag is hoe begin je met testen, heb je de bug kunnen reproduceren? Dat is een redelijke simpele voordat je überhaupt gaat kijken of een bug gefixed is. Moet je 100% zeker weten dat de bug ook daadwerkelijk te reproduceren is. Dat jij snapt wat de bug doet. Als een linkje bijvoorbeeld niet werkt, moet je daadwerkelijk hebben gezien dat het linkje niet werkt. Als je antwoord jij is, dan ga je naar vraag 2. Heb je kunnen verifieren dat de bugs opgelost? Nou, dan zul je dus de nieuwe versie pakken. Dan ga je kijken, werkt het linkje nu bijvoorbeeld wel. Ik kan bijvoorbeeld mijn inputfield wel, de juiste validatie. Je krijgt dat nu wel, krijg ik nu wel een alarm als ik tekst invul voor mijn geboorte datum. Zo ja, dan ga je naar vraag 3. Heb je gerelateerde functionaliteit getest? En dit is altijd een wat lastigere. Dit zijn de unhappy parts, de dingen die daar aanvast zitten. Als je eens een keer code hebt, als ik een link heb bijvoorbeeld. Dan kan het zijn dat er nog onderliggend allerlei verschillende code dingen gebeuren. In het geval van een veld, bijvoorbeeld wat gebeurt in hemelsnaam, met de data als ik het invalideer. Ik heb tekst kunnen invullen. Ik heb productieve geboorte data kunnen invullen. Ik heb data in de toekomst toe gevoegd. Wat gebeurt er op het moment dat ik nu in één keer validatie ga toevoegen? Gaat al de data in de database dan verloren? Heb ik een upgrade script? Krijg de gebruiker nu een melding dat de data niet meer klopt. Dat soort dingen moet je over nadenken. En dat is een lastige. Dit is eentje waar je ervaring in zou op moeten doen. En als je dit echt een lastige vindt, ga daar samen met de developer doorheen. Of met iemand die hier heel veel verstand van heeft. Of vragen gebruiker die weten echt super veel. De vierde vraag is, is de buik voor de gebruikers opgelost? Het zal niet altijd het geval zijn. Wij gebruiken bijvoorbeeld GitHub voor onze issues. Waar alle issues ook komen staan. En we hebben een support help desk. En daar krijgen wij veel issues binnen.  Met alle edge cases, met plugins, met thema's, al dat soort dingen. Aan de hand daarvan kunnen wij vaak zeggen, oké, dat is opgelost voor al die klanten. En als een hele grote bug is, dan kunnen wij ook een proefversie draaien van de plugin. En die aan de klant geeft, zodat de klant ook kan testen. Als dit kan, als het antwoord jij is of niet toepassbaar, dan ga je naar vraag vijf. En heb je er een happy pass getest. En dit is dus, kan ik opnieuw verkeerde data ingeven? Kan ik opnieuw, wat gebeurt er met mijn votieve data? Krijg ik nu wel de juiste feedback. Wat gebeurt er als ik het formuleertje daaronder aanraak? Wat als ik het toch wil analyseren, als ik op de backknop druk? Al dat soort dingetjes, alles waarvan je verwacht. Dat een gebruiker het niet zou doen, doe dat. Want ik garandeer je dan een gebruiker dat wel gaat doen. Als je denkt, kan een gebruiker dit doen. Of je denkt, een gebruiker mag dit niet doen. Dan betekent dat als je dat echt moet testen. Dan hebben we de hele overview. En ik heb het idee dat ik echt reed snel door de presentatie ben heen gegaan. Ja, hè? Of wat mee? Dit zijn de vijf punten. Houdt een begin testing. Heb je de bug kunnen reproduceren? Heb je kunnen veriveren dat de bug is opgelost? Heb je gerelateerde functionaliteit getest? Is de bug voor gebruikers opgelost? En heb je er een happy patch getest? Dat was niet zo heel erg, toch? Dat zijn vijf vragen die je kunt helpen als een gids. En je bent als developer bij jij een maker. En je bent echt een wereldbouwer. En niemand wil in een gat in de weg belanden. En continu horen dat je er maar overheen moet stappen. Of er maar omheen moet stappen. Of het maar moet negeren. Of het gewoon moet accepteren. Je wil gewoon dat dat gat gerepareerd wordt. En wij beïnvloeden het humeur van onze gebruikers en onze collega's met onze code. Laat we voor ook zorgen dat dit een positief gevoel is. En laten we dan ook vooral alles stukmaken. Maar maak het wel beter alsjeblieft. Dank je wel. Ja, ik voeg me af. Dit gaat echt over het project testen. Nu voeten we ook aan usability testen.  En hoe doe je dat dan, zeg maar, in één gevoel? Hoe doe je dat apart? De vraag is of wij ook aan usability testen doen. En of wij dat dan eigenlijk in zo'n geheel doen of we dat nog apart hebben. Wij hebben een apart team die ontwikkeld voor usability die daarover nadenkt. En we hebben natuurlijk 8 miljoen gebruikers die ook heel erg goed kunnen aangeven wat werkt en wat niet werkt. Wij hebben ook collega's in dienst die hier volledig op gespecialiseerd zijn op usability en op accessibility. Wij gebruiken hun kennis ook heel erg. Eén keer in dezelfde tijd hebben we een input-sessie met het hele kantoor. En dan zal ook het hele kantoor... We hebben mensen die de plugin helemaal niet gebruiken die voor het eerst in de plugin kijken. En heel interessante dingen zien om juist op die manier de boel te verbeteren. Dus we zijn continu op zoek naar wat kan beter en op welke manier. Als tester zelf ziet je vaak zo diep erin dat het lastig is voordat je ziet waar het fout gaat. Ze proberen dat op andere manieren te signaleren. Ja. Ja. Ja, ik denk dat het zo weinig wordt. Maar het stond voor mij daar. Ik heb het bij mij ervangend als je het test en een bepaalde bug dat test je alles op die buggen in. Zo moet je eigenlijk alles studeren maar er valt altijd iets op de complete aan de andere kant en dan bedacht je dat je gaat zo ontvallen. De enige manier om dan tot te testen van een nieuwe feature om naar te gaan is de eigen zeteling moet je de product weer gaan testen. Dus alle testcreates weer worden van de hele product om echt zeker te zijn dat alles weer werkt. Ja. Heb je daar tips voor op de zichtmiljoon? Dat is al het eerst keer heel veel werk. Ja. Moet je daar een goede test zien maken want dat is je niet. De vraag is dus wat test je wel qua grenzen als je de feature aan die kant maakt van het product dan valt er waarschijnlijk wel iets aan die kant om. Ik snap het. Wij hebben het ook inderdaad gezien bij de plugin als tester. Ik fixe het gewoon.  Maar ik kan gewoon voorstellen als developer dat je niet altijd die impact snapt en dan zou je inderdaad echt het hele product opnieuw moeten testen. En dat is ook wat er bij ons is gebeurd. Dat is waarom wij dus meerdere testers hebben. Elke release hebben wij een stuk of 4 of 5 en dat is ook de reden waarom wij langzaam overstappen naar geautomatiseerde testen. Wij hebben een lijst met wat wij op dit moment alle belangrijkste features vinden wat absoluut niet kapot mag gaan dat het echt hoge impact heeft voor je website. En dat moet altijd goed zijn. Als daar een bug in is dan moet dat direct gezien worden. En op die manier als je geautomatiseerd gaat testen dan zou je zien dat uiteindelijk je veel meer tijd bespaart maar na een paar weken merk je vaak al wel het verschil met zelf testen. Ja. We hoeven jullie ook aan testen van de toegankelijkheid van de website. Bijvoorbeeld voor mensen die blind zijn ze kunnen niet met een muis werken kan de de heen nemen via een toetsenbord kan. Ja. De vraag is wat doen wij eigenlijk aan accessibility voor mensen met een beperking bijvoorbeeld een visuele beperking. Ook met de toetsenbord alleen maar kunnen navigeren door de website. Dat doen we. We hebben meerdere trainingen ook gehad hierover. En we hebben sowieso ook mensen in dienst die hier ook altijd heel erg mee bezig zijn. En dan kijk ik ook heel even mijn collega Michiel aan want hij weet daar veel meer vanaf wat wij doen op dat gebied of het gebied van accessibility voor mensen met een beperking op onze website. Een website met software eigenlijk waar wij gewoon doen. En dan heb je heel veel actie dingen als fontgroot en ook kleurcontrast. Ja. Voor iedereen wij letten dus heel erg op kleurcontrast ook en op de toegankelijkheid. Dus dan zijn we absoluut mee bezig. Zijn er verder nog vragen? Ja. Wat was de naam van de toer die voor jullie gebruikt voor de algemeten? Codecept, yes. Codecept Codecept Codecept Heb je er nog vragen? Ik heb eigenlijk nog wel een vraag. Ja, jij was code sloper, zeg maar. En jij hebt dus mensen die dingen bouwen. Hoe blijf je nou, zeg maar. Ik kan me best wel voorstellen dat we er af en toe denken, hallo. 