Softwareontwikkeling maakt een revolutie door. Kwaliteit staat hoger op de agenda dan ooit. Testen is meer en meer onderdeel geworden van het totale kwaliteitsplaatje. Kennis van en ervaring met de verwachtingen van de business is nog nooit zo leidend geweest. Exploratory testen is niet meer weg te denken. 'Works as designed' is niet meer een geaccepteerde foutoplossing. Toch lijkt het tijdig vinden van kritische fouten maar niet te lukken.
Het zal u niet zijn ontgaan. Verbeteringen in code-quality, first-time-right quality, continue integratie, meer focus op requirements engineering en business analyse. Elk van deze ontwikkelingen heeft tot doel het verhogen van de kwaliteit van software. Testen is volledig geïntegreerd met, of soms zelfs leidend geworden voor ontwerp en ontwikkeling. Maar toch merk en lees ik te vaak dat – ook grotere – organisaties de mist in gaan bij het implementeren van nieuwe software.
Niet alleen administratieve software, maar ook internet of things, of volledig embedded software blijkt nog steeds onbetrouwbaar bij implementatie. Met soms fatale afloop. Denkt u maar eens aan hoeveel er recent weer in de media verscheen over softwarefouten in de auto, trein en vliegtuigindustrie.
‘De software is onbetrouwbaar’, zo luidt de verklaring. Of: ‘het is juist de combinatie van factoren die tot dit probleem geleid hebben’. Het zijn vaak dit soort analyses die voor testen de trigger zou moeten zijn: Was dit niet te voorkomen door testen? Waren de opgetreden combinaties van factoren niet te voorzien? Hadden we dit met testen kunnen vinden? Jazeker, sterker nog, we hebben de ‘tools’ gewoon al jarenlang in handen!
In deze tijd van de ‘lean DevOps’ en agile manier van software produceren, is de focus van testen sterk verschoven naar het leveren van ‘first time right’-software en het leveren van ‘value’ aan de klant. Value in je iteratie lever je door werkende software. Logisch gevolg van deze ontwikkeling is dat testen meer is dan alleen het checken of de software doet wat ie moet doen volgens de specificaties.
Verleggen
Checken is niet in staat om buiten een vooraf vastgestelde werking (de specificatie) te testen. De focus van testen moest echt verlegd worden naar: Doet het systeem wat het moet doen in de gebruikerscontext? En doet het systeem niet wat het níet moet doen in diezelfde context? De focus van testen verschuift van zuiver ‘checking’ van specs naar exploratory testen (‘checking-en-testen’) van het systeem zoals het gebruikt wordt door de klant. Hierdoor wordt testen creatiever, intuïtiever en flexibeler.
De laatste jaren merk ik dat technieken steeds meer plaats moeten maken voor deze nieuwe manier van testen. Zoals bij elke ontwikkeling lopen we het risico om hierin door te slaan. Want, zijn ’testtechnieken ouderwets en van geen tot weinig toegevoegde waarde?’ De nieuwe manier van testen geeft een antwoord op het psychologisch verschijnsel van ‘Inattentional Blindness’: Het gevaar, dat we door het gebruik van testtechnieken, teveel gestuurd worden in zoeken naar een specifiek aspect in het resultaat, waardoor we de rest van de resultaten van onze tests over het hoofd zien. Dit vermindert de creativiteit, intuïtie en flexibiliteit van de tester en daarmee de kwaliteit van het testen.
Sterke aanpak
Exploratory testen is dus een sterke aanpak! Maar verlegt een exploratory aanpak niet de focus van testen zodanig dat er ook dan gesproken moet worden van ‘inattentional blindness’?
Focussen we niet teveel op de basale behoeften (waarde) van de klant? De eerder genoemde voorbeelden geven al aan dat we niet altijd voldoende oog hebben voor de ongedachte combinaties. Terwijl juist combinaties met een simpele classificatie-boom snel en gedegen geïdentificeerd zijn. Tijd dus, om de oude testtechnieken te herwaarderen!
Ervaring en vakkennis
Professioneel testen is een combinatie van ervaring en vakkennis. Een combinatie van exploreren en techniekgebruik. Dat legt een nieuwe claim op de aloude technieken en op de tester die hier vertrouwd mee moet zijn. Testtechnieken zijn niet langer leidend voor het maken van testcases. Ze spelen wel een cruciale rol als het gaat om het ondersteunen en aanvullen van ‘exploratory testen’. Testtechnieken die het creatief brein en de intuïtie ondersteunen bij het komen tot goede tests. Die mix van ‘oude’ en ‘nieuwe’ wereld is onmisbaar voor de moderne tester in de huidige tijd!
Het is goed om te benadrukken dat, zoals genoemd wordt, de ‘ouderwetse technieken’, zoals ze genoemd worden, zeker nog niet uitgerangeerd zijn en dat we deze altijd in ogenschouw moeten nemen binnen onze testtrajecten. Beslissingstabellen, process coverage, dataflowtests en grenswaarde-analyses, om er een paar te noemen, kunnen hun nut hebben en waardevolle aanvullingen zijn in een exploratory test-sessie.
Daar wil ik dan wel aan toevoegen dat het wat mij betreft hier meer om gaat om de verkeerde interpretatie van wat ‘Exploratory testing’ is. Hoe men over Exploratory testing denkt gaat van ‘heen en weer klikken op de vrijdagmiddag’ tot ‘checking en testing’. Ik zou daar ‘learning’ aan willen toevoegen, omdat het gebasseerd is op ‘ervaring opdoen, leren en dat weer gebruiken voor je volgende test(sessie)’.
Zo zou Exploratory testing moeten worden gezien. Uiteraard vallen de ‘ouderwetse testtechnieken’ niet buiten deze definitie, wellicht dichter bij het ‘checking’ gedeelte dan het ’testing’ gedeelte. Ze zijn ze een integraal onderdeel van alle testen die je uitvoert. In combinatie met alle nieuwe testtechnieken die deze school van testen ons brengt.
De ‘inattentional blindness’ die ontstaat moeten we altijd proberen te vermijden. Daar helpen onze testtechnieken ons bij. De oude moeten we niet vergeten, maar ook de nieuwe technieken moeten we als testers nog wel wat meer in verdiepen. Die helpen ons als professioneel tester de onbewuste vooringenomenheden (biases) te herkennen die we allemaal hebben als ‘mens’.