Meer testers aan de knoppen

Door Eibert Dijkgraaf ● Eibert.Dijkgraaf@praegus.nl ● @EibertD
We willen ‘meer blauw op straat’ en ‘meer handen aan het bed’. Bekende kreten die zijn ontstaan uit onvrede over doorgeslagen bureaucratie. Bij de politie en in de zorg komen ze niet meer aan hun kerntaken toe, zoals boeven vangen of mensen verzorgen.
Op het gebied van softwaretesten is een vergelijkbare roep te horen. Als je goed luistert, hoor je de roep ‘meer testers aan de knoppen’. Weg van de bureaucratie; testers moeten weer gaan testen! Onderwerpen als Context Driven Testing, Rapid Software Testing en Exploratory Testing vinden een vruchtbare voedingsbodem in alle frustraties over overbodige testdocumentatie en onzinnige testgevallen.
Deze roep zal ongetwijfeld ons vakgebied beïnvloeden. Hoe heeft het zover kunnen komen? Waarom is de roep ontstaan? En nog belangrijker; zijn we op de juiste weg om een goed antwoord te vinden?
Een stukje historie
Een manier om de ontwikkeling van het softwaretesten (op hoofdlijnen) te duiden is via de ‘scholen’. Dit zijn stromingen in ons vakgebied die onder andere beschreven zijn door Brett Pettichord [ref. 1]. In de figuur worden er vijf onderkend, in een onderlinge samenhang.

De eerste testen ontstonden in de wereld van het programmeren. Gestructureerde technieken werden toegepast op de code en zo ontstond een analytische vorm van testen. De toenemende automatisering leidde tot een groeiende vraag voor testers. Het werd een vakgebied op zich waarbij er naast analytische testers ook steeds meer functionele testers kwamen, zonder programmeerervaring. Wel nam het testwerk in kwantiteit enorm toe. Zo ontstond er een nieuwe behoefte aan structuur. Deze keer niet zozeer inhoudelijk, maar meer op het proces. Hoe kom je tot een goede teststrategie en verstaan we elkaar in de communicatie? Dit heeft geleid tot de ontwikkeling van standaarden en methodieken. Dit heeft geholpen in het volwassen worden van het testvak. Afspraken zijn beter te maken en de randvoorwaarden worden beter ingevuld.
De voorkeur voor een ‘school’ wordt mede bepaald door de culturele achtergrond. Wat inzicht in het Rijnlands model en het Angelsaksisch model helpt om te begrijpen en mogelijk te verklaren hoe de ontwikkeling is doorgegaan. De volgende tabel geeft een globale indruk van de verschillen. Voor meer informatie zie [Ref. 2].

