De ict-branche staat vol van innovatie, toch lijkt het er op dat elke discipline zijn eigen vorm van innovatie heeft. Als je kijkt naar het testen, lijkt het net als of het testen sinds tijden stil staat. Toch valt dit te betwisten, het testen van informatiesystemen staat niet stil. Aan de hand van de volgende voorbeelden zal ik proberen weer te geven dat de ontwikkeling van het testen niet wordt ingegeven door de techniek.
De laatst nieuw geïntroduceerde formele testtechniek dateert van 1994; de classification tree method waarmee functioneel gezien het laatst wiskunde paradigma voor testdoeleinden is geslecht. Wat eind zeventiger jaren begon met equivalentie klassen of grenswaardenanalyse, eindigde bijna 25 jaar later met de functionele interpretatie van orthogonale arrays. Sindsdien zijn er wel nieuwe methoden en technieken geïntroduceerd, zoals bijvoorbeeld Exploratory Testing, Context Driven Testing, etc. Maar dit zijn meer paradigma’s die simplistisch gezegd, de testers meer bewust moeten maken van de wereld hen hen en van de omgeving waarin het informatiesysteem zal acteren.
Agile Software Development
De ontwikkeling van het testen binnen een Agile-omgeving heeft niets te maken met technieken maar juist meer met een mind-set bij een tester. De tester moet zich bewust worden van de context waarbinnen hij acteert. Daarnaast zal hij zich op een of andere manier moeten aanpassen van defect-hunter naar requirement-toetser. Waar de rol van de tester traditioneel er al een is van kwaliteitsbewaker, zal dat binnen een Agile-traject nog veel meer het geval zijn. De tester zal net als de ontwerper en ontwikkelaar moeten leren samen te werken met andere disciplines. De tester moet het besef hebben dat het vinden van laat defect (dus tijdens de testuitvoering) ook deels zijn verantwoordelijk is. De ontwikkeling van het vakgebied testen zit hem dus veel meer in de zachte kant van het vakgebied dan in de harde kwalificaties als methoden en technieken. Zoals Eugene Derksen al aan gaf in zijn opiniestuk in maart 2010, zijn er grote overeenkomsten tussen Agile Software Development (en Scrum in het bijzonder) en Exploratory Testing. Ook hier werd benadrukt dat de mindset van de tester de meeste aandacht nodig heeft in deze veranderende wereld.
Service oriented architectures
Service oriented architectures (SOA) zijn in principe een feestje dat wordt georganiseerd door de business, waarbij ict de middelen verschaft om een flexibele inrichting van het informatiesysteem te creëren. Binnen het testen van SOA’s zijn de niet-functionele systeemeisen nog vaak onderbelicht. Veel van deze eisen zijn aan te tonen door checklists (beheerbaarheid) of tooling (performance). Degene die het overzicht heeft hoe je bepaalde eisen zou kunnen toetsen of testen, is in veel gevallen de tester. Maar ook hier geldt dat er geen nieuwe technieken hoeven te worden geïntroduceerd voor het testen van services alleen of de services in het geheel van een constellatie. SOA-trajecten worden kenmerkend vaak ontwikkeld met behulp van Agile Software Development. Bij het testen van SOA-trajecten is het belangrijk dat er gekeken wordt naar de inpasbaarheid van het systeem binnen de bedrijfsprocessen, zeker bij de acceptatietesten.
Model Based Testing
Model Based Testing (MBT), is net als SOA een door techniek gedreven beweging. Net als bij een SOA geldt dat er bij MBT voor de tester een uitdaging ligt in het begrijpen van de context waarin het informatiesysteem draait en hoe je de diverse non-functionele eisen kunt aantonen. Kenmerkend voor MBT is dat de testactiviteiten door de hele ontwikkelcyclus heen worden uitgevoerd en niet meer zoals bij traditionele watervaltrajecten alleen maar aan het einde. Net als bij het testen van een SOA, geldt ook voor het testen bij MBT dat de nadruk moet liggen bij het acceptatietesten en de fit binnen de bedrijfsprocessen.
Conclusie
Concluderend kunnen we zeggen dat de uitdaging voor de tester niet meer zit in het begrijpen en kunnen toepassen van technieken, maar dat een tester zijn uitdagingen moet zoeken in het begrijpen van de context van een informatiesysteem. Kennis en kunde blijft een vereiste, maar dat wordt als vanzelfsprekend gezien. Een tester zal zijn uitdaging meer en meer moeten zoeken in het begrijpen van de context waarbinnen hij zijn werkzaamheden uitvoert.
Testers moeten twee vragen beantwoorden. Doet het infomatiesysteem wat het moet doen? Doet het informatiesysteem iets wat het niet mag doen? Misschien is dit wat Tom bedoeld met requirements toetsen en defect hunting. Beide vragen worden altijd en overal gesteld en moeten dus ook altijd en overal beantwoord worden. Welke vraag het belangrijkste is hangt van de business en niet van de gebruikte ontwikkelmethodiek. Zowel in waterval als in agile projecten moeten testers aantonen of requirements al dan niet zijn gerealiseerd. Iedereen vindt liever defects tijdens test dan in productie.
Testers doen er verstandig aan om eens uit de positie van kwaliteitsbewaker te stappen. De bewaker van de kwaliteit is/zijn de opdrachtgever(s) van het testtraject. Het gaat hier dus bijvoorbeeld om de projectleider, de producteigenaar, de delivery manager etc. De taak van de tester is om informatie te verzamelen zodat juist deze personen inzicht verkrijgen in de kwaliteit van het product.
De opmerking van Michel Kraaij is zeer terecht. Ik ben als tester vaak wel als “kwaliteitsbewaker” aangesteld, maar dat zat dan in de context van een project, waar de projectleider (of andere persoon) deze verantwoordelijkheid neerlegde bij de tester(s). Vreemd, gezien een tester wel veel weet van alle aspecten van een software product, maar in de meeste gevallen andere aspecten niet kan overzien, zoals de politieke situatie of besluiten op hoger niveau. De tester kan vaak geen goede inschatting over het geheel maken en niet de totale kwaliteit van een product binnen een organisatie beoordelen. Hierdoor is de rol ‘beperkt’ tot het leveren van zo goed mogelijke informatie over (grotendeels) technische aspecten van het product. Nu een andere (controversiële?) gedachte: De beoordeling van de totale kwaliteit van een nieuw IT product ligt dus vaak bij managers die ook weer niet gespecialiseerd zijn in het vak “kwaliteit”. Kwaliteits-specialisten op het hogere management niveau zijn wat mij betreft meer nodig, waarbij ik mij kan voorstellen dat veel van deze specialisten vanuit de rol van tester doorgroeien naar dit vak. Managers voor het bewaken van proces-kwaliteit en een kwaliteits-specialist voor de inhoudelijke kwaliteit met (inhoudelijke) inzicht op alle niveaus van kwaliteit wat gerelateerd is aan een IT product. Sluit ook weer aan op dit stuk, dat dit in eerste instantie geen techniek gerelateerde uitdaging is.
@Michel: je moet wel een onderscheid maken tussen de rol van tester in een project en het sturen van het project op de variabele kwaliteitszorg (naast tijd, geld en scope). Het artikel beoogt inzicht te geven in de rol van de tester in relatie tot zijn teamleden, terwijl jouw reactie er een is op programmamanagement niveau. Daar zit in de meeste projecten wel een paar lagen tussen 🙂
@Rob:
Dat een projectleider bepaalde taken bij jou neerlegt, dat kan. Echter, dat betekent niet dat hij zijn verantwoordelijkheid ook bij jou neer kan leggen. Verbazingwekkend dat veel projectleiders dit toch lijken te doen. Nog verbazingwekkender is het dat testers dit ook zomaaar accepteren. Testers zitten niet in de rol van projectleider. Nog zitten zij op een positie/rol waarin ze de kwaliteit van een product kunnen veranderen. Testers kunnen, net zoals je zegt, een bepaald aspect van het product aan het licht brengen. Deze informatie kan mogelijk helpen (maar soms ook tegenwerken) een besluit te nemen. Zij het over kwaliteit of over andere aspecten.
@Anko:
Heb ik iets gezegd waardoor jij mijn opmerking op programmaniveau hebt geplaatst? Bij mijn weten heb ik het alleen over de rol van de tester gehad. Misschien ben je van de wijs gebracht door de diverse benamingen van opdrachtgevers?
@Michel – Misschien valt er wel iets voor te zeggen in kleinere organisaties. Of om als organisatie (mgt) te benadrukken dat de testafdeling serieus wordt genomen. Ligt dus aan de context zou ik zeggen 😉