Auteur: John Kronenberg ● John.Kronenberg@closesure.nl
Inleiding
Op deze plek heb ik vorig jaar twee artikelen gepubliceerd. Na mijn eerste artikel, waar ik een lans brak voor de tester met voldoende technische bagage, heb ik een tweede artikel gewijd aan de rol die ik de afgelopen tijd bij mijn opdrachtgevers uitvoer: Software Engineer in Test. Een logisch vervolg op deze twee artikelen is om testautomatisering te beschouwen vanuit de positie van de developer. Meer en meer zie ik ‘in het veld’ dat developers de testautomatisering binnen projecten op zich nemen. Dit artikel geeft een antwoord of wij, testers of testautomatiseerders, dat als een bedreiging of als een kans zouden moeten zien.
Argumentatie
Laat ik maar direct mijn antwoord met jullie delen. Als developers de testautomatisering binnen onze projecten oppakken, dan is dat over het algemeen een zegen voor ons vakgebied. Voor deze stelling heb ik de volgende argumenten:
Het zet testers en developers in hun kracht.
In de voorgaande artikelen heb ik al aangegeven dat mijns inziens testautomatisering een vorm van softwareontwikkeling is. Over het algemeen zijn testautomatiseerders, ofwel Software Engineers in Test, meer developer dan dat ze tester zijn. Wat ik in de markt zie, is dat er in Nederland een schaarste is aan goede testautomatiseerders. Begrijp me niet verkeerd, er zijn voldoende goede technische testers in Nederland, maar veel van hen zijn niet goed in testautomatisering en/of willen eigenlijk niet testautomatiseren. Developers daarentegen hebben programmeren in hun DNA en, mits het testframework slim is gekozen, kunnen ze de testautomatiseringscomponenten in de programmeertaal waarop ze in het project al werken, ontwikkelen. Bij mijn huidige project is de testautomatisering opgezet in Cucumber, waarbij de step definitions in Java zijn ontwikkeld. Deze componenten hadden, bij mijn afwezigheid op het project, prima door de developers kunnen worden ontwikkeld. Dit schept dan weer ruimte voor de testers om te doen waar ze goed in zijn: De kwaliteit van de software aantonen.
Testautomatisering door developers ondersteunt het ‘whole team approach’.
De kracht van mijn huidige team is dat we kwalitatief goede software proberen te maken met elkaar. Als team kwamen we tot de conclusie dat we graag onze testen parallel wilden kunnen draaien in plaats van sequentieel. Het sequentieel draaien zorgde ervoor dat onze testen een doorlooptijd had van meer dan een uur. Hierdoor duurde het het team veel te lang voordat we een uitspraak konden doen over de kwaliteit van de opgeleverde software. Om parallelle testuitvoer mogelijk te maken moest naast een softwareaanpassing ook twee stepdefinitions aangepast worden. We hebben als team geconcludeerd dat deze aanpassingen in de stepdefinitions net zo goed door een developer gedaan kon worden. Nu onze developers ook hebben meegeholpen aan het opzetten van de testautomatisering merk ik dagelijks dat de testautomatiseringsoplossing ook door de developers gedragen wordt.
De kwaliteit van de testautomatisering is over het algemeen beter als de developer de testen heeft geautomatiseerd, dan als de tester de testen heeft geautomatiseerd.
Iedere tester die met testautomatisering bezig gaat, weet dat je als testautomatiseerder, in de programmeertaal waarin de testen worden geprogrammeerd, geen senior hoeft te zijn. De reden hiervoor is vrij simpel. Om bijvoorbeeld een GUI of een API te testautomatiseren hoef je relatief maar een klein gedeelte van de programmeertaal onder de knie te hebben. Terwijl je, om deze GUI of de API in deze programmeertaal te bouwen, je relatief veel kennis van de programmeertaal zult moeten hebben. Hier spelen aanbieders van boeken en cursussen over testautomatisering handig op in door bijvoorbeeld een ‘Java voor testers’ boek uit te brengen of een gelijknamige cursus aan te bieden. Bovenstaande beantwoordt zonder twijfel aan een onder testers aanwezige behoefte. Ik sta achter het uitgangspunt dat testers voldoende, maar niet noodzakelijkerwijs te veel kennis over de programmeertaal van de te gebruiken testtool hoeft te hebben. Dit heeft dan wel als bijeffect dat de testautomatisering niet een net zo’n goede kwaliteit zal hebben dan als de developer de testautomatisering heeft opgezet. De developer zal, met dezelfde principes als dat hij software ontwikkelt (bijvoorbeeld gebruikmakend van clean code principes) de testautomatisering opzetten. Hierdoor krijg je over het algemeen beter onderhoudbare en overdraagbare testautomatisering.
Conclusie
Ik concludeer dat het een kans voor het team is als de de developer helpt met de testautomatisering. Als je een Software Engineer in Test in het team hebt kun je hem/haar vanzelfsprekend verantwoordelijk maken voor het testautomatiseringsframework, maar dat neemt niet weg dat ook in zo’n teamopzet de developer zou moeten kunnen meehelpen met het ontwikkelen van testautomatiseringscomponenten. Zijn er alleen technische testers op het team aanwezig, dan is het een goed idee de developer(s) de verantwoordelijkheid voor het testautomatiseringsframework te geven. Testers hoeven dan niet de testautomatiseringscomponenten te ontwikkelen, maar kunnen ingezet worden voor het in bijvoorbeeld Cucumber ontwerpen van testscenario’s.