ING

Bij ING werk ik momenteel aan de E2E-test voor de ING scanner. Deze ING scanner vervangt op den duur TAN-sms/TAN-lijst als bevestigingsmethode voor (betaal)opdrachten/inloggen. Het project wordt uitgevoerd door veel verschillende teams op verschillende locaties. Zij bouwen/updaten allemaal hun eigen stukje software in de keten. Uiteindelijk komt alles voor de eerste keer in zijn geheel samen voor de E2E-test. Het is mijn opdracht om de E2E-test voor te bereiden, uit te voeren en waar mogelijk te automatiseren.

Aangezien een E2E-test toch net iets anders is dan een gewone functionele test heb ik als voorbereiding mezelf eerst een refresh gegeven op het gebied van E2E-testen door mezelf in te lezen. Hierbij stuitte ik op het document “Polteq-Praktijkgerichte-Aanpak-voor-E2E-testen”. Deze instructie heb ik vervolgens als leidraad gevolgd bij het opzetten van de E2E-test. De instructie is niet 1 op 1 overgenomen, maar meer als een soort gereedschapkist gebruikt, waarbij we alle relevante tools gebruikt hebben.

Ik ben begonnen met het opknippen van de E2E-test in de E2E-processen, dit zijn de hoofdprocessen waaruit de keten bestaat. Vervolgens ben ik als 2de stap een E2E-inventarisatie uit gaan voeren. Hierbij neem je alle kennis die er is van het proces op om tot Actoren, Stappen, Beslissende factoren, Kritische factoren en Resultaten te komen. Dit was voor mij meteen een goed leermoment om het project te gaan begrijpen en wat hierbij allemaal kwam kijken.

De 3de stap die ik heb uitgevoerd was met de verschillende teams om tafel te gaan zitten om per proces een PRA uit te voeren. Hierbij hebben we ook gekeken naar de testgevallen/resultaten die eerdere testfases hebben opgeleverd. 

Aan de hand van de informatie die dit gezamenlijk heeft opgeleverd heb ik vervolgens een test strategie uitgestippeld. Ik heb alle data vastgelegd in een test matrix (zelf noem ik het altijd uitgebreide Data Combinatie Test). Hierin staan de logische testgevallen aangegeven, met prioriteit, risico, executietijd en benodigde test data.

De vervolg stap was het kijken of alle test data voorhanden was of dat deze gecreeerd kon worden. Tot slot hebben we gekeken welke test cases er geautomatiseerd moesten/konden worden. We hebben hierbij onder andere in ogenschouw genomen of de test case vaker gebruikt gaat worden, effort om de test case te maken en stabiliteit van de test case.

KNAB

Bij Knab was ik verantwoordelijk voor het testproces voor zowel Android als iOS. Vanaf het moment dat we wilden starten met het opzetten van een test automation framewerk voor iOS bleek het bestaande framework niet aan de verwachtingen te voldoen. Ik heb toen het voortouw genomen een nieuwe teststrategie op te zetten voor beide platformen. Het doel hierbij was om volledig over te gaan van handmatig naar geautomatiseerd testen, waarbij iedereen in het team een rol heeft bij het realiseren van de testdoelen. Hiervoor hebben we verschillende proof of concepts uitgevoerd om tot het juiste automation framework te komen. 

http://Array

Uiteindelijk zijn we voor een native oplossing gegaan voor Android (Android Studio, Java) en iOS (Xcode, Swift). Hierboven een deel van de test die een Android ontwikkelaar en ik uiteindelijk gezamenlijk hebben opgezet. Mooie aan deze tests was dat iedere test zowel mocked als tegen de echte backend te runnen was. Aangezien alle code van de app en het automation framework in hetzelfde project zat, ontstond er een mooie joint effort op het gebied van testen. Ik was verantwoordelijk voor het toevoegen van nieuwe functionaliteiten en de ontwikkelaars waren verantwoordelijk voor het onderhouden van de bestaande testcases.