Wat gebeurt er als we de beroemde vier waarden van het Agile Manifesto toepassen op het testen van software, ongeacht de ontwikkelmethode die wordt gebruikt? Het blijkt dat agility bij het testen iets anders is dan het testen in agile-projecten. Testen op een agile manier lijkt eigenlijk heel veel op exploratory testen.
Voordat we naar de waarden van het Agile Manifesto (Beck en anderen, 2001) gaan, wil ik het verschil aangeven tussen tests en controles (Bolton, 2009). Controleren of een systeem werkt volgens de specificaties kan worden geautomatiseerd, en als dezelfde controle vaak gedaan moet worden, is het vaak de moeite waard om dit ook te doen. In tegenstelling tot het controleren, kan het testen niet worden geautomatiseerd. Wanneer specificaties niet compleet zijn of niet helemaal geldig, is de menselijke intelligentie nodig is. Aangezien specificaties nooit compleet zijn en nooit helemaal geldig, zullen menselijke testers altijd nodig zijn. Controleren is het op zoek gaan naar de bevestiging dat alles in orde is, testen is het op zoek gaan naar problemen.
Mensen en interacties boven processen en tools
We testen namens anderen, dus we moeten ons voorstellen hoe die anderen een stuk software zouden ervaren. Daarom moeten we weten wat ze nodig hebben en wat ze willen. Documentatie is hierbij niet meer dan een gebrekkig hulpmiddel. Dat geldt ook voor mondelinge communicatie, maar in face-to-face interactie is er de bonus van non-verbale communicatie. In het softwareontwikkelproces is de menselijke geest het belangrijkste instrument. De beste manier om het testen te verbeteren is dan ook door training van individuele testvaardigheden, waaronder nadrukkelijk ook de soft skills.
We zijn gewend om te praten over tools als software die het ontwikkelproces van een ander, nieuw stuk software ondersteunt. In bredere zin is een tool iets dat kan worden gebruikt om iets anders te maken. Documentatie kan ook worden beschouwd als een tool bij het ontwikkelen van software. Een specifieke vorm van documentatie is de beschrijving van de processen. Processen gebeuren, of ze gedocumenteerd zijn of niet. De mate waarin ze gedocumenteerd worden, is een keuze. Dan zijn er nog generieke procesbeschrijvingen, ook wel bekend als methoden. Deze zijn ook te beschouwen als tools; ze mogen dus nooit leidend zijn, maar ze moeten zorgvuldig worden gekozen en verstandig worden gebruikt. Wat betreft best practices – die bestaan niet. Er zijn alleen good practices onder bepaalde omstandigheden (Kaner en Bach, 2009).
Werkende software boven uitgebreide documentatie
De meest directe manier waarop het testen van bijdraagt aan werkende software is door bevindingen. Als die bevindingen worden opgelost, wordt de software beter. Elke activiteit die niet bijdraagt aan het doen van bevindingen moet zoveel mogelijk worden beperkt. Testscripts mogen daarom niet te gedetailleerd zijn, net zomin als de testplannen. Aangezien een tester geen bevindingen kan doen terwijl hij bezig is met het schrijven van scripts of plannen, moet de tijd die besteed aan wordt het maken van deze documenten zo kort mogelijk zijn. Bevindingenrapporten zijn de belangrijkste documenten die een tester schrijft.
In exploratory testing (Bach, 2003) is de voorbereidende documentatie niets meer dan een missie. De missie beschrijft ruwweg waar te zoeken naar wat voor soort problemen. Met niets anders dan deze missie, zijn vaardigheden, een toolkit en een ononderbroken tijdsspanne, gaat een tester op zoek naar bevindingen. De testuitvoering kan worden vastgelegd. Meestal is het een goede gewoonte om een exploratory testsessie te debriefen; de tester vertelt, meestal aan zijn teamleider, wat hij heeft gedaan en waarom. Daarbij geeft hij een idee over de testdekking en hij leert steeds beter na te denken over zijn eigen werk.
Samenwerking met de klant boven contractonderhandelingen
Aangezien we testen namens anderen is het ideaal als die anderen beschikbaar zijn. Zij geven ons ideeën en zij kunnen ons vertellen of onze tests zinvol zijn. Idealiter testen we ook samen, waarmee we kennis van zaken en testvaardigheden combineren, om de kans op relevante bevindingen te optimaliseren.
Als tester zul je niet vaak een rol spelen in de contractonderhandelingen, maar je zult worden gevraagd naar de kwaliteit van de software. Is het product goed genoeg? De waarheid is dat je dat niet weet. De enigen die dat weten zijn de eigenlijke gebruikers, op het moment dat ze het gebruiken. Dus als de vraag wordt gesteld, maak dan duidelijk dat kwaliteit niet kan worden gekwantificeerd. Criteria voor acceptatie kunnen niet worden uitgedrukt in termen van het aantal onopgeloste bevindingen met een bepaalde ernst, want het is niet te zeggen hoe deze bevindingen het daadwerkelijke gebruik van de software zullen beïnvloeden. En hoe zit het met de bevindingen die je hebt gemist? Het enige dat je zeker weet, is dat ze bestaan, maar niemand weet hoeveel het er zijn en hoe ernstig ze zijn. Wat je kunt doen, is wijzen op wat er is gedaan om te verzekeren dat het product doet wat het moet doen en wat er is gedaan om te zoeken naar problemen.
Reageren op verandering boven het volgen van een plan
Bij softwaretesten komen geschreven plannen in twee varianten voor: testplannen en testscripts. Vaker wel dan niet worden die geschreven voorafgaand aan de testuitvoering en in de tussentijd vinden veranderingen plaats. Eisen veranderen, risico's veranderen, de software zelf verandert. Testplannen kunnen vrij gemakkelijk worden aangepast aan die veranderingen, en dat zou ook moeten. Testscripts aan de andere kant, bevatten vaak een hogere mate van detail en zijn minder flexibel. Daarom, indien nodig, moeten die zo laat mogelijk worden geschreven.
Het ontwerpen van tests is het plannen van testuitvoering. In exploratory testing is het resultaat van een test van invloed op het ontwerp van de volgende test. In tegenstelling tot bij testuitvoering volgens een script, waarin de tests voorafgaand aan de testuitvoering worden bepaald, wordt het testen beïnvloed door de kennis die wordt opgedaan tijdens het testen. Exploratory testing is voor softwaretesten wat agile ontwikkeling is voor softwareontwikkeling; plannen krijgen gaandeweg vorm en worden gebaseerd op de meest recente informatie.
De kwaliteit van het testen
Als softwaretester kun je nooit zeggen: 'Ik heb dit gemaakt.' Wat je soms wel kunt zeggen is: 'Ik heb een ramp verhinderd.' Maar wie gaat dat geloven? En als er een ramp gebeurt, zul jij de schuld krijgen. Op de één of andere manier denkt iedereen altijd dat software niet goed werkt omdat het niet goed getest is en nooit omdat het slecht was ontworpen of slecht gebouwd. Dus als het gaat om de kwaliteit van je werk als tester, moet je kunnen verantwoorden wat je wel en niet hebt gedaan om zwakke plekken bloot te leggen. Je zult vrij van schuld blijven als je de keuzes die je hebt gemaakt kunt uitleggen en verdedigen. Omdat problemen een eigen wil lijken te hebben, kunnen deze keuzes bij het testen, in tegenstelling tot bij het controleren, niet vooraf gemaakt worden. Daarom is testen altijd exploratief.
Referenties
Bach, J. (2003), Exploratory Testing Explained, http://www.satisfice.com/articles/et-article.pdf
Beck, K. en anderen (2001), Agile Manifesto, http://agilemanifesto.org/
Bolton, M. (2009), Testing vs. checking, http://www.developsense.com/blog/2009/08/testing-vs-checking/
Kaner, C. en Bach, J. (2009), The Seven Basic Principles of the Context-Driven School, http://www.context-driven-testing.com/
Een uitgebreide, Engelstalige versie van dit artikel is eerder gepubliceerd in Agile Record onder de titel "Mental gymnastics". Het commentaar van Michael Bolton hierop, waarvoor dank, is gebruikt bij de totstandkoming van deze vertaling.
Beste Bert.
Mooi artikel, goede timing. Ik had gisteren een discussie. Waarom horen we zo weinig van ET. is het commodity geworden en doet iedereen het gewoon? Nee, ik zie nog veel traditioneel testen. Zijn alle ET-ers gaan SCRUMmen? Ik denk het niet. ET heeft juist ook veel toegevoegde waarde in de test-soorten die buiten de sprints vallen. Met jouw toepassing van het manifest, kunnen traditionele testers goed de transitie maken naar agility en het helpt hun wellicht om hun waarden en normen te delen met de ontwikkelaar. Dat komt DEV-TEST samenwerking ten goede. Ik zal naar je artikel refereren tijdens mijn Exploratory testen training die ik begin november geef.
Beste Derk-Jan,
Dankjewel voor de lovende woorden.
ET zal nooit een commodity worden omdat verschillende testers tot verschillende tests komen, afhankelijk van hun kennis, ervaring en voorkeuren. Traditionele testers, die de opdracht krijgen om een testscript te maken voor bepaalde functionaliteit met gebruikmaking van een bepaalde testtechniek, zullen allemaal dezelfde logische testgevallen opstellen. Voor individuele verschillen is alleen ruimte bij het fysiek maken van de tests. Traditionele testers zijn dus een commodity. Als je je wilt onderscheiden als tester, kun je je beter bekwamen in ET.
Wel is het zo dat iedereen het al doet, alleen heeft men er vaak moeite mee om dit toe te geven. Er is geen enkele tester die zich voor 100% aan het testscript houdt. Bijvoorbeeld, op het moment dat er een bevinding optreedt, zal de tester direct onderzoeken of de bevinding reproduceerbaar is. Strikt genomen wijkt hij hiermee af van het script. Een goede tester gaat verder en probeert de bevinding te pinpointen, dat wil zeggen hij probeert zoveel mogelijk informatie te verzamelen die kan helpen bij het oplossen van de bevinding. Dit is een uitstapje, een verkenning, exploratief dus. Verder is het zo dat testers ook letten op andere dingen dan alleen het verwachte resultaat. Ook in projecten waarin zogenaamd geen plaats is voor ET wordt een groot deel van de bevindingen gedaan buiten de testscripts om.
Het antwoord op de vraag “Waarom horen we zo weinig van ET?” lijkt simpel: Omdat er zo weinig over gesproken wordt. En als er over gesproken wordt is het vaak in negatieve zin. Onderliggende oorzaak is misschien dat veel testers ET beschouwen als een test(ontwerp)techniek, die alleen toegepast kan worden bij minder kritische applicaties door ervaren testers met veel domeinkennis. Zo staat het immers in het TMap-boek. ET is echter geen test(ontwerp)techniek, maar een benadering. Binnen ET kunnen alle verschillende test(ontwerp)technieken worden toegepast. Testervaring en domeinkennis zijn natuurlijk nooit weg, maar dat hoeft junior testers er niet van te weerhouden om hun nieuwsgierigheid, intelligentie en vakkennis ook in te zetten tijdens de testuitvoering en niet alleen tijdens de testspecificatie. Bij kritische applicaties moet er meer en vaker worden gecontroleerd door middel van testscripts, maar daarnaast is het altijd goed om ook (exploratief) te testen. Je kunt namelijk nooit alles controleren, er zijn domweg teveel mogelijkheden. Dit geldt evenzeer in agile projecten als in watervalprojecten.
Goed ook om te horen dat jij binnenkort een ET-training geeft. Ik hoop dat je niet te veel concurrentie ondervindt van Michael Bolton die in ongeveer dezelfde periode zijn Rapid Software Testing cursus komt geven in Nieuwegein.