In gesprek met Gerard Numan

Sinds begin van dit jaar is er een interessant boek aan het verschijnen over End to End (E2E) testen. Aan het verschijnen? Ja, het is een e-boek, waarvan iedere maand een nieuw hoofdstuk uitkomt. Testnieuws sprak met de auteur, Gerard Numan van Polteq.

Gerard, vertel eens wat over jezelf: wie, wat, waar, waarom, …
Ik ben software tester: testanalist, testcoördinator, testmanager, opleider en auditeur, sinds 1998 werkzaam in het vak. Als persoon zou ik mezelf willen beschrijven als sociaal en tegelijk wetenschappelijk. Ik houd er van om ingewikkelde zaken uit te zoeken, er over te discussiëren, inzichten vorm te geven en uit te leggen.

Ik werk al een hele tijd bij Polteq; ik heb er net mijn tienjarig jubileum gevierd. Afwisseling in mijn werk is voor mij belangrijk. Ik vind het leuk testgevallen te ontwerpen en uit te voeren, en dat af te wisselen met testmanagement en het geven van een cursus of presentatie. Dit is ook hoe mijn loopbaan bij Polteq er uit ziet.

Je hebt een boek geschreven: ‘Praktijkgerichte aanpak voor End to End (E2E) testen’. Hoe ben je daartoe gekomen?
Tijdens mijn eerste testklus, als testanalist, viel mij al op hoeveel misverstanden er bestaan over integratietesten. Definities waren niet duidelijk en er werden veel integratierisico’s gemist. De één bedoelde met Integratietesten eigenlijk interfacetesten, de ander SysteemIntegratieTesten en weer een ander GebruikersAcceptatieTesten. Het was lastig om alle benodigde partijen te betrekken bij het voorbereiden en uitvoeren van Integratietesten.

In 2010 kregen we bij Polteq het idee om een whitepaper over Integratietesten te gaan schrijven, omdat Integratietesten een steeds groter thema werd en klanten vaker om verheldering en begeleiding vroegen. Toen ben ik het verhaal structureel gaan uitwerken en kwamen we er achter dat er een boek van te maken is.

E2E_schets

Het bleek nodig om Integratietesten helderder te definiëren en de verschillende niveaus van integratietesten te onderscheiden: Connectiviteitstest, Interfacetest, Systeemintegratietest en tenslotte E2E-test. We hebben toen de E2E-test, als overkoepelende integratietest, als uitgangspunt voor het boek genomen. In de afgelopen jaren heb ik een aantal E2E-testen mogen opzetten, coördineren en uitvoeren. Ik heb trouwens ook veel gespard met collega’s en hun ervaringen bij diverse organisaties kunnen meenemen. Mijn boek is dan ook in dialoog met de praktijk ontstaan.

Wat is voor jou de essentie van E2E-testen?
Daadwerkelijke processen en daadwerkelijke situaties zijn het uitgangspunt van een E2E-test. Ontwerpen zijn ondersteunend voor een E2E-test, maar niet het laatste woord. E2E-testen is daarom meer valideren dan verifiëren. Voor E2E-testen moeten de testers zelf de testbasis verzamelen. De testbasis van de E2E-test is namelijk de samenhang tussen businessprocessen, beheerinstructies, globale ontwerpen, functionele ontwerpen en technische ontwerpen. Dit staat vrijwel nooit ’ergens’ mooi en in zijn totaliteit beschreven. Je moet inzichtelijk krijgen hoe systemen worden gebruikt, door wie en met welk doel, en hoe processen door de keten van alle systemen en systeemonderdelen heen lopen. Testgevallen moeten er op gericht zijn om die samenhang efficiënt en toch volledig te raken.

Lands End

Een E2E-tester moet het volgende kunnen:

  • Weten wat het verschil is tussen een Connectiviteitstest, een Interfacetest, een Systeemintegratietest en een E2E-test.
  • Integratierisico’s kunnen analyseren en weten welke van de Integratietesten deze dekken.
  • Een E2E-inventarisatie (over de samenhang tussen processen en systemen) kunnen uitvoeren en op basis daarvan testgevallen weten te ontwerpen.
  • Weten hoe je de E2E-testen vervolgens organiseert: wie heb je wanneer nodig en hoe zet je mensen op een voor hen acceptabel wijze in?

Hoe past E2E-testen eigenlijk bij moderne kort-cyclische ontwikkelmethodieken zoals Agile?
Kleine teams die samen snel hoogwaardige aanpassingen opleveren, verliezen makkelijk het oog voor onverwachte effecten verderop in de keten. E2E-testen zou onderdeel van Agile werken moeten zijn, maar lijkt vaak op gespannen voet te staan met het kort-cyclische karakter van Agile. Ik denk dat met name grote organisaties kennis van E2E-ketens moeten verzamelen en beschikbaar stellen aan Agile teams. In de Agile teams is die kennis soms best wel beschikbaar, omdat er verschillende disciplines bij betrokken zijn, maar vaak zie je dan dat men die kennis niet onderling, tussen de teams, deelt en per team alle wielen opnieuw uitvindt.

Daarnaast kun je denken aan ‘Continuous Integration in the Large’: een continu operationele E2E-testomgeving, waarin periodiek E2E-tests plaatsvinden om de resultaten van de verschillende Agile teams, maar ook van grote projecten en kleine bugfixes, vanuit een brede kijk te (her)testen.

Hoe voorkom je dat E2E-testen een te grote testsoort wordt naast alle reeds bestaande testen?
E2E-testen is niet per se een nieuwe testsoort, een nieuwe fase, met een nieuwe, latere inproductiename als gevolg. E2E-testen begint met het vaststellen van E2E-risico’s en het verwerven van inzicht in de E2E-keten. Die inzichten kun je zonder meer inzetten in bestaande testsoorten zoals de Interfacetest of de Systeemtest. Testuitvoering van een E2E-test kan daarnaast (ten minste deels) worden gecombineerd met Interfacetesten, Systeemintegratietesten en Acceptatietesten.

Schrik daarom niet terug voor E2E-testen! Met name het ontwikkelen van inzicht in de E2E-keten betaalt zich op alle fronten terug: ook voor de kwaliteit van systeemtesten, beheerprocessen, en het ontwerp van volgende trajecten.

Je kunt de hoofdstukken van het boek hier downloaden.