Gerard Numan ● gerard.numan@polteq.com
Gerard Numan kennen we sinds enige maanden als de vaste cartoonist van TestNet Nieuws. In treffende plaatjes weet hij ‘aha’-momenten uit het bestaan van de tester vast te leggen. Gerard is echter niet alleen een begaafd tekenaar, ook als auteur staat hij zijn mannetje. Sinds begin van dit jaar is namelijk zijn boek over End-to-End-(E2E-) testen aan het verschijnen. Aan het verschijnen? Ja, het is een e-boek, waarvan iedere maand een nieuw hoofdstuk uitkomt. Daar willen we meer van weten.
Gerard, vertel eerst eens iets over jezelf.
Ik ben softwaretester: testanalist, testcoördinator, testmanager, opleider en auditeur, sinds 1998 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 eruit 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 veel integratierisico’s werden 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.
Ik heb in 2002 op STARWEST mogen spreken over wat ik destijds ‘ketentesten’ noemde. Mijn ideeën van toen heb ik in de praktijk daarna steeds kunnen bijslijpen en toepassen. In 2010 kregen we bij Polteq het idee om een white paper over integratietesten te schrijven, omdat integratietesten een steeds groter thema werd en klanten steeds vaker om verheldering en begeleiding vroegen.
Vervolgens ben ik het verhaal structureel gaan uitwerken en kwamen we er achter dat er een boek van te maken is. Het bleek nodig om integratietesten helderder te definiëren en de verschillende niveaus van integratietesten te onderscheiden: connectiviteitstest, interfacetest, systeemintegratietest en ten slotte E2E-test. We hebben toen de E2E-test, als overkoepelende integratietest, als uitgangspunt voor het boek genomen. De E2E-test is namelijk in de literatuur tot nu toe de minst belichtte testvorm, maar in de praktijk zeker niet de minst belangrijke.
In de afgelopen jaren heb ik een aantal E2E-testen mogen opzetten, coördineren en uitvoeren. Ik heb 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.
In welk opzicht is E2E-testen echt anders dan ‘gewoon’ 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.
Een ander groot verschil met ‘gewoon’ testen is dat je het als tester niet alleen kunt. De kennis die nodig is voor een E2E-test zul je nooit volledig zelf kunnen bijeensprokkelen; je zult samenwerking moeten zoeken met gebruikers, beheerders en ontwerpers, en deze betrekken in de E2E-test. Je hebt hen nodig om gevoel te krijgen voor de daadwerkelijke risico’s, zodat je de E2E-test effectief en behapbaar kunt houden. En dan kom je er snel achter dat deze mensen ook andere dingen doen, dus je moet veel zelf invullen.
Altijd en overal een volledige E2E-test uitvoeren is geen optie: te duur, te lang. E2E-testen moeten daarom waar dit kan worden geautomatiseerd en in samenhang met andere integratietesten en acceptatietesten worden uitgevoerd. Dit is wel degelijk mogelijk en levert veel op, ook voor anderen, zoals bijvoorbeeld kennis voor beheerders en gebruikers!
Kortom, allemaal kansen om ons mooie testvak uit te breiden en meer waarde te geven!
Wat zouden alle (andere) testers minimaal van dit onderwerp moeten weten en ermee moeten kunnen?
Tja, om maar eens wat primaire zaken op te noemen:
- 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 kunnen ontwerpen.
- Weten hoe je de E2E-testen vervolgens organiseert: wie heb je wanneer nodig en hoe zet je mensen op een voor hen acceptabele wijze in?
Al die testsoorten die je noemt, dat voelt behoorlijk ‘old school’. Past dat wel 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 blijft daarom ook in Agile van belang. Agile teams hebben kennis van E2E-ketens deels zelf al beschikbaar, omdat er verschillende disciplines bij betrokken zijn. Maar vaak zie je dan dat men die kennis tussen de teams niet onderling deelt en per team alle wielen opnieuw uitvindt. Ik denk dat met name grote organisaties kennis van E2E-ketens moeten verzamelen en beschikbaar stellen aan Agile teams, zodat men E2E-risico’s kan meenemen in toetsen en testen.
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.
Zoals jij E2E-testen presenteert, lijkt het een flinke klus. Hoe voorkom je dat het te groot 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 reviews en 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. Een E2E-test is gebaseerd op expliciete proceskennis. Door gebruikers in te zetten bij het vergaren en het testen daarvan is het veelal mogelijk om vroeger te accepteren! In de praktijk zie je trouwens vaak dat acceptatietesten, omdat men daar weet welke risico’s normaal worden gemist, al uitgroeien tot een E2E-test.
Een boek schrijven doet de gemiddelde tester niet elke dag. Hoe is dat voor jou verlopen, welke ups en downs wil je met ons delen?
Ik heb het geschreven parallel aan de inzet in opdrachten, met af en toe een aantal dagen om meters te maken. Dit was soms best lastig: schrijven is een activiteit die je niet zo maar aan- of uitzet. Toch heb ik er veel genoegen aan beleefd. Al met al heeft het natuurlijk langer geduurd dan gedacht (waar kennen we dat van?).
- Downs: je komt je eigen beperkingen tegen. Ik heb vaak stukken geschreven die later door anderen behoorlijk werden ‘afgeschoten’. Te veel jargon, niet goed lopende zinnen, te vaak van voorkennis bij de lezer uitgegaan die voor mij inmiddels vanzelfsprekend was. Als tester had ik kunnen weten dat een product pas goed is na een gestructureerd testproces met veel testbevindingen!
- Ups: uiteindelijk heb je een kindje gebaard waar je heel trots op bent. Daarnaast maak je het onderwerp jezelf eigen door het zo uitvoerig uit te werken.
Jouw boek verschijnt als e-boek, in maandelijkse afleveringen via de website van Polteq. Waarom hebben je voor die opzet gekozen?
Fysiek publiceren (je weet nog wel: een echt boek dat je kunt vasthouden, met een kaft en druppeltjes inkt op papier) is niet meer zo nodig, niet meer zo effectief, niet meer zo van deze tijd. Het is bijvoorbeeld moeilijk om over een onderwerp iets te schrijven dat altijd en voor iedereen het laatste woord is. Mensen zijn tegenwoordig ook veel meer aangesloten op sociale media. Wat je wilt vertellen moet daarom in los leesbare hapklare brokken via deze kanalen deelbaar en aanpasbaar zijn. Misschien komt er uiteindelijk nog wel een fysieke versie, maar daar zijn we nu niet mee bezig.
Hoe is de belangstelling voor het boek en wat zijn jouw ervaringen tot nu toe, nu de eerste vijf hoofdstukken zijn verschenen? Krijg je veel reacties?
Er is inmiddels een (groeiende) schare van trouwe lezers. Die geven voornamelijk positieve feedback, maar stellen ook een aantal kritische vragen, bijvoorbeeld over de toepasbaarheid in combinatie met Agile, het risico van een te grote nieuwe testsoort zonder genoeg toegevoegde waarde en de mate waarin je diverse ketenpartners moet benoemen en betrekken in testontwerp en uitvoering. In vervolgdelen en nieuwe versies gaan we meer in op deze punten.
Waar ik nog erg nieuwsgierig naar ben, is naar de praktijkervaringen van anderen, vooral in relatie met de kritische opmerkingen. Ik wil natuurlijk ook graag weten hoe toepasbaar mijn ideeën voor anderen zijn. Als iemand mij een verhaal vertelt of een vraag stelt, ga ik daar altijd op in.
Een slotwoord van een gedreven auteur…
Schrik 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.