Auteur: Rik Marselis ● Rik@Marselis.eu ● @rikmarselis
Vorige week, op woensdag 11 september (ja ja, nine-eleven, een dag van life-changing events) was het TestNet najaarsevenement. Het was weer gezellig als vanouds.
Voor mij was het een eer om het evenement met een keynote-presentatie te mogen openen. Het thema van het evenement was ‘Over testen gesproken’ en ik had besloten daarbij aan te sluiten door vanuit mijn eigen ervaring enkele test-lessen te delen.
De eerste les heb ik al aan het begin van mijn carrière geleerd. Als COBOL-programmeur werd van mij verwacht dat ik, voordat een programma dynamisch getest werd op de IBM370-computer, ik samen met een collega eerst een code-review deed. En vervolgens ging desk-checken. Dat desk-checken betekende dat ik het programma statement voor statement doorliep en dan zelf voor computer speelde. Op een kladblaadje hield ik de inhoud van de variabelen bij. En op deze manier vonden mijn collega’s en ik snel eventuele logische fouten. Daarnaast leerden we van elkaar over slim programmeren. Je snapt dus wel dat ik me wel eens verbaas over de nonchalance waarmee het nut van statisch testen tegenwoordig door nogal wat programmeurs wordt afgewezen.
De tweede les ging over waarmee je begint als je een nieuwe testklus start. Veel mensen denken als eerste aan een testplan. Mijn ervaring is dat je beter eerst met je testrapportage kunt beginnen. Want de testrapportage is eigenlijk het enige product van testen waar de stakeholders echt wat om geven. Dus als je vanaf dag 1 met ze in gesprek gaat over wat voor rapportage ze willen hebben, dan kun je op basis daarvan wel beredeneren wat je allemaal moet doen om die rapportage te kunnen invullen.
En les drie ging over de toekomst van testen, of breder kwaliteitszorg. Want door de enorme hoeveelheid gegevens over de kwaliteit van een systeem die we door middel van testen verzamelen en de nog grotere hoeveelheid gegevens over de kwaliteit die we door middel van monitoring op de live-omgeving kunnen verzamelen, hebben we alles beschikbaar om aan ‘quality forecasting’ te doen. Met quality forecasting gaan we door het toepassen van kunstmatige intelligentie voorspellen hoe de kwaliteit van een informatiesysteem zich zal gaan ontwikkelen. En als de kwaliteit de verkeerde kant op gaat, dan kunnen we fouten al oplossen nog voordat ook maar één gebruiker een probleem merkt!
Maar, hoe zit het nou met dat blackbox-testen uit de titel? Ik verwonder me regelmatig over terminologie. Met blackbox-testen bedoelen we dat we testen zonder dat we de werking van een systeem kunnen zien. Het is een zwarte doos waar we niet in kunnen kijken. We doen er wat input in en als de output goed is, nemen we aan dat het ‘onder de motorkap’ ook goed werkt. Maar soms willen we wel degelijk de interne werking van een systeem zien. Dus dan moeten we in het systeem kijken. Dus geen zwarte doos om het systeem. Maar wat dan wel? Veel mensen zeggen ‘whitebox-testen’. Dan doe je dus een witte doos om het systeem. Maar ook door een witte doos kun je niet heen kijken, toch? Dus het tegengestelde van blackbox-testen is natuurlijk ‘glassbox-testen’. Want door een glazen doos kun je wel heen kijken!
Wil je mijn keynote-presentatie nog eens terugkijken volg dan deze link:
https://www.slideshare.net/RikMarselis/over-testen-gesproken-testnet-najaar-2019-openingskeynote-rik-marselis of kijk op de TestNet website https://www.testnet.org/testnet/p000646/bibliotheek/evenementen/najaarsevenement-2019-over-testen-gesproken, hier vind je ook vele andere presentaties en de foto’s van het evenement.
Tot slot wil ik ook via deze weg het bestuur van TestNet bedanken dat ik tijdens het evenement benoemd ben tot erelid van de vereniging. Ik heb de afgelopen ruim vijftien jaar met veel plezier bijgedragen aan het organiseren en blijf onze mooie vereniging uiteraard volgen en bezoeken.
Veel testplezier!