Twee typen context

De Context Driven School of Testing maakt school en daar zijn goede redenen voor. De “oude” procesmodellen zijn nu eenmaal niet onverkort in elke situaties en activiteit toe te passen. Vandaar dat men in deze school ook zo vaak tegen het idee van “best practices” aan trapt. Een testtechniek die ergens heeft gewerkt hoeft dit niet zo maar ergens anders ook te doen. Een techniek moet dan ook nooit worden gezien als een concrete handleiding die men overal moet toepassen. Zo werkt het echter vaak nog wel en dat geldt niet alleen voor testmethodologieën: ook testtools of testautomatisering worden vaak van boven af voorgeschreven aan een gehele organisatie, in elke mogelijke uithoek, in elke situatie. Zonde, niet effectief en zeker niet efficiënt.

Maar wat is dan die context waar we ons aan moeten meten, om tot een goed testkeuzes te komen voor een specifieke situatie?

Ik wil er op wijzen dat er twee verschillende typen context zijn die van belang zijn voor het bepalen van de juiste testen. Het eerste type context betreft wat ik hier voor het gemak de projectomstandigheden noem: de omstandigheden van testen binnen een project of de organisatie, de plek van testen ten opzichte van andere projectatctiviteiten. Dit type context bevat de ontwikkelmethodiek, de kwaliteit van unittesten, beschikbare resources voor testen.  Zo is de keuze van testtechnieken en testdekking voor een groot deel van deze context afhankelijk. Ik heb de indruk dat men het over het algemeen over dit type context heeft.

Het tweede type context vind ik veel interessanter: het gaat dan om de context van de software en het project in de organisatie en de wereld. Het gaat dan om bijvoorbeeld hoe de software wordt gebruikt (het eindproces), wie de software uiteindelijk gaat gebruiken, in welke omstandigheden de software en de gegevens worden gebruikt en waar en wanneer gegevens in en vanuit het systeem nodig zijn en worden gewijzigd. Volgens mij zit het belangrijkste punt van de Context School in dit tweede type context: het gaat er dan om als tester met de klant (of de gebruiker, de beheerder, et cetera)  mee te denken en vanuit het perspectief van de klant de software te testen. Maar ook om te onderzoeken hoe de software of de gegevens elders of later worden gebruikt en wat er allemaal zou kunnen gebeuren.

Vanuit het eerste type context maakt men niet de stap die m.i. de belangrijkste boodschap is van de Context School: om als tester uit de modus van verificatie op basis van projectinterne documenten te stappen en de uitdaging aan te gaan toegevoegde waarde te leveren voor mensen die er toe doen .

Advertenties

Een externalistische kijk op testen

Externalisme is een stroming in de wetenschap waarbij men concludeert dat functies (bijvoorbeeld het bewustzijn of het geheugen) niet louter te begrijpen zijn in termen van de materiële ondergrond (hersenen) maar moet worden gezien als een proces waarbij de materiële basis reageert op een buitenwereld, functioneert in een omgeving.  Het bewustzijn of de geest  “zit” volgens het externalisme dan niet in de hersenen maar zit in de wisselwerking tussen hersenen, lichaam, zintuigen en omgeving.

Internalisme is de opvatting dat mentale processen, zoals denken, voelen, zien, voornamelijk te begrijpen zijn als toestanden of inhoud van hersenactiviteit. Hieruit volgt vaak een deterministische kijk op de geest. Een voorbeeld hiervan is Dick Swaab’s “Wij zijn ons brein”. Hoewel de meeste van de gedachten in dit boek gebaseerd zijn op in feite juiste resultaten en observaties uit de neurologie schieten de conclusies van Swaab vaak tekort om mentale verschijnselen en processen te begrijpen. Ze zijn niet volledig. Door in de hersenen te kijken zul je namelijk nooit een gedachte of een gevoel  zien. Je ziet (slechts) het neurologische correlaat van een gedachte.

Dit denkprobleem is relevant voor de IT, en dus ook voor testers. Internalistische vooroordelen zijn wijdverspreid en leiden er toe dat systemen niet goed worden ontworpen en beoordeeld en risico’s worden gemist. Zit het proces in de hardware of de software? Zit het proces in een keten van alle hardware en software, of zit de keten van hardware en software in het proces dat gebruik maakt van deze keten? Als je systemen alleen maar beschouwd vanuit hun interne werking, en voornamelijk alleen maar “in” de systemen kijkt dan mis je het grote plaatje. Een mooi voorbeeld van hedendaags “internalisme”, waarbij alleen maar  in de systemen wordt gekeken is James Bach. James Bach is een hedendaagse testgoeroe, die veel zinnige dingen zegt. Zie voor een college door James Bach: http://www.youtube.com/watch?v=ILkT_HV9DVU.

