Auteur: John Kronenberg ● john.kronenberg@gmail.com
Redactie: Henk Johan Kwakkel
Een tijdje terug keek ik op YouTube een presentatie van Richard Bradshaw die hij op SeleniumConf in 2019 had gegeven. Je kunt de presentatie zelf hier bekijken. De titel van zijn presentatie was ‘Redefining Testautomation’ en waarschijnlijk heb ik deze presentatie gekeken vanwege deze interessante titel. Zelf heb ik de afgelopen jaren voor TestNet een drieluik geschreven over hoe ik de rol van testers en testautomatiseerders in ons vakgebied voor nu en in de toekomst zie (1), (2), (3) en ik zie in Richard Bradshaws presentatie heel veel parallellen met hoe ik naar testautomatisering kijk, voor nu en in de toekomst. Voor mij een reden om me in Richards werk te verdiepen. Graag geef ik jullie een introductie in Richard Bradshaws gedachtengoed.
Persoonlijke noot
Zoals jullie in mijn vorige artikelen over testautomatisering kunnen lezen zie ik mezelf als Software Engineer in Test. Een beetje gechargeerd: ‘ik ben een ervaren tester, maar ik vind het automatiseren van testen toch leuker en uitdagender’. Wat mij echter opvalt, is dat mijn klant eigenlijk helemaal geen Software Engineer in Test zoekt, maar, wederom gechargeerd, ‘iemand die ook testen kan automatiseren, maar testen toch leuker en uitdagender vindt’. Ik ben dus veel van mijn tijd aan het testen. Tijd die ik niet kan (en hoef te) besteden aan testautomatisering. Mijn eerste reactie op bovenstaande is dat ik een andere verhouding testen versus testautomatisering in mijn rol zoek, ik vind testautomatiseren namelijk leuker en uitdagender. Na het verdiepen in het gedachtengoed van Richard Bradshaw begrijp ik beter dat als je echt als testprofessional het verschil wilt maken, de verhouding testen en testautomatisering dichter bij elkaar zou moeten liggen. Ik kan me wel vinden in de wijze waarop Rob van Steenbergen het onlangs in een interview op TestNetNieuws heeft verwoord: ‘De focus op testautomatisering (in de markt) is vrij heftig en een valkuil aan het worden’. Kan Automation In Testing (AiT) ons helpen deze focus te verleggen?
Automation in Testing
Wat bedoelt Richard Bradshaw met Automation in Testing? Op zijn site https://automationintesting.com staat het volgende: ‘Automation in Testing (AiT) is a mindset and namespace that promotes human-centric automation within the context of testing’. Ik lees hierin dat testautomatisering ondersteunend moet zijn aan het testproces en dat de mens (lees: de tester) in het automatiseringsproces centraal moet staan.
Automation in Testing kent de volgende zes principes:
Supporting testing over replicating testing
Testability over automatability
Testing expertise over coding expertise
Problems over tools
Focusing on risk over coverage
Observability over understanding
De principes zijn behoorlijk zelf-verklarend. De focus van de principes ligt overduidelijk bij het ondersteunen van het testen met testautomatisering in plaats van dat testautomatisering het vertrekpunt is. Dit is mijns inziens de kracht van AiT. Testen blijft onverminderd belangrijk. Testautomatisering staat naast testen en moet niet pogen het testen te vervangen.
Het is belangrijker om een testbare applicatie te hebben dan een automatiseerbare applicatie. Met andere woorden, het niet kunnen automatiseren van een testgeval is niet zo erg, als je het testgeval maar handmatig kunt uitvoeren. Voor mij een waarheid als een koe.
Testautomatiseerders moeten volgens Richard dus in de eerste plaats testers zijn. Het kunnen programmeren van bijvoorbeeld stepdefinitions in Java is natuurlijk gewenst, maar als de programmeerskills niet voldoende zijn om zelf zo’n stepdefinition uit te werken, kan een developer er altijd bij helpen of die taak geheel overnemen. Ik kan me daar wel goed in vinden. Al vind ik wel dat een Software Engineer In Test die beide vaardigheden goed beheerst, het schaap-met-de-vijf-poten dus, wel iets extra’s aan een project toevoegt.
‘Voor iemand met een hamer ziet alles eruit als een spijker’. Dat is het risico wat je loopt als je een testautomatiseringstool als vertrekpunt neemt om de testautomatiseringsuitdagingen van een project op te lossen. Testautomatisering moet maatwerk zijn. Er moet een framework / tool gekozen worden op basis van de uitdagingen die specifiek zijn voor het project waar je een framework voor op wil zetten. Trap niet in de valkuil dat je de tool centraal stelt. Maak keuzes op basis van de projectproblemen.
Testen gaat over het dekken van risico’s, vanuit de gedachte dat je nooit voldoende tijd en middelen hebt om je hele applicatie te dekken. In de praktijk wordt te vaak door opdrachtgevers de vraag gesteld om alle testgevallen te automatiseren. Hierdoor hebben veel projecten een hoge graad van testautomatisering, maar niet noodzakelijkerwijs de belangrijkste risico’s afgedekt. Zonde.
Ik kan me ook wel vinden in het statement van Richard dat de applicatie volledig doorgronden minder relevant is dan het kunnen observeren en exploreren van de applicatie.
Conclusie
Op zichzelf is Automation in Testing niet nieuw natuurlijk. Het is een goed tegenwicht voor de wens van opdrachtgevers om alle testgevallen te automatiseren. Het kan als testprofessional geen kwaad de principes van AiT regelmatig te bekijken. Softwaretesten is niet dood. Het is net zo belangrijk als in de jaren dat testautomatisering nog niet zo grootschalig ingezet werd. Mooi om dat in AiT terug te lezen.
Goed en duidelijk verhaal John!
Het spanningsveld is herkenbaar maar er valt veel te zeggen voor Software Engineers in Test binnen een organisatie. Let wel: binnen een organisatie, niet persé binnen een (Agile) team.
Test automation is een development discipline, geen test discipline. Ook is gedegen product-kennis voor het opzetten / onderhouden van een geautomatiseerde test infrastructuur niet noodzakelijk (voor het goed testen van het product wel!).
Wat wel noodzakelijk is, is kennis van de automation tools (incl. CI/CD!) en programmeertalen die gebruikt worden…tools en talen die vaak niet dezelfde zijn als die voor implementatie van het product gebruikt worden.
Zie daar het gat: als je in zo’n situatie de test automation gaat laten doen door de devs die het product maken, is de kans groot op een custom test automation oplossing gebaseerd op het unit-test framework dat voor product-code gebruikt wordt. Ook daar een groot risico op “iemand met een hamer”. En dit gebeurt op heel grote schaal: Protractor wordt toch aardig veel gebruikt voor functionele testen / flows op websites…maar het is in de basis een unit test framework wat hiervoor dus eigenlijk helemaal niet zo geschikt is!
“Het is belangrijker om een testbare applicatie te hebben dan een automatiseerbare applicatie. Met andere woorden, het niet kunnen automatiseren van een testgeval is niet zo erg, als je het testgeval maar handmatig kunt uitvoeren. Voor mij een waarheid als een koe.”
Hier zou ik toch een randvoorwaarde willen stellen: “als je alle testgeval maar binnen een acceptabele tijd (=budget) uit kan voeren”. Ik ken geautomatiseerde suites die zo’n uur draaien. Een mens kan die testen ook allemaal handmatig uitvoeren…maar zeker niet binnen een normale 8-urige werkdag. De applicatie is dus testbaar, maar als die niet automatiseerbaar zou zijn, is er toch echt een probleem. Testbaarheid en automatiseerbaarheid zijn soms hetzelfde.
Ook bij meer technische testen is het verschil vaak klein / afwezig. Neem een REST API waar een OpenAPI specificatie voor is. Voldoet de API volledig aan de specificatie? Natuurlijk kun je dit zonder automation framework valideren (OpenAPI document is ‘human readable’ en met tools als Insomnia, Postman, etc. kun je de API calls wel maken)…maar hoe lang gaat dat wel niet duren?
Wat mij betreft zijn de uitgangspunten niet verkeerd, maar ze hebben wel hun beperkingen en je daar moet je je altijd bewust van blijven.