Onder testers is het idee ontstaan dat testen een creatieve bezigheid is. Dit is een misvatting; testen is in essentie niet creatief maar juist destructief. Het is daarbij wel goed om alle intellectuele vermogens aan te spreken en niet alleen de gebaande paden te begaan, maar het doel is nooit om iets nieuws te maken. De primaire taak van testers is om informatie te verschaffen en het enige dat zij daarmee creëren is duidelijkheid.
De vraag of een plan goed is uitgevoerd is bij softwareontwikkeling vaak niet met alleen met ‘ja’ of ‘nee’ te beantwoorden. In alle situaties waar dit wel zo is, kunnen we stellen dat testen zich beperkt tot het controleren of de software zich conform specificaties gedraagt. Hier komt weinig intellectuele uitdaging aan te pas; deze controles kunnen we dan ook automatiseren. Het uitvoeren van regressietestgevallen, handmatig of geautomatiseerd, is zonder twijfel de minst creatieve bezigheid in het testvak.
Proza over poëzie
Het verzinnen van deze testgevallen is ook niet heel erg creatief. Het toepassen van testtechnieken op specificaties is wel iets dat je moet leren, maar iedereen die dit onder de knie heeft, komt tot dezelfde logische testgevallen. De creativiteit in het testen moeten we dus zoeken in activiteiten die te maken met onvolledige of onduidelijke specificaties. Het is zelfs denkbaar dat testgevallen zelf de specificaties zijn. Dit gebeurt nog niet veel, maar het integreren van testactiviteiten in de ontwikkelcyclus is de enige manier om invloed te hebben op het moment dat software wordt gecreëerd, namelijk het moment dat de code wordt geschreven.
Als we programmeren vergelijken met poëzie dan kun je stellen dat ontwerpen en testen beide proza zijn. Dit proza heeft direct betrekking op de poëzie; het kan niet los daarvan bestaan. Het ontwerpen van software is het opstellen van rijmschema’s en het afbakenen van het onderwerp. Het is meestal de taak van de tester om achteraf een verhaal te maken over het gedicht. In het beste geval ontwikkelen de code en de tests zich tegelijk. Het resultaat is dan een programma met één beschrijving die tegelijkertijd het ontwerp en de test is.
Kunst van de kritiek
Testactiviteiten die het ontwikkelteam helpen om werkende software op te leveren zijn positief; ze dienen om aan te tonen dat de software werkt volgens verwachting. Op een zeker moment bereikt de software een mate van volwassenheid waarin een andere vraag belangrijk wordt: zijn er situaties waarin de software niet volgens verwachting werkt? Dit leidt tot negatieve testactiviteiten die er op gericht zijn om problemen aan het licht te brengen. Negatief testen vergt een totaal ander perspectief dan positief testen, mede omdat het niet uitsluitend gebaseerd is op specificaties. Is het daarmee creatief? Integendeel, negatief testen is gericht op het laten falen van de software; het is destructief.
Door het blootleggen van zwakke punten stellen testers anderen in staat om software te verbeteren. Door het vertellen van een informatief verhaal over de software leveren testers indirect een bijdrage aan het scheppend moment. Dit verhaal moet zo eerlijk mogelijk zijn, dus testers hoeven niets te verzinnen. Wel moeten ze zich continu afvragen hoe betrouwbaar hun informatie is, anders bestaat de kans dat ze sprookjes vertellen; heel creatief, maar ook contraproductief.
Het testvak is niet creatief; testers ondersteunen degenen die het scheppende werk doen. Softwaretesten is wel een kunst, iets waar je goed in kunt worden, maar het is de kunst van de kritiek. Oplossingen testen is problemen zoeken.
[Dit artikel is een bewerking van mijn artikel ‘Oplossingen testen is problemen zoeken’ dat eerder is verschenen in de TestNetNieuws, een uitgave van TestNet, de beroepsvereniging van softwaretesters in Nederland.]
Aj, een ontwikkelaar die zich beperkt voelt door de tester… Het werk van de tester bestaat bij de gratie van de ontwikkelaar… Creatief en Destructief zijn tegengestelden… Beste Bert: of je bent nog geen goede testers tegengekomen en je problemen zijn echt, of je lijdt aan het waanidee dat ontwikkelaars het centrum van het universum zijn. Overigens zijn er ook veel testers die vinden dat zij verantwoordelijk zijn, of de trekker zijn, van alles wat zich binnen software ontwikkeling afspeelt, maar dat keert niet als bijkomend probleem terug in het stuk.
Ik sluit me bij de meeste reacties aan: testen is JUIST zoveel mogelijk creatief bezig zijn, waarbij het minst interessant is het vergelijken van het product met de specificaties en ‘zien dat het is zoals beschreven’. De vergelijking van poezie en proza is misplaatst; hoewel de tester niets lijkt te bouwen en de ontwikkelaar wel zijn beide takken van sport belangrijk om een opdrachtgever het vertrouwen te geven dat de gevraagde oplossing geen problemen op gaat leveren. Even belangrijk. Dus wat mij betreft creëert een ontwikkelaar poezie en een tester ook, nog met hetzelfde thema in gedachten ook, maar met een volslagen andere invalshoek.
Ik kijk uit naar een nieuw artikel, hopelijk na wat positieve ervaringen met goede testers.
Nou, dan toch even mijn plasje. Leuk artikel om te lezen, omdat het prikkelt aanzet tot denken en reacties uitlokt.
Mijn perspectief: Ik ben voornamelijk (database) ontwikkelaar geweest in het verleden.
Het is vrij simpel. Het is allemaal niet zo zwart wit.
Ontwikkelen is soms poezie en creatief, maar vaak is het ook gewoon noeste (saaie) arbeid vooral als het product al (lang) in productie is en er dingen gewijzigd, aangepast en onderhouden moet worden. Vergt vaak ook een andere ontwikkelaar.
Zelfde geldt voor testen. Ik heb een “hekel” aan testers omdat ze vaak zo goed en punctueel zijn en dat leidt tot noeste arbeid voor de ontwikkelaar. Gedachten uitwerken naar code is leuk, alles wat erna komt mist het creatieve en is vaak dus saai.
Voor de tester is een testplan en dergelijke opzetten best leuk. Maar na een iteratie of tien waarin je alles *weer* moet doorlopen voor de zekerheid, dan is dat echt niet leuk of creatief.
De uitspraken zijn dus soms of vaak waar, maar zeker niet altijd.
Grapppig detail overigens. Testen is ook een vorm van produceren (al zijn het testresultaten) en dat kun je weer niet destructief noemen… die weerbarstige realiteit ook altijd!
@ Henri Koppen. Wanneer je na een ‘een iteratie of tien waarin je alles weer moet doorlopen’ doe je toch iets niet goed lijkt me. Zo’n klus kun je vaak automatiseren. Zelfs binnen een enkele iteratie zou ik in zo’n geval kijken hoe je handmatige handelingen kunt voorkomen. Dit vergt overigens creativiteit.
Persoonlijk ben ik van mening dat een goede (!) tester zich juist onderscheidt door creativiteit en verder buiten de kaders van Tmap kan acteren.
Hartelijk dank voor alle reacties.
Het lijkt er op dat ik een gevoelige snaar heb geraakt. Dit heeft er volgens mij mee te maken dat “creatief” een positief beeld oproept en “destructief” een negatief beeld. Die beelden kloppen niet altijd: het creëren van een laagwaardig product is helemaal niet positief, het slopen van een dergelijk product is juist een goede zaak.
Het gaat dus om de kwaliteit van het product en die maken we inzichtelijk door te testen. Volgens mij is de essentie van testen het zoeken van zwakke plekken. Hoe beter het product is, hoe lastiger het is om zwakke plekken te vinden. Dit maakt testen uitdagender, moeilijker en leuker, maar niet creatiever. We maken nog steeds niks. We brengen hoogstens iets teweeg; we leveren informatie, creëren duidelijkheid en in het beste geval scheppen we daarmee een beetje orde in de chaos.
Als we niet eerlijk tegen onszelf kunnen zijn, hoe kunnen we dan eerlijk zijn tegen anderen?
Bert,
Leuk om te zien dat dit artikel zoveel reacties veroorzaakt. Echter, ik ben het totaal niet eens met je stelling.
De essentie van testen is het aantonen of een product goed genoeg is. Een tester welke uitsluitend gericht is op het vinden van fouten heb je weinig aan. Teminste, ik zou ‘m niet in mijn team willen hebben.
Je stelt dat testers niets maken. Echter we maken een teststrategie, testontwerp, handmatige en geautomatiseerde testgevallen, waarmee we met zo min mogelijk inspanning zoveel mogelijk willen raken. Mijn ervaring is dat, wanneer je dit echt goed wilt doen, je creatiever moet zijn dan wat het TMap boek je voorschrijft. Een goede tester weet verder te kijken dan het testdomein en is in staat om tot nieuwe testtechnieken te komen, welke het beste passen bij het betreffende testproject.
Verder geef je aan dat uiteindelijk alle testers tot dezelfde logische testgevallen komen. Zou dat echt zo zijn, dan stel ik voor dat we alle seniore testers ontslaan en de vacatures allemaal later vervullen door uitzendkrachten met een korte Tmap cursus.
Testen is destructief, volgens de Dikke van Dale betekent dit ‘geneigd tot vernietigen’ en hiermee zou je dan inderdaad een klein deel van testen kunnen beschrijven. Klein deel, want met testen zijn we niet aan het vernietigen, maar juist informatie aan vergaren. Daarbij zijn proefjes zoals een digitaal bommetje op een web applicatie werpen wellicht een onderdeel van testen.
Programmeren kan ook destructief worden beschouwd als je het in relatie brengt met de mogelijkheid dat je een aantal banen aan het weg automatiseren bent.
Als ik denk aan een activiteit wat niet creatief is, moet ik gelijk denken aan de film ‘Modern Times’ van Charlie Chaplin, waar Chaplin tot vervelens toe aan een moer loopt te draaien (en hier overigens compleet gestoord van wordt). Het maken van software lijkt niet erg op zo’n fabrieksproces, wellicht in onderdelen. Druk op knop: compileer, start automatische test, genereer grafiek…
Creativiteit is een proces wat loopt van een probleem analyse naar een oplossing. In de ICT proberen we een technische oplossing te verzinnen voor een probleem. In een project moet er aardig creatief nagedacht worden. Dit om problemen op te lossen die ons in de weg staan om überhaupt goede software te kunnen maken.
En daar kom je op een term zoals ‘groepscreativiteit’, waar alle aspecten van het maken van software bij elkaar een creërend proces vormen. De tester is dan onderdeel van deze groep en draagt dan hier ook aan bij. Net zoals de projectmanager bijdraagt of de beheerder, de sales meneer, de secretaresse. Zelfs de pizza leverancier draagt dan een steentje bij.
Ik zie testen niet als een apart onderdeel (moer aandraaien in een fabricageproces), maar als een onderdeel van het creëren van software met een team van mensen. En hierbij zie ik de destructieve kant van testen niet.
Dus testers kunnen niet creatief testen? En testers dragen niet bij aan de creatie van software die voldoet aan overeengekomen specificaties? En testers scheppen geen duidelijkheid over de kwaliteit van (tussen)producten?
Als testen destructief zou zijn zal geen ontwikkelaar zijn productie aanbieden aan testers; ze zouden er geen spaan heel van laten. Maar omdat een ontwikkelaar weet dat wat hij creëert alleen maar beter wordt als het onder de loep van de tester heeft gelegen, zal hij met professioneel plezier zijn creaties ter test aanbieden.
Het samenspel van gebruiker, analist, ontwikkelaar en tester behelst het totale creatieve proces waarmee voortdurend wordt gewerkt aan verbetering (denk aan de aloude PDCA cyclus).
Testen positioneren als niet creatief en zelfs destructief is daarom naar mijn smaak te kort door de bocht.
Creatief en destructief zijn voor zover ik weet niet elkaars tegenstellingen.
Je schrijft zelf “Door het blootleggen van zwakke punten stellen testers anderen in staat om software te verbeteren”
Dat maakt testen niet destructief, maar juist constructief!
Verder kan je het testen zo creatief maken als je zelf wilt. Ik geef toe, voor een junior tester die alleen maar testscripts uitvoert zal dit minder gelden dan voor een ervaren tester in een scrum team.
Bert,
Als gevolg van een opeenstapeling van denkfouten kom je nu tot de onjuiste conclusie dat het testvak niet constructief of creatief is, maar destructief. Op basis van je voorgaande artikelen wil ik nagaan waar deze denkfouten zijn ontstaan en hoe deze zijn op te lossen.
Met je eerste opiniestuk “Toolselectie voor automatische testuitvoering” is niets mis; een prima, goed leesbaar verhaal, waarin je een aantal aandachtspunten formuleert voor het selecteren van een testautomatiseringstool. Dit uitstekende verhaal levert wel direct mijn eerste punt van verbazing op: hoe kun je nu keer op keer beweren dat testers niets maken, als alleen al testautomatisering een aspect van het testvak is waarin testers aantoonbaar even constructief en creatief zijn als ontwikkelaars? Waar ontwikkelaars (of beter: de eindgebruikers binnen de organisatie) uitkijken naar steeds krachtigere programmeertalen, waarmee steeds sneller functionaliteit kan worden gerealiseerd (5GL?), zijn testers evengoed op zoek naar steeds krachtigere testscripttalen, waarmee steeds sneller functionele testen, integratietesten (SOA!) en regressietesten opgezet kunnen worden.
Met enkele collega’s gebruik ik sinds enkele jaren een op TestFrame gebaseerde testscript-generator, waarbij templates met eenvoudige selectie en iteratie-instructies worden toegepast. Deze aanpak heb ik al eens beschreven in een reactie op “Geautomatiseerd testen is een abc’tje” dat eind 2009 verscheen.
De eerste belangrijke denkfout doet zich voor in je tweede opiniestuk: “Tester moet kennis van testdomein hebben”. Om een aantal redenen is het mijns inziens niet zinvol om onderscheid te maken tussen positief testen en negatief testen.
Positief testen
= bevestigend testen
= controleren
Doet de applicatie wat het moet doen, zoals voorgeschreven in functionele documentatie (de specs).
Kan door middel van (geautomatiseerde) testscripts.
Negatief testen
= niet-bevestigend testen
= exploratief testen
Doet de applicatie NIET wat het moet doen; het zoeken naar foutsituaties die niet zomaar van functionele specificaties zijn af te leiden.
Kan niet door middel van (geautomatiseerde) testscripts.
Het probleem met negatief testen is dat het nogal veel overeenkomst heeft met agile testen, zoals ook blijkt uit je derde opiniestuk: weinig of geen documentatie, niet automatiseerbaar met testscripts (hoewel dit punt inmiddels is rechtgezet in het uitstekende artikel ‘Testautomatisering in een Agile omgeving’ van René de Jong cs).
In mijn optiek kan elk geautomatiseerd testscript zowel aantonen dat een applicatie doet wat het moet doen als aantonen dat er nog fouten in zitten. De proefgevallen die met een script tot stand worden gebracht kunnen afgeleid zijn van documentatie (functionele ontwerpen) maar kunnen ook tot stand komen op basis van kennis van de business en gezond verstand. Het is hierbij evident dat complexe gevallen in integratietesten een veel grotere kans geven om fouten aan het licht te brengen dan eenvoudige, gladde gevallen (hoewel ook die laatste in geval van nieuwe functionaliteit eerst fout kunnen gaan).
De drie onjuiste conclusies die het gevolg zijn van het onterechte onderscheid tussen positief en negatief testen:
1. Exploratief testen is verkennend testen bij gebrek aan documentatie.
2. Exploratief testen is niet uitvoerbaar met testautomatisering.
3. Exploratieve (lees: agile-) testers kunnen zich onderscheiden; traditionele testers zijn een commodity (zoals je stelt in een reactie naar aanleiding van je derde opiniestuk).
Conclusie 1 is te beperkt, want exploratief testen is zeer aan te bevelen bij complexe applicaties met een overvloed aan functionele documentatie. Het is zeer leerzaam en informatief om op basis van businesskennis en gezond verstand complexe gevallen tot stand te brengen en te kijken wat de applicatie doet.
Conclusie 2 is onjuist: testautomatisering maakt exploratief testen juist bij uitstek mogelijk.
Conclusie 3 is ook onjuist. Het zijn juist de functionele en technische testers – in jouw optiek de traditionele testers – die de vaste grond cq. fundering leveren waar agile testers zo naarstig naar op zoek zijn. Zie ter aanvulling ook mijn reactie op ‘De rol van de tester verandert’.