Functionele testen die je via de GUI uitvoert automatiseren; dat zal veel testers als muziek in de oren klinken! De handmatige testen zijn de laatste hindernis voordat het naar productie kan en word ook nog regelmatig gezien als bottleneck in het proces.. Het is dus ook niet raar dat er al snel aan het automatiseren van deze GUI testen gedacht word. Deze testlaag automatiseren heeft nog wel wat valkuilen en die wil ik hier graag met je delen. # 🤖 Misvattingen over test automatisering ❌ **Door testautomatisering maak je tijdswinst of kan je minder testers inhuren.** Test automatisering is een project op zich, er zit veel tijd in het bouwen, analyseren van de resultaten en onderhouden van de testen. Zolang het SUT veranderd heeft het impact op de automatische testen ❌ **Testautomatisering is vervanging van handmatig testen.** Testautomatisering is een tool, een hulpmiddel om handmatig testen te ondersteunen. Een robot beoordeeld datgene wat hem verteld is, een mens zal altijd meer meenemen in de beoordeling en zal daarmee altijd meer potentiele bugs kunnen vinden. ❌ **Als het eenmaal staat ben je klaar** [[Pesticide paradox]]: ”If you repeat the same test over and over, the test will eventually fail to find new defects.”. Om deze "pesticide paradox" te overwinnen, moeten testgevallen regelmatig worden gereviewd en bijgewerkt, en moeten nieuwe en verschillende tests worden geschreven om verschillende delen van de software of het systeem te testen om potentieel meer defecten te vinden. ❌ **Test automatisering is alleen de taak van een tester** Je bouwt als team aan een product en je bouwt ook met elkaar aan het vertrouwen in het product. # 🤖 Wanneer komt test automatisering het best tot zijn recht? - Test automatisering komt eigenlijk het best tot zijn recht als het gaat om **[[Load Testing|load]]-, [[Stress Testing|stess]]-, [[Unit Testing|unit]] en [[integratie testen]]**. Deze testen zijn handmatig niet of slecht uit te voeren. - Ook testen die veelvuldig herhaald moeten worden zijn geschikt; zoals je **[[Regressie test]]**. ## Testsoorten Voor wie bekend is met software testen kent [Het V-Model](craftdocs://open?blockId=45A84203-1C9C-4C84-BD65-D42CD50A9D4A&spaceId=2154107e-b0ee-4453-f8fd-57edcda10041) waarschijnlijk wel. Deze beschrijft verschillende testsoorten. In het agile landschap is het niet meer altijd zo scherp maar over het algemeen zie je de fasen nog wel terug. Elke fase heeft een ander doel. De fasen vullen elkaar aan en zorgen voor een goede [[Testdekking]]. Voor testautomatisering is dat niet anders. ![[Pasted image 20240731181916.png]] *Het V-Model* ## De Testpiramide De vertaling naar test automatiseren heeft de vorm van een piramide gekregen: ![[Pasted image 20240731181946.png]] *Test automatiseringspiramide* De test automatisering piramide is een vertaling van de testsoorten naar een beschrijving van 3 levels van testautomatisering, hun relatie en hun belang. Mike Cohn beschrijft het concept van deze piramide in zijn boek *Succeeding with Agile*. Hoe hoger in de piramide hoe de uitvoeringstijd, complexiteit en dus ook de kosten. Hoe lager, en breder, de laag in de piramide hoe meer testen er voor uitgevoerd kunnen worden voor minder tijd, hogere betrouwbaarheid. Alle lagen samen vullen elkaar aan en zorgen voor maximaal haalbare test dekking. **Wat valt op:** - Handmatig testen blijft onderdeel van het test proces! - [[Unit Testing]] nemen de meeste ruimte in en GUI de minste Lees meer inhoudelijk over de lagen van de piramide: [[Test Automatisering Piramide]] ## In de praktijk een ijshoorntje In de praktijk is de piramide vaak meer een ijshoorntje: ![[Pasted image 20240731185137.png]] Dit komt m.i. omdat de manuele testen de laatste actie van het ontwikkelproces is en het meest last heeft van tijdsdruk, de bij testers welbekende **[[Testsqueeze]]**. De tester voelt de noodzaak voor automatisering het meest omdat de handmatige testen onwijs veel werk kosten. Wanneer unit en integratie testen niet op orde zijn zal de tester dit nog extra merken omdat dit dan ook middels handmatige acties wordt gecontroleerd. Gevolg: tester gaat automatiseren en automatiseert meer dan nodig is via de weg die hij kent; de GUI. Wie er nog meer last heft van de tijd van testen? De budgethouder; die wil efficiënter (lees; goedkoper) werken en heeft gehoord van testautomatisering.. Op deze manier wordt ook de tester aangemoedigd de grootste tijdvreter de automatiseren; handmatige testen en regressietesten. > **Test automatisering bied het meeste meerwaarde als elke laag elkaar aanvult** ## Ter lering en vermaak Dit zijn een aantal sprekende voorbeelden van missende [[integratie testen]]:     # 🤖 GUI testen zijn de meest complexe testen om te automatiseren Zoals je kan zien in de test automatisering piramide wil je eigenlijk zo min mogelijk GUI testen ten opzichte van de andere [[Testvormen]]. Op de pagina GUI tests kan je lezen waarom GUI testen complex zijn op technisch vlak; Er zijn veel afhankelijkheden in het systeem landschap maar vergeet ook niet je computer zelf, de browser(versie), internet verbinding etc. Bedenk je ook, een robot kan niet… - Beoordelen of iets er **goed**/**mooi** uitziet - **[[Usability testen]]** Een robot is geen mens - **[[Exploratief Testen]]** Een robot kan niet experimenteren > [!danger] De robot is zo slim als jij hem maakt. > Maar let op; hoe complexer je hem maakt hoe onderhoudsgevoeliger hij wordt. > Wie test eigenlijk het testautomatiserings project? 🧐 **Voorbeeld**: Ik verwacht een bepaalde button op deze pagina. De computer kan niks zeggen of de plek van de button logisch is, misschien zit er ineens een afbeelding voor of staat hij onderin in plaats van netjes uitgelijnd. Dit kan een robot tot op zekere hoogte maar dit zal mensenwerk blijven. 🧐 **Voorbeeld**: Een website laadt a-synchroon, stukje voor stukje en om dit aan te duiden komt er soms een loader in beeld. Als gebruiker wacht je netjes. De computer moet je vertellen dat als er een loader in beeld komt je moet wachten. Voor de computer is NIKS vanzelfsprekend. 🧐 **voorbeeld:** Robot moest controleren of er een specifieke tekst aanwezig is. Check! Toch krijg ik klachten van gebruikers; “de tekst is weg en krijg hem niet terug!!” ik begreep er even niks van… Toen ik zelf ging kijken bleek dat de tekst er wel was, maar hij was wit op een witte achtergrond! Als automatiseerder moet je je kritisch blijven; is het zo belangrijk dat je ook kleuren wil gaan controleren? Dat kan, maar stel je controleert de kleur van de achtergrond en de kleur van de voorgrond en deze zou niet gelijk moeten zijn. Maar op goed moment bepaald een content manager dat de achtergrond een fade krijgt, of een afbeelding wordt. Dan moet je je testen weer gaan aanpassen. Is dat het waard? ## Wat test je niet via de GUI - **Alles wat je als integratie of unittest had kunnen testen** - **Eenmalige testen** Als je het normal ook niet vaker dan 1 keer zou testen, dan hoef je het ook niet te automatiseren. - **Net nieuwe features** Automatiseer iets wanneer het stabiel is. Natuurlijk kun je vast beginnen met bouwen maar investeer pas echt tijd in de bouw als je exact weet wat er verwacht wordt. - **Complexe business rules (bijvoorbeeld berekeningen)** Dit doe je beter via API’s bijvoorbeeld. Weet jij nog meer voorbeelden? ## Wat test je wél via de GUI Zo min mogelijk! - Zorg dat GUI testen een aanvulling is op de unit en integratietesten om het plaatje compleet te maken. - Test via de GUI de GUI - Test de belangrijke flows met een hoog risico / business value. Een product risico analyse kan helpen bij het bepalen wat je gaat automatiseren. In de praktijk betekend het dat je testset op dit niveau heel minimaal zal zijn