Nederland loopt achter op het gebied van testen. De dagen van de ‘Dutch school of testing’ zijn voorbij, dankzij de wet van de remmende voorsprong. Maar er is langzamerhand een soort nieuw realisme ontstaan, een nieuwe kijk op testen. Jan Jaap Cannegieter, directeur productmanagement bij Sysqa en spreker op diverse seminars in binnen- en buitenland, vertelt over de eye-opener die hij ‘down under’ kreeg en de nieuwe kijk op testen.
Je spreekt regelmatig op conferenties over testen. Wat is je in je trips naar het buitenland het meeste opgevallen?
Dat we in Nederland achterlopen als het gaat om ontwikkeling van methoden en technieken op het gebied van testen.
Hoe bedoel je? Ik dacht dat Nederland altijd voorop liep in testland?
Dat kan ik me voorstellen. In de jaren ‘90 zijn er in Nederland verschillende testmethoden ontwikkeld. Enkele grondleggers van het testen in Nederland spraken veel op buitenlandse conferenties, Nederlandse boeken over testen zijn vertaald in diverse talen en in het buitenland werd zelfs gesproken over de ‘Dutch school of testing’. Toen liepen we internationaal gezien inderdaad voorop in de testwereld.
Wat is er dan gebeurd dat we nu achterlopen?
Ik denk dat er vervolgens sprake is geweest van de ‘wet van de remmende voorsprong’. We zijn blijven hangen in de methoden die in de jaren 90 zijn ontwikkeld, terwijl in het buitenland de ontwikkeling van testmethoden verder is gegaan. En dan doel ik op ontwikkelingen zoals context driven testen, exploratory testen en rapid software testen. Die ontwikkelingen beginnen pas de laatste tijd vaste voet aan de grond te krijgen in Nederland, terwijl exploratory testen toch echt al meer dan tien jaar geleden is ontstaan.
Hoe ben jij erachter gekomen dat we achterlopen in Nederland?
Zolang je alleen in Nederland blijft, kom je daar niet achter. Ik moest daarvoor naar de andere kant van de wereld; Nieuw Zeeland en Australië. Ruim twee jaar geleden heb ik daar een key note presentatie en een tutorial verzorgd op twee conferenties. Het viel me op dat ze daar anders over testen praatten dan ik gewend was en dat ze andere helden hebben dan wij in Nederland. Maar ik werd pas echt wakker geschud tijdens de tutorial die ik verzorgde. Het onderwerp was testprocesverbetering en op een goed moment was ik met een aantal deelnemers aan het discussiëren over testontwerp en testuitvoering. Op één of andere manier leek het alsof de deelnemers en ik elkaar niet echt begrepen. Ineens zei een deelnemer tegen een andere deelnemer: ‘He’s from Holland, he only knows scripted testing.’ Door die opmerking werd ik toch wel behoorlijk uit mijn evenwicht gebracht. Ik begreep in eerste instantie gewoon niet wat die man bedoelde. Ok, ik kom inderdaad uit Nederland. En zit ik daardoor in een bepaald hokje? En wat is scripted testing? De tutorial ging gewoon door, de bewuste deelnemer heb ik nooit meer gezien, maar zijn opmerking is bij me blijven hangen.
En toen?
Ik heb op die conferenties nog zoveel mogelijk mijn licht opgestoken, maar pas terug in Nederland ben ik er samen met een aantal collega’s echt ingedoken. We zijn de ideeën van James Bach, Michael Bolton, James Whittaker, Elisabeth Hendrickson en Gerald Weinberg gaan bestuderen, zijn hun boeken gaan lezen, en zijn andere conferenties gaan bezoeken. En uiteindelijk hebben we situationeel testen ontwikkeld.
Aha, een nieuwe testmethode?
Nee, situationeel testen is geen nieuwe testmethode, absoluut niet. Sommige breed ontwikkelde testers zeggen ook dat er niets nieuws in staat en dat is helemaal waar. Situationeel testen is wel een vernieuwende kijk op testen. De essentie is dat je die manier van testen gebruikt die het beste bij jouw systeem, project en organisatie past, dus niet altijd die ene methode gebruikt die standaard is bij jou organisatie. Situationeel testen onderkent verschillende vormen van testen. Denk daarbij aan testen in testsessies aan de hand van een aantal globale testideeën, of testen zonder van te voren testscripts te maken en de uitkomsten van de tests leidend te laten zijn voor de volgende tests. De in Nederland overbekende manier van testen, waarbij we testen aan de hand van vooraf opgestelde testscripts, valt ook onder situationeel testen omdat deze manier in sommige situaties ook heel goed bruikbaar is. Als tester heb je dus veel meer manieren van testen tot je beschikking. Geen enkele manier van testen is goed of slecht, het hangt van de situatie af hoe je het beste kan testen. Dat maakt testen dus veel flexibeler, effectiever en vaak ook goedkoper en sneller. Het vraagt wel van de tester om al die verschillende manieren van testen te beheersen.
En wordt situationeel testen al toegepast?
Zeker! Een aantal klanten van Sysqa passen het al met veel succes toe. De testers zelf zijn eigenlijk altijd enthousiast omdat ze de aanpak op hun situatie toe kunnen snijden en een veel grotere gereedschapskist hebben dan vroeger. De methode is niet meer leidend! Naast dat een aantal organisaties het al toepassen verzorg ik de laatste tijd regelmatig workshops situationeel testen, er is veel interesse voor de ideeën.
Is Sysqa de enige die bezig is met deze ontwikkeling?
Nee, er zijn inmiddels ook anderen buiten Sysqa die hier heel actief en goed mee bezig zijn. Onlangs heeft Testnet, een netwerkorganisatie voor en door testers, bijvoorbeeld een evenement georganiseerd over context driven testen. Daarnaast zijn er een aantal erg enthousiaste testers die regelmatig bij elkaar komen om het over dit soort dingen te hebben. Maar ondanks al die initiatieven zijn er nog heel veel testers die alleen de oude kijk op testen er op na houden. Er is dus nog een wereld te winnen en dat is de grote uitdaging voor de test community voor de komende jaren.
Goede ontwikkeling!
Methodes zijn alleen van toegevoegde waarde als de tester zelf het testen in zijn genen heeft.
Dus, blijf kritisch, A fool with a tool is still a fool!
“De essentie is dat je die manier van testen gebruikt die het beste bij jouw systeem, project en organisatie past, dus niet altijd die ene methode gebruikt die standaard is bij jou organisatie.”
Dat geldt voor zowel elk aspect van ICT, dat je kijkt naar het resultaat wat je wilt bereiken en daar de beste oplossing voor zoekt. Bedrijven willen echter managebare policies. Voor testers, ontwikkelaars, beheerders en ander werkvloervolk verandert er dus niets.
Binnen TMap zijn Exploratory Testing en Error Guessing legitieme testtechnieken. Waarin verschilt situationeel testen nu precies?
# Peter Lichtenveldt: Exploratory Testing is absoluut geen testtechniek, hoewel het (foutief!)wel zo staat beschreven in TMap. Dat is de wereld op z’n kop: TMap beschrijft hoe je op allerlei manieren scripted kan testen, en aan het andere uiterste van het spectrum is Exploratory Testing de denkwijze waarop je zonder testscripts zeer gestructureerd kan werken. TMap en Exploratory Testing staan NAAST elkaar, de één is geen onderdeel van de ander of omgekeerd. Maar deze misvatting heerst in Nederland wel meer.
Ik moet hier Bart Fessl volgen. Tmap legt feitelijk alleen maar een ‘blauwdruk’ zoals ITIL dat ook doet waar je de rest zelf uiteindelijk mag en kan invullen.
Persoonlijk en professioneel kijk ik alleen maar naar de functionaliteiten van het proces in de zin van toegevoegde waarde. Vaak ervaar ik dat wanneer men weer eens ergens weer wat nieuws voor heeft verzonnen, het alleen maar weer een extra stap blijkt te zijn in het hele testproces i.p.v. een werkelijke toegevoegde waarde.
Ik heb eenvoudige testprocessen gezien die twee maal zo snel werkten dan veel ‘gecertificeerde’ processen omdat ze gewoon bij de meest basale waarden van het testen bleven.
@Cordny Nederhoorn…..
Indeed…
@Bart; ik ben het niet helemaal met je eens dat Exploratory Testing geen testtechniek zou zijn. Het is geen scripted testtechniek. Maar je moet wel degelijk vaardigheden bezitten en hulpmiddelen inzetten om deze testtechniek goed uit te kunnen voeren. TMap is zeker niet heilig, maar beschrijft wel degelijk een aantal testtechnieken. Daarbij is vooral aandacht voor scripted technieken. Er wordt echter ook aangegeven dat er meer is dan alleen deze scripted technieken, zoals bijvoorbeeld ET en EG. Belangrijkste techniek die een tester dient te bezitten is het logisch kunnen nadenken. Welke testtechnieken moet ik inzetten om voor de klant het maximale resultaat te behalen. Dat kunnen scripted en non-scripted technieken zijn of een mix daarvan. Dat mag je van mij situationeel testen noemen.
@ Gilbert: de beschrijving die je meegeeft zegt juist dat je begint aan te voelen waarom ET géén testtechniek als EVT, PCT, BTT etc. is. Om goed non-scripted of exploratory te kunnen testen moet je op een heel andere manier in de wereld staan dan nodig is om je een testtechnik goed eigen te maken. Met een paar uur studeren kan ik de volledige tekst van TMap rondom de BTT reproduceren en kan ik deze zelfs in de praktijk gaan toepassen. Om goed exploratory te kunnen testen gebruik ik al m’n ervaring, stel ik continu vragen, stel ik zaken ter discussie, gebruik ik (al is het zonder ze op te schrijven) testtechnieken, basistechnieken, heuristics, mijn omgeving. Kortom: bij ET maak ik gebruik van alles wat mij beschikbaar is, inclusief mijn kennis van TMap. Dat maakt ET veel meer dan zogenaamd een testtechniek, sterker, dat geeft aan dat het géén testtechniek is maar een manier van het benaderen van testen. En dus staat ET mijns inziens naast testmethoden als TMap, en is het geen aan te leren truukje zoals de eerder genoemde testtechnieken.
Als je weet dat ca. 7% van de fouten coding-fouten zijn (J. Martin). Als je dat gegeven vervolgens langs de “wet van Boehm” (B. Boehm) en “succes- en faalfactoren” (T. van Aken) haalt, dan blijft testen “Much ado about nothing”, een Nederlands achterhoede gevecht.
Jammer Jan-Jaap dat je een inhoudelijk standpunt koppelt aan het bedrijf waarvoor je werkt. Een goed inhoudelijk standpunt / Expert opinie doet dat m.i. niet.
@Pieter Allijn
Een zoektochtje naar de J Martin die je noemt leverde helaas niets op. Dus graag een wat duidelijker referentie. Maar misschien belangrijker. “7% van de fouten zijn coding fouten”, dus?
De wet van Boehm word met grote regelmaat aangehaald ondanks het feit dat hij bij nader onderzoek (Leprachauns of Software Engineering – Laurent Bossavit) slecht is gebaseerd op een enkel onderzoek met een te kleine grootte om welke gerechtvaardigde conclusie dan ook te trekken. Zelfs Boehm noemt het in het oorspronkelijke artikel slechts ter illustratie.
Maar ook hier, dus?
De aangehaalde succes- en faalfactoren van Teun van Aken hebben betrekking op het al dan niet succesvol zijn van een project. In zijn lijstje ontbreekt echter een belangrijk criterium. Namelijk wat het resultaat van het project is. Heeft het project ook het gewenste bedrijfs- en gebruiksresultaat opgeleverd? Laat dat laatste nou net een vraag zijn de moderne software tester, met inachtneming van de verschillende stakeholders, beoogt te beantwoorden.
Je achterhoede opmerking maakt daarmee dan ook geen enkele indruk. Het versterkt eerder het beeld dat Jan Jaap oproept dat de ‘Dutch School’ zijn langste tijd heeft gehad en dat niet alleen software testers, maar ook de rest van de software ontwikkelgemeenschap er goed aan deden om daar eens bij stil te staan.