Testen is destructief

03-01-2013 11:39 | Door Bert Wijgers | Lees meer artikelen over: Testing | Er zijn 19 reacties op dit artikel | Permalink
Computable Expert
Bert Wijgers
Bert Wijgers

Softwaretester

Expert van Computable voor het topic Development

Meer

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.]
Reacties op dit artikel
De redactie vindt deze reactie: OKeen échte tester, 03-01-2013 13:11
Ik moet zeggen dat ik het creatief vind om een artikel van meer dan een A4tje te schrijven zonder dat je iets zegt. Ik krijg de indruk dat de heer Wijgers het testvak beu is of gewoon een slechte dag heeft gehad.
 
Als hij realistisch naar zijn vak zou kijken (volgens zijn linkedin pagina is hij wel degelijk gewoon een tester), zou hij constateren dat testers een duidelijk standpunt innemen, iets dat hij in dit artikel achterwege laat.
 
Om een lang verhaal kort te maken: Wat is nu eigenlijk het standpunt dat de heer Wijgers in dit artikel aanneemt? Een A4tje vol afzwakkingen van zijn eigen argumenten.
De redactie vindt deze reactie: OKLex van Gestel, 03-01-2013 13:13
Je kunt testen ook zien als het vinden van openingen in het verbeterproces (positief) eerder dan het gatenschieten (negatief).
Ik zou dus eerder zeggen dat testen een creatief proces is om met alle intellectuele vermogens buiten de gebaande paden te treden teneinde informatie te verstrekken om de wereld te verbeteren.
De redactie vindt deze reactie: OKMichiel Croon, 03-01-2013 13:33
Waarom moeten creativiteit en destructiviteit elkaar in deze context uitsluiten? Als ik voor het handmatige deel van het testen een applicatie moet laten omvallen, dan zou ik daar met reproduceerbaarheid als randvoorwaarde zo creatief mogelijk in willen zijn, des te groter de kans dat je ergens tegenaan loopt. Uiteraard leg je een aantal testscenario's vooraf vast maar daar zou ik me niet door laten beperken.
De redactie vindt deze reactie: OKEgbert Bouman, 03-01-2013 13:33
Bert, je creeert een onzuivere tegenstelling: creatief en destructief zijn geen tegenpolen maar gaan in deze context juist samen. Ik zeg het liever zo: een goede tester is "constructief kwaadaardig". Lees hoofdstuk 6 van "SmarTEST, slim testen van informatiesystemen" eens, ik ben benieuwd wat je daarvan vindt.
 
In tegenstelling tot Reginald ben ik het overigens wel met je eens dat testen of iets conform specs is in essentie niet creatief is. Ik ben ook met je eens dat veel testers op deze wereld niet uitblinken in creativiteit. Dat hoeft ook niet altijd: van je accountant verwacht je ook niet elke dag nieuwe sprongen.
 
Maar 1. een slim testontwerp en een slimme exploratieve strategie vergen wel degelijk creativiteit en 2. goede testers zijn goed in negatief testen: doet het NIET wat het NIET mag doen. Dat vergt 'Out of The box' denken en creatief verbanden leggen en daar zijn veel mensen niet zo goed in.
 
Misschien is de moraal: testers zijn niet altijd even creatief, maar goede testers zijn dat wel.
De redactie vindt deze reactie: OKEgbert Bouman, 03-01-2013 13:35
Michiel, je zou het niet zeggen als je onze openingszinnen vergelijkt, maar ik las jouw bijdrage echt pas na het plaatsen van de mijne :-).
De redactie vindt deze reactie: OKWim de Bok, 03-01-2013 14:09
Wat is nu de zin om zo een denigrerend artikel over testen te schrijven? Het is naar mijn mening wel degelijk een creatief vak om goede testgevallen voor applicaties te bedenken en daarbij misschien ook extremen te testen en applicaties onder druk te zetten. En ook iets waar de ontwikkelaar aan kan bijdragen om de juiste testgevallen te bepalen. Kan zelfs nog heel leerzaam voor de ontwikkelaar zijn want die hebben misschien ook wel niet alle wijsheid in pacht of iets over het hoofd gezien. Ontwikkelen is een gezamenlijk activiteit waarin de testers ook hun belangrijke rol spelen.
De redactie vindt deze reactie: OKMichiel Croon, 03-01-2013 14:22
Goede timing Egbert! En mooi wat je zegt over het negatief testen (een dubbele ontkenning is normaal gesproken ongewenst, je stelt terecht dat out(side) of the box denken van belang is).
 
Het opiniestuk nogmaals lezende kom ik nog tot het volgende:
 
Bert geeft in zijn inleiding aan dat het nooit het doel is om "iets nieuws" te maken. Daar kan ik me op zich wat bij voorstellen.
 
Creativiteit kun je echter zowel aanwenden voor het resultaat dat je oplevert, maar ook voor de weg daarnaartoe (het proces). En dat sluit dan weer mooi aan bij jouw opmerking over een exploratieve strategie.
De redactie vindt deze reactie: OKAp Schouten, 03-01-2013 14:24
Het artikel is wellicht bedoelt om reacties uit te lokken, nou hierbij dan ook de mijne. Ik zie het als volgt:
Als ik in een vliegtuig plaatneem dan heb ik liever niet een creatieve piloot maar iemand die gestructureerd alle pre-takeoff checks doet. Dus problemen voorkomt i.p.v. ze op te lossen onderweg.
 
Overigens wordt met toepassing van Agile processen in softwareontwikkeling er veel meer creativiteit vereist van alle betrokkenen, ontwikkelaars, architecten en testers. Dus het artikel is wellicht alweer verouderd.
De redactie vindt deze reactie: OKarjan schouten, 03-01-2013 14:49
Een tester moet wel creatief zijn. Ik vindt dat een programmeur en tester heel dicht bij elkaar liggen. Eigenlijk vindt ik het testen een onderdeel van het programmeur zijn.
De redactie vindt deze reactie: OKChris, 03-01-2013 14:49
Ik ben het met Egbert eens, testers zijn niet altijd creatief, goede testers zijn dat wel!
 
Dat testen conform specs geen creatieve bezigheid is weten we. Sterker nog er zijn mensen (zoals bijvoorbeeld Michael Bolton) die het onderscheid maken tussen testen en checken. Waarbij checken het "simpelweg" nalopen van de specs is. Zeg maar valideren.
 
Testen daarentegen is een creatief proces waarin je probeert nog onbekende informatie in te winnen over het product waar je aan test. Onderzoeken, ontdekken en leren zijn daarin van belang.
 
Ik hoop dat er steeds meer mensen gaan testen...
 
De redactie vindt deze reactie: OKBart Fessl, 04-01-2013 11:48
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.
De redactie vindt deze reactie: OKHenri Koppen, 04-01-2013 15:53
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!
 
De redactie vindt deze reactie: OKRene, 04-01-2013 17:32
@ 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.
De redactie vindt deze reactie: OKBert Wijgers, 05-01-2013 0:08
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?
De redactie vindt deze reactie: OKRene, 05-01-2013 14:41
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.
De redactie vindt deze reactie: OKRob van Steenbergen, 05-01-2013 19:48
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.
De redactie vindt deze reactie: OKHans Kroon, 07-01-2013 13:30
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.
De redactie vindt deze reactie: OKagile_tester, 08-01-2013 13:01
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.
De redactie vindt deze reactie: OKJack Jansonius, 24-01-2013 11:50
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’.
 
Gerelateerde artikelen

03-10-13  Sogeti: Testen is dood, leve de tester

92 vacatures
docent Software Engineering

Hogeschool van Amsterdam , Amsterdam

Developer

Matthat Sofware B.V. , Gouda

Web Developer ASP.NET C# (Medior / Senior)

NiDiDo BV , Barneveld

PHP Programmeur

BWSS B.V. , Deventer

.NET (C#) Programmeur

Let's build IT , Hoorn NH

Top 10 Reagerende members
  Aantal reacties
met 3+ sterren
Gemiddelde
waardering
Klik voor meer info1 1575 6.2
Klik voor meer info2 1305 6.0
Klik voor meer info3 1272 6.2
Klik voor meer info4 1072 6.2
Klik voor meer info5 1000 6.1
Klik voor meer info6 901 6.1
Klik voor meer info7 755 6.2
Klik voor meer info8 528 6.1
Klik voor meer info9 405 6.2
Klik voor meer info10 399 6.0