Vorige week woensdag en donderdag (19 en 20 juni) werden de Test Automation Days gehouden. De eerste dag bestond uit twee workshops die elk drie uur duurden. Op tweede dag van de Test Automation Days werden vooral presentaties gehouden. Ik zal van drie van deze presentaties een samenvatting geven.
Keynote sessie: Balancing your test automation with exploratory testing – Mirjana Kolarov (Levi9 IT Services)
Kernboodschap is: geautomatiseerd testen is niet de vervanging van alle andere testen, exploratief testen blijft altijd nodig. Ze toont dit onder meer aan met een youtube filmpje van Daniel J. Simons ( https://www.youtube.com/watch?v=IGQmdoK_ZfY ): drie spelers in het wit en drie spelers in het zwart gooien elkaar de bal toe. Opdracht is: tel het aantal keer dat de witte spelers de bal overgegooid hebben. We verwachten dat dit 16x zal zijn.
Na het tonen van het filmpje blijkt dat de kleur van de achtergrond is aangepast tijdens het spel en ook dat er een zwarte gorilla door het scherm liep. En dat iemand van het zwarte team stopte met spelen. Voor de spreekster illustreert dit geautomatiseerd testen: doordat je super gefocussed bent op de uitkomst van iets wat je verwacht, zie je niet meer wat er daarnaast -ook- gebeurt (en mis gaat). Bij exploratief testen verwacht je het onverwachte. Daardoor ben je anders gefocussed.
Een ander voorbeeld: zij heeft iets in haar gedachten, wij moeten dit vanuit de zaal raden met ja/nee vragen. In totaal waren er vijf vragen nodig om er achter te komen dat ze haar hond in gedachten had. Dat dit zo snel kan, heeft ermee te maken dat je na de eerste vraag al heel veel mogelijkheden kunt uitsluiten. Dat is ook een voordeel van exploratief testen: je kunt afhankelijk van de uitkomst van eerdere testen besluiten welke kant je (extra) wilt bekijken. Het is wel belangrijk om aantekeningen te maken tijdens exploratief testen.
Bij de verschillende niveaus van testen (unit testen, integratie testen, systeem testen, end-to-end testen) is het belangrijk om overlap van testen te vermijden. De neiging bestaat soms om te veel end-to-end testen te doen, waarbij dezelfde test telkens opnieuw gedaan wordt. Dit zorgt ervoor dat testen lastig te onderhouden worden en te lang duren.
Bij eploratief testen is het wel belangrijk om te blijven nagaan wat er -wel- geautomatiseerd getest kan worden: regressietesten en smoke testen zijn bij uitstek geschikt om te automatiseren. Het is ook voor testers zelf vervelend om telkens dezelfde tests uit te voeren (en hier is de kans dan ook groot dat testen over het hoofd gezien worden als ze niet geautomatiseerd worden).
Functionele testen, performance testen, loadtesten, stress testen, security testen en bruikbaarheidstesten zijn bij uitstek exploratieve testen. Bij deze testen wordt overigens wel gebruik gemaakt van tools.
Regressietesten, smoke testen, data gedreven testen, load testen (deels), security testen (deels) en testen in een CI/CD straat zijn bij uitstek plekken waar geautomatiseerd getest wordt.
Gebruik geautomatiseerde testen om je geest te verruimen voor de exploratieve testen.
Wat me in dit soort verhalen vaak opvalt, zijn de geruststellende woorden dat “het vak van tester niet verandert”. Ook in deze presentatie werd genoemd dat programmeurs eerder hun baan zullen verliezen dan testers. Ik geloof hier niet zo in: ik denk dat bij het invoeren van Scrum en CI/CD de rol van beheerder meer in de richting van testers gaat. En dat testers, meer dan nu, ook de mensen zijn die geautomatiseerde testen zelf gaan invoeren (dus ook “code kloppen” om die geautomatiseerde testen te implementeren).
Keynote sessie: Cypress: continuous and confidence – Amir Rustamzadeh (Cypress.io) :
Hij begint de presentatie met heel veel cijfers:
* Het aantal teams dat niet werkt met geautomatiseerd testen is afgenomen van 26% in 2016 naar 11% in 2017.
* Het aantal teams dat Continuous Deployment doet was 11% in 2016, 16% in 2017
* Het aantal teams dat niet aan regressietesten doet was 48% in 2016, 41% in 2017
Testen is duidelijk “moeilijk”. Het is nodig om weerstand tegen het schrijven van testen tegen te gaan en sneller te testen om betere feedback loops te kunnen genereren. Er zijn stevige programmeervaardigheden nodig.
Ontwikkeling van UI testen: in 2005 kwamen frameworks voor web ontwikkeling op, bijvoorbeeld Ruby on Rails en Django. JQuery maakte het in 2006 makkelijker om vanuit websites databases te benaderen. De grote omschakeling kwam vanaf 2010 met de brede verspreiding van mobiele telefoons waar internet op mogelijk was. In die tijd kwam ook Angular React op, complexiteit verschoof van de server naar de front-end.
Het vreemde is, dat de manier van testen wel gelijk gebleven is, terwijl je in de programmatuur een verschuiving van stateless naar stateful applicaties ziet.
Cypress is een betrouwbare, gratis (MIT licentie) testtool. Het is makkelijk te installeren (“npm install cypress”) zonder voorafgaande configuratie van instellingen. Als na de installatie de windows-omgeving gestart wordt dan zijn direct voorbeelden beschikbaar van heel veel soorten testen.
Tijdens het uitvoeren van testen wordt bijgehouden hoe het scherm er bij elke stap uit zag, hierdoor is “tijdreizen” mogelijk en kan ook na afloop nog beoordeeld worden of er bijzonderheden waren in een afzonderlijke stap. Cypress kent ook een goede command-line interface (CLI).
Het grote verschil met Selenium is dat Selenium buiten de browser blijft, terwijl Cypress meekijkt met de events zoals die binnen het browserscherm afspelen. Ook kent Cypress een backend, die er bijvoorbeeld voor kan zorgen dat iemand ingelogd is in de applicatie (zonder dat hiervoor telkens de GUI gebruikt hoeft te worden, dit scheelt veel tijd). Ook kan de backend de database voorzien van testdata (bijvoorbeeld testusers).
Cypress wacht standaard maximaal 4 seconden totdat een verwacht object in de browser staat. Er zijn geen extra sleeps nodig (zoals bij Selenium).
Cypress kan ook gebruikt worden in CI/CD straten:
npx cypress run -> maakt een video van de tests, met extra
screenshots als er errors zijn
npx cypress run –record -> maakt cypress dashboard aan
npx cypress run –record –parallel -> voert tests parallel uit,
bijvoorbeeld als er 3 CI/CD servers in een
cluster draaien. Bepaalt zelf welke test op
welke node uitgevoerd moet worden op
basis van de doorlooptijd van eerder
uitgevoerde tests.
Features die nog in ontwikkeling zijn:
* test retries (bij flaky tests): probeer het maximaal 3x voordat geconstateerd wordt dat een test niet goed uitgevoerd is.
* volledig simuleren (stubben) van het netwerk
Break-out sessie: Securing your CI/CD pipeline – Jeroen Willemsen (Xebia)
Er zijn best veel plekken waar een CI/CD vatbaar is voor security issues:
– de eigen applicatiecode
– libraries van derden
– bad practices in de runtime environment
Dit geldt ook voor Docker containers:
– Base layer OS’en
– OpenSSL layer
– Bad practices in Kubernetes, Mesos/Marathon
– Slechte configuratie van Docker layers
– Security issues in het Host OS
Ook de code die door de pipeline gebuild, getest en uitgerold wordt is vatbaar voor security issues. Voorbeeld: de code van CCleaner is besmet geraakt doordat een hacker toegang tot de code base had.
Iedere productieomgeving (en daarmee: elke pipeline omgeving) heeft monitoring en alerting nodig. Denk aan applicatielogging, logs van container componenten, audit logs, OS logs, SSH logs, netwerk logging. Denk ook aan: controle of poorten in Docker open staan die niet open zouden moeten staan, of controle dat de pipelineomgeving niet buiten builds/tests om gebruikt wordt.
Er moet goed nagedacht worden over Identity and Access management (wie mag wat, ook t.a.v. het inchecken van code of het starten van een pipeline). Hoe ga je om met medewerkers die uit dienst gaan? Gebruik bij voorkeur een centrale identity store (zoals Active Directory). Denk ook aan multi-factor authentication en aan het vier-ogen principe.
T.a.v. secrets management: kijk ook naar AWS KWS, Azure Keyvault, HashiCorp Vault. Vernieuw regelmatig secrets.
Controleer op afhankelijkheden met de OWASP dependency checker. Je kunt ook duurdere oplossingen gebruiken, maar [1] controleer dan wel dat deze (minimaal) dezelfde dependencies constateert als de gratis tools en [2] controleer dat deze niet veel te veel constateren (false negatives).
Static code checking: er zijn tools op de markt, kijk of deze niet te duur zijn: soms kun je met grep al zaken afvangen (zowel grep op logfiles als grep op configuratie).
Dynamic analysis: er zijn gratis tools die best goed zijn, zoals OWASP Zed Attack Proxy (ZAP).
Let ook op Docker layers: als een vulnerability van de ene laag wordt opgelost in een hogere laag ziet de dependency checker dit niet altijd. Het blijft belangrijk om zelf na te denken. Goede tools: Clair, Anchore. Evt. ook Docker Hub.
Een deel van deze tests vragen (heel) veel tijd. Misschien een optie om de standaard regressietesten direct na het inchecken te doen en de security checks elke nacht?
Meer lezen? Kijk op de site van de OWASP: https://www.owasp.org/index.php/Main_Page
Foto’s en afbeeldingen:
1e foto: http://www.testautomationday.nl
Afbeelding piramide: https://watirmelon.blog/testing-pyramids/
2e foto: Frederique Retsema
