Stapje voor stapje komen we dichterbij het klassieke toekomstbeeld van vliegende auto’s en robothulpjes. Zelfrijdende auto’s bestaan al, we kunnen praten met een assistent in onze telefoon en als we muziek willen luisteren krijgen we een uitgebreide lijst met suggesties die bij onze smaak passen. Maar achter veel van deze ontwikkelingen zit software, gemaakt door mensen. Wie test dit? En hoe test je dit? Dit waren de centrale vragen tijdens de Test Automation Day op 21 juli in Rotterdam. De Test Automation Day werd dit jaar voor de achtste keer georganiseerd. Hoofdthema is natuurlijk testautomatisering, maar wat deze conferentie bijzonder maakt, is dat de sprekers altijd net een stukje verder kijken. Zo is er niet alleen aandacht voor het hoe, maar ook voor het waarom van het testen. Hiervoor trekken ze internationale sprekers aan met kennis van de cutting edge van testing.

The (im)possibilities of Test Automation

Het thema dit jaar was To automate or not to automate, is that a question? The (im)possibilities of Test Automation. Aan de ene kant kregen we veel te horen over het testen van en met nieuwe technieken, zoals artificial intelligence (AI) en machine learning. Maar er was ook aandacht voor het testautomatiseringsproces zoals we het nu al een aantal jaren toepassen. Voor dit event waren er maar liefst vier keynotesprekers ingevlogen en waren er in totaal zestien presentaties over echte ervaringen, onderzoeken en inspirerende ideeën.

Na een volle dag met presentaties kwam ik met veel ideeën thuis. Ideeën die ik direct kan toepassen in mijn eigen werk, maar ook interessante gedachtes over de toekomst en bijvoorbeeld de ethiek in het testen. Graag deel ik wat van die ideeën met jullie.

AI testen

Ongemerkt komt artificial intelligence steeds dichterbij. Afhankelijk van de definitie die je hanteert, zou je al kunnen stellen dat AI al een feit is. Allemaal leuk en aardig, maar hoe test je een AI? Of, wat simpeler en misschien wat realistischer voor ons gesteld: hoe test je een systeem dat zich aanpast aan de hand van machine learning? Bijvoorbeeld een systeem dat koopgedrag voorspelt en daar reclame op afstemt, zoals Angie Jones (nu werkzaam bij Twitter) ooit in haar carrière moest testen. Maar bij een machine learning-systeem is het uiteindelijke resultaat van het proces niet gedefinieerd. Je kunt niet zeggen dat het systeem als je Y, X en Z doet, advertentie A, B en C laat zien. Er zijn alleen maar vrij algemene prognoses en verwachtingen. Daar kun je geen nette assertion voor maken in je automatische test.

Kun je dan eigenlijk wel automatisch testen? Jazeker, want je moet tijdens je test de machine laten leren, om te kunnen constateren of het leren goed is gebeurd. In haar voorbeeld liet Angie zien dat automatisch testen hiervoor een vereiste is. Zij moest duizenden transacties uitvoeren om het systeem bepaalde acties aan te leren. Daarna moest zij weer duizenden transacties uitvoeren om te bepalen of het inmiddels ingeleerde systeem naar behoren reageerde zoals goed leek. En wat bleek? Het systeem leerde wel, maar het resultaat was toch niet goed. Ook al waren er geen exacte correcte percentages gedefinieerd, toch was duidelijk dat het systeem een fout bevatte. Deze bevinding werd gedaan door de tijd te nemen om het systeem te laten leren, en daarna het geleerde te laten toepassen. Daarnaast was het resultaat niet van tevoren vast te leggen in een assertion. De bevinding was het resultaat van de beoordeling en beschrijving van de tester. Er is dus, zelfs in deze helemaal geautomatiseerde test, nog steeds plaats voor een menselijke tester.

Waarom moeten we die AI en machines zo goed testen?

Angie Jones had een heel treffend voorbeeld dat ik niet snel zal vergeten. Het was een combinatie van het trolleyprobleem, een gedachte-experiment dat nu heel actueel is met de opkomst van autonome vervoersmiddelen (via Paul Fenwick op Oscon 2017). Het komt erop neer dat er een keuze gemaakt moet worden tussen het redden van twee personen. Wie kies je, ethisch gezien? Angie versimpelde het: als je zou moeten kiezen tussen het aanrijden van een dier (met dodelijk gevolg) of de bestuurder laten verongelukken, wat kies je dan? Eigenlijk iedereen in de zaal koos ervoor om het dier te laten sterven. Daarna liet ze de fotoherkenningssoftware van Google zien, zoals gebruikt in Google Photos. Deze software herkent voorwerpen, dieren, gebeurtenissen en mensen. Het is niet vergezocht dat vergelijkbare software in een autonoom voertuig wordt ingebouwd om mensen te onderscheiden van dieren en voorwerpen. Ware het niet dat in 2015 bleek dat Google Photos soms donkere mensen aanmerkt als ‘gorilla’. Een dier. Als we dan onze voorgaande keuze voor het laten sterven van het dier erbij pakken, wordt al heel snel duidelijk waarom we dit soort algoritmes heel goed moeten testen. Overigens, de oplossing van Google voor dit probleem was heel simpel. Ze ‘herkennen’ gewoon geen enkele aapachtige meer in hun systeem. Probleem opgelost?

De mens overbodig als tester?