Ook in dit college zegt James Bach een aantal interessante dingen, waar ik het meestal onverkort mee eens ben. Zo wijst hij op het verschil tussen “Checking” en “Testing”.  Checking is het uitvoeren van controles, gebaseerd op vastgelegde criteria. Het is hersenloos verifiëren. Testautomatisering is een vorm van “checking”. Maar ook testen waarbij men als enige testbasis functionele of technische specificaties neemt zijn “checking”.  “Testing” hoort echter een kritisch denkproces te zijn, waarbij de tester  constant op zijn hoede is en het systeem probeert te onderwerpen aan situaties waar het in het nauw wordt gebracht. Ik vindt dit een erg goed punt. Echter: in het college, maar ook in zijn  publicaties, geeft James Bach als enige voorbeelden van dergelijk kritisch “Testing”, testgevallen die op component- en systeemniveau zijn bedacht en uitgevoerd. Bevindingen die zo worden gevonden betreffen alleen interne bugs. Nergens kom ik in zijn betoog “Testing” tegen op het niveau van ketens van systeemintegratie of het testen vanuit processen of vanuit de daadwerkelijke gebeurtenissen in de wereld.

Ik wil niets af doen aan de ideeën van James Bach: ze zijn waardevol, maar incompleet. Door zijn internalistische houding wekt James Bach de indruk dat testen een vak is van mijnwerkers die de krochten van softwarecode ingaan om daar buitenissige fouten en effecten op te sporen. Dit moet ook gebeuren, als deze fouten niet worden opgespoord zal het proces ook niet werken. Echter: om de samenhang van systemen in relatie met processen en gebeurtenissen te testen, zal de mijnwerker moeten opstijgen en dezelfde kritische, creatieve houding moeten inzetten om de wereld rondom de software mee te nemen in zijn beoordeling van de software.

Een keten van geautomatiseerde systemen staat niet op zichzelf, maar heeft pas betekenis ten opzichte van de wereld buiten die keten: een tekstverwerker is alleen maar een tekstverwerker omdat mensen met behulp van de tekstverwerker teksten schrijven. Dit lijkt zo simpel maar het is heel gemakkelijk om de tekstverwerker uitsluitend te beschouwen als de verzameling bits en bytes ,die het ook is, en het alleen maar te beoordelen op criteria die heel concreet zijn vastgelegd voor hoe de verzameling bits en bytes zich gegeven bepaalde input moet gedragen en wat voor output er dan uit moet komen.

Het systeem, als systeem dat een proces ondersteunt, is niet denkbaar zonder het te zien in termen van de functie die het vervult voor iets buiten het systeem. Deze breedst mogelijke context, waarin systemen worden beoordeeld vanuit het gehele proces, is de expliciete focus van de E2E-test (en vaak ook van acceptatietesten). De acceptatiecriteria voor zo’n test zijn dan geen optelsom van de acceptatiecriteria of specificaties voor elk van de deelsystemen, maar moeten worden opgesteld vanuit het gehele proces waarin de systemen functioneren én vanuit mogelijke gebeurtenissen en situaties die het systeem, het proces en de gegevens kunnen overkomen. Met name de laatste staan niet in procesbeschrijvingen of specificaties en hebben een externalistische kijk nodig vanuit testers op processen en systemen .

 

Mijn link met E2E-testen

Ik heb sinds 1998 al vermoed dat er in de definities van integratietesten iets miste, dat “wij IT-ers” een tunnelvisie hebben, waardoor wij bij voorbaat niet in staat zijn om bepaalde integratieproblemen te voorkomen.

In 2002 kreeg ik het voorrecht op een conferentie iets te mogen zeggen over wat ik toen met een ongelukkig woord “Chain Testing” noemde. De lezing ging vooral over ketenrisico’s en de maatregelen die daarbij hoorden. Deze zocht ik voornamelijk in de organisatie van de testen en het in kaart brengen van alle koppelingen. Ook daar miste nog steeds een belangrijk punt: ik bekeek namelijk integratie als een schakeling van systemen. Op zich is dat niet onjuist. Het is echter onvolledig: integratie heeft namelijk als doel om een proces te ondersteunen.

Integratie is niet het integreren van systemen maar het mogelijk maken van een proces.

Pas in het daadwerkelijk uitvoeren van een proces blijkt de integratie, niet door in systemen te kijken. Daarom zijn interfacetesten en systeemintegratietesten niet genoeg (hoewel ze wel noodzakelijk zijn).

Dit is de ontdekking die ik gedaan heb. Ik zal er nooit een Nobelprijs mee winnen: ik ben niet de eerste die deze ontdekking heeft gedaan. In de geschiedenis, in de IT, in de testwereld, overal is dit inzicht al bekend. Het is mij echter niet bekend of er een aanpak is die dit expliciet (of expliciet genoeg) benoemt en die de consequenties (voor testen) voldoende uitwerkt. De aanpak die binnenkort op polteq.com wordt gepubliceerd is dan wellicht de eerste poging.

Zie link voor de nieuwe praktijkgerichte aanpak voor E2E-testen:

http://www.polteq.com/testdienst/praktijkgerichte-aanpak-end-to-end-e2e-testen/