Blog:

Test Automation: niets voor een Software Engineer?!

Published on apr 17, 2019
By Jordy / Software Engineer

Het was 2 juli 2016, een heerlijke zomerse dag waarop mijn eerste Fourtress Zomerevent plaatsvond. Op dit Zomerevent pitchte Wouter Pol mij voor het eerst de opdracht van Test Automation bij Philips Digital & Computational Pathology. In eerste instantie was ik deels pessimistisch over het woord “Test” in de rolbeschrijving, maar al snel overtuigde Wouter me het tegendeel van deze misvatting. Test Automation, zoals de naam in eerste instantie misschien niet doet vermoeden, bestaat voor een zeer groot deel uit software development. Gedurende het gesprek werd ik al snel enthousiast over de opdrachtbeschrijving. Zeker door mijn achtergrond in de Frontend development en mijn ervaring met JavaScript.

Philips Digital & Computational Pathology
Philips Digital & Computational Pathology (DCP) is een afdeling van Philips op de campus in Best. Deze afdeling is gespecialiseerd in de ontwikkeling van een system ter ondersteuning van Pathologie, de studie naar het ontstaan van alle soorten ziekten. DCP focust in dit gebied voornamelijk op het ontstaan van kanker. Onderzoek naar deze ziekte is en blijft al jaren een complexe taak. Philips ondersteunt hierbij door de introductie de Pathology Suite en de Collaboration Suite. In dit blog ga ik vooral in op mijn ervaringen als Software Engineer in de Test Automation bij het testen van deze applicaties. Daarnaast probeer ik jullie te overtuigen van mijn mening dat Test Automation een must is voor iedere Software Engineer.

Test Automation op applicatie niveau
Gherkin
Software Engineers zijn doorgaans voornamelijk gewend om geautomatiseerde testen te schrijven op het niveau van unit- of integratie testen en minder op het niveau van applicatie testen. Voor mij was dit niet anders en ik ontdekte bij DCP dan ook al snel een hele nieuwe wereld op het gebied van test automatisering. De eerste stap bij de ontwikkeling van een test is de vertaling van een requirement van het systeem naar de test. Deze testen schrijven we in de “test taal” Gherkin, een standaard voor testen geschreven in een Given-When-Then formaat. Dit formaat wordt voornamelijk toegepast bij het schrijven van testen waar de nadruk ligt op Behaviour Driven Development. Het grootste voordeel van dit formaat is het feit dat de testen geschreven zijn in een verhaalvorm die ook te begrijpen is door personen met een minder technische achtergrond. Neem als voorbeeld het volgende voorbeeld van een eenvoudige test geschreven in Gherkin:

Given I am on the login page
When I log in with username Jordy and password Welkom123
Then I am on the home page

Cucumber, Protractor en Selenium
Nu denk je waarschijnlijk: heel leuk zo’n test, maar wat nu? Dit is het onderdeel waar de development toegepast wordt. Voor de koppeling van test naar code wordt gebruik gemaakt van het test framework Cucumber. Cucumber maakt gebruik van reguliere expressies om testen de koppelen aan de code van de test stap. Dit klinkt misschien vaag, daarom hier onder een voorbeeld van de code implementatie van de tweede stap in de test naar code geschreven in JavaScript.

When(/^I log in with username (\S+) and password (\S+)$/, function (username, password) {
        // Hier komt de implementatie
});

In dit voorbeeld matcht de reguliere expressie met de tweede stap in de test. Wanneer de test wordt uitgevoerd zal dan ook de deze logica uitgevoerd worden zodra de tweede stap in de test uitgevoerd wordt. Op deze manier kunnen alle regels in de test voorzien worden van code implementatie. Deze implementatie werd doorgaans geschreven in JavaScript met behulp van Protractor en Selenium. Deze tools maken het mogelijk om rechtstreeks te communiceren met de browser. Denk hierbij bijvoorbeeld aan het openen van een specifieke pagina, het indrukken van een knop of het invullen van een input veld met een gebruikersnaam of wachtwoord.

Nóg meer development
Het grootste deel van de werkzaamheden ligt bij de implementatie van deze test stappen. Hierdoor ben je als Test Automation Engineer voornamelijk bezig met software development en maar een klein deel van de tijd met het schrijven van de testen. Later betrokken we ook Test Engineers bij het schrijven van Gherkin testen, waardoor we ons als Test Automation Engineers volledig konden richten op de implementatie van de testen.

We zouden geen Software Engineers zijn als we niet constant opzoek zijn naar verbeteringen en nieuwe tools en technieken. Daarom heb ik gedurende mij carrière bij DCP de volledige codebase van het test framework voor de Collaboration Suite omgezet van JavaScript naar TypeScript. Een zeer grote uitdaging en een flinke boost voor de development ervaring op het gebied van TypeScript applicaties.

Deze en vele andere uitdagingen hebben me een grote stap verder gebracht in mijn ervaring als Software Engineer. Niet alleen op het gebied van Test Automation of testen in het algemeen, maar ook op het gebied van software development. In mijn huidige opdracht bij HSDP pluk ik daar nu ook de vruchten van bij de ontwikkeling van een applicatie geschreven in TypeScript.