Testen van AI en machine learning is dus nog steeds nodig. Maar met machine learning en AI kunnen ook testen gemaakt en uitgevoerd worden. Zijn wij menselijke testers dan nog wel nodig? Niks zo faalbaar als de mens, toch? Gelukkig had Ilari Henrik Aegerter, directeur van House of Test, daar een goede (en zeer humoristische) reactie op. Na een geweldig toekomstbeeld waarin AI’s het overnemen van ons, werd het al snel serieuzer. Hij zette AI en mensen tegenover elkaar in het proces en gaf aan dat wij nog steeds nodig zijn. Software is immers gemaakt door en voor mensen, en wij zijn dus een integraal en onvervangbaar onderdeel hiervan. En hoe bepaal je bijvoorbeeld goede dekking? Goede dekking is altijd een beladen term, populair bij managers, minder populair bij ontwikkelaars en testers. En waarom? Omdat je de dekking altijd bepaalt aan de hand van een model van de software, en nooit aan de hand van de software zelf. En daarom is dekking altijd een onzekere term, die niet bruikbaar is, in ieder geval niet zoals deze nu gebruikt wordt.

Allemaal leuk en aardig natuurlijk die ervaringen met machine learning en die gedachte-experimenten over het testen van en met AI. Maar niet velen van ons zullen daar nu echt al iets aan hebben. Gelukkig was een groot deel van de dag gevuld met praktische presentaties, waarvan ik er graag enkele uitlicht.

Bijwerkingen

Amy Philips van Moo vertelde over de ‘bijwerkingen’ van automatisch testen. Over flakey tests bijvoorbeeld, iets wat we allemaal wel eens zijn tegengekomen. Hoevelen van ons herstarten de test dan niet gewoon nog eens, of negeren het flakey resultaat? We weten allemaal dat het niet goed is, maar ja, tijdsdruk… Amy benadrukte nog eens dat we flakey tests echt niet moeten accepteren. Want hoe weet je dat de gefaalde tests falen vanwege een flakey test en niet een echte fout? En waarom zou je nog waarde hechten aan de overige testresultaten als je er een paar al negeert? Haar advies, analyseer en fix die flakey tests! Daarnaast had ze het over het proces van testautomatisering, waarin een team enthousiast begint met automatiseren, alles automatiseert en alles op rolletjes loopt. En dan… Het onderhouden van de tests kost teveel tijd. De resultaten zijn niet betrouwbaar. Fouten glippen er toch door heen. Dan wordt het tijd om eens kritisch naar je tests en aanpak te kijken (liever natuurlijk voordat je begint). Het probleem is vaak dat er getest wordt op niet-kritieke features, dat tests elkaar overlappen of zelfs dupliceren en dat vaak de hele applicatie (full-stack) wordt getest. Automatiseer alleen de tests die er echt toedoen, en denk hierbij goed na over je aanpak.

Opruimen

Een andere interessante presentatie, vooral vanwege de invalshoek, was de presentatie van Rick Tracy over de Tidy Tester. Hij gebruikte de beroemde Konmari-opruimmethode van Marie Kondo om zijn tests en testproces op te ruimen. Verhelderend en iets wat zeker zinvol kan zijn voor ieder project dat al een tijdje loopt. Na een analyse van je tests en je proces kom je tot het opruimen. Eigenlijk gooi je virtueel alles op een grote hoop, daarna ga je sorteren en kent ook een waarde toe. Zelf leerde ik dat het niet erg is om iets op ruimen wat je misschien in de toekomst nog zou kunnen gebruiken. Opslaan kost misschien niet zoveel geld, maar wel energie. Daarnaast moeten we niet alleen dingen bewaren die waardevol en heel goed zijn. Ook de tests die simpele dingen automatiseren (regelmatig herstarten, inloggen, controleren of iets up is) zijn om een andere reden waardevol. Kijk ook naar hoe vaak zaken gebruikt worden. Een test die maar eens per jaar uitgevoerd wordt, moet je die wel bewaren? Vergt die niet juist veel onderhoud, en is het handmatig testen dan niet beter? Na het opruimen is het van belang deze nieuwe structuur te blijven handhaven en periodiek (dagelijks of wekelijks) op te blijven ruimen. Een goed vergelijking is die van Marie Kondo zelf, om elke dag je tas te openen en op te ruimen. Doe dit ook met je werk en dan blijft het netjes.

Er waren ook enkele demonstraties en beschrijvingen van hoe AI en machine learning ons kunnen helpen met testen. Zo kan machine learning gebruikt worden om testen te maken. Denk aan een site met een vaste structuur maar veranderende content, zoals een nieuwswebsite. De computer kan door vele iteraties van de voorpagina te bekijken zien wat de vaste structuur is, en wat veranderende content is. Dit kan meegenomen worden in een test die bevestigt of de structuur nog steeds hetzelfde is. Ook zou AI het gedrag van gebruikers kunnen voorspellen en op basis daarvan tests kunnen schrijven. Echter, daarbij hou ik toch altijd de presentatie van Ilari (zie hierboven) in het achterhoofd, dat software gemaakt is voor en door mensen, en dat wij als menselijke testers toch altijd een uniek perspectief hebben.

Zoals je hebt gelezen was de Test Automation Day voor mij een inspirerende dag. Niet alleen heb ik enkele praktische handvaten gekregen over hoe ik mijn werk beter of anders kan doen, ik heb ook een kijkje mogen nemen in de toekomst van het testen, en de leuke en interessante vraagstukken die nog op mijn pad zullen komen. En dat is precies het mooie van het bezoeken van een conferentie zoals de Test Automation Day. Je spreekt collega’s van andere bedrijven, je hoort hele nieuwe dingen en andere invalshoeken en door een dagje achter je bureau vandaan te komen, raak je weer vol van inspiratie. Alleen daarom al is het bezoeken van zo’n conferentie meer dan de moeite waard.