Met name in de wereld van het Rijnlandse model, met veel aandacht voor middellange- en langetermijndenken, zijn de teststandaarden en -methodieken in gebruik genomen. Zo ontstond er ruimte voor beheersing en controle. De aandacht voor kwaliteit heeft zich doorgezet in de preventieve toepassing. Voorkomen is beter dan genezen. De kwaliteitszorg kreeg vorm en een deel van de testers is als QA-specialist verder gegaan.
Naast preventie zijn snelheid en wendbaarheid ook prominent naar voren gekomen. De agile ontwikkeling kreeg vorm, inclusief het nauw verbonden testen en een deel van de testers moet daarin mee en past zich wederom aan (met vallen en opstaan).
Deze ontwikkelingen beïnvloeden elkaar en de kennis ontwikkelt door. Het is dus niet zo dat je in één specifieke school thuishoort, waarbij je je kan onttrekken aan de kennis van het voorgaande.
Tegelijkertijd met de ontwikkeling van standaarden en methodieken heeft in de Angelsaksische wereld het testen zich op een andere voedingsbodem ontwikkeld. Particulier initiatief en zelfredzaamheid zijn daar belangrijker dan processen voor de langere termijn. Deze kenmerken zijn ook herkenbaar bij het Context-Driven testen. De persoonlijke ‘drive’ is een belangrijke succesfactor. Het zijn niet de processen en methodes die je vertellen hoe je succesvol moet testen. Maar je wordt succesvol door je eigen ervaringen, de heuristieken en de mentale modellen die je kunt toepassen. Het voortschrijdend inzicht deel je wel met de community want daardoor leer je zelf ook weer het meest.
Een stukje discussie
De laatste tijd is er veel aandacht geweest voor de verschillen tussen de ‘scholen’. Gezien de toon van de discussie lijkt er sprake van een bloedgroepenstrijd en een onverenigbaarheid van de ‘scholen’. Bij extreme standpuntbepalingen wordt vaak ingeha(a)kt op de tekortkoming van de andere aanpak.
Maar iedere ontwikkeling kent zijn onderbouwing en heeft op die plaats en tijd zijn waarde. Bewezen methoden, en daar mag je het bij de beschreven ‘scholen’ toch wel over hebben, ontlenen hun bestaansrecht aan sterke punten die onder bepaalde omstandigheden tot succes leiden.
Inzicht in het ontstaan kan leiden tot meer begrip voor de verschillende visies. Niet alles is zo zwart/wit als in de discussie wordt geponeerd. De ontwikkelingen zijn verklaarbaar en hebben een reden.
Het is een groot goed als we beseffen dat wij als individuen en dus ook als testers, allemaal zijn beïnvloed door onze cultuur en achtergrond. Dat geldt ook voor onze organisaties. De ene organisatie hecht veel waarde aan strakke processen, terwijl de ander veel creativiteit toelaat en persoonlijk ontwikkeling voorop stelt. Deze omstandigheden maken de ultieme keuze voor één manier van testen lastig, want zowel bedrijfscultuur als persoonlijkheden bepalen daardoor mede of een aanpak succesvol zal worden.
Een stukje praktijk
Interessant is om voor jezelf te overwegen of de ervaren tekortkomingen bij een bepaalde aanpak inherent zijn aan de methodiek of dat ze ontstaan door een gebrekkige toepassing. Daarom ter afsluiting enkele voorbeelden uit de discussie.
Zo wordt verteld dat een methode als TMap te dik is aangezet en leidt tot onnodige testdocumentatie. Maar wordt er dan wel adaptief gewerkt? Waar staat dat je overbodige documentatie moet schrijven? Je bent zelf verantwoordelijk voor de documentatie. Zorg er dus voor dat die naadloos de boodschap verwoordt die jij wilt.
Ook wordt ervaren dat het gestructureerd specificeren op basis van ontwerpdocumentatie te vaak leidt tot onzinnige testgevallen. Het ontevreden gevoel wordt versterkt als de tester domweg van papier gaat uitvoeren en niet meer reageert op wat er gebeurt. Het goed toepassen van testontwerptechnieken op basis van een strategie, zou je juist in staat moeten stellen om een bewuste keuze te maken van wat je wel en niet wilt testen. Goed toepassen van gestructureerde specificaties kan dus ook voorkomen dat onzinnige testgevallen worden uitgevoerd.
Wat nog wel eens wordt vergeten is dat ontwerpdocumentatie maar een deel van de beschrijving is. Als tester moet je bij het specificeren juist dan ook op zoek naar datgene wat niet beschreven is. Dat is een creatief proces, waarbij ervaring zeker helpt om hierin te groeien. Bij de uitvoering blijft een techniek als Error Guessing van grote waarde om juist interactief met het testobject te kunnen acteren en te kunnen inspelen op voortschrijdend inzicht.
Anderzijds ontstaan rondom het Context-Driven testen ook mythes. Een voorbeeld is de bewering dat er bij Exploratory Testing geen sprake meer is van testspecificaties. Of erger nog, dat je überhaupt alle documentatie achterwege kunt laten. Of dat het gebruik van metrieken uit den boze is. Dergelijke beelden worden niet alleen door tegenstanders gemaakt, maar ze worden gevoed door het onkundig gebruik. Een interessante blog hierover is door James Bach geplaatst op zijn eigen site: http://www.satisfice.com/blog/archives/924. Hij weerlegt daarin een aantal beelden die zijn gegroeid rondom Exploratory Testing.
Een stukje conclusie

Wat wil ik met deze voorbeelden zeggen? De gevolgde of voorgeschreven methodiek is geen excuus waarom de klant niet geïnformeerd kan worden over de kwaliteit van zijn product. Elke aanpak kent zijn voor- en nadelen, maar de belangrijkste succesfactor is met name het vakmanschap van de tester zelf.
Om dat vakmanschap te voeden móeten we testinhoudelijk van elkaar leren.
Bij de training Rapid Software Testing (vanuit de Context-Driven ‘school’) krijg je een duidelijk advies: zorg dat je zoveel mogelijk daadwerkelijk test. Met andere woorden, als je een tester bent, dan moet je testen. Laat je niet teveel afleiden door andere zaken eromheen. Ik moest terugdenken aan mijn eerste lessen in het testvak, gebaseerd op TMap: bereid je goed voor, zodat je tijdens de uitvoering, op het kritieke pad, zoveel mogelijk kunt testen.
Voor mij was daarmee de schijnbare tegenstelling opgelost en kreeg ik nog meer mogelijkheden om als tester aan de knoppen te zitten.
Referenties
1. Schools of software testing (Brett Pettichord) – http://www.prismnet.com/~wazmo/papers/four_schools.pdf
2. http://managementscope.nl/magazine/artikel/681-verschillen-angelsaksisch-rijnlands-model