Met name in de afgelopen drie jaar is er eindeloos veel geschreven, gesproken en gedaan over de toekomst van software testen. Een rol die aan het einde van zijn latijn zou zijn. Hieronder vindt u vijf redenen waarom testen dood is. Argumenten die wellicht houtsnijden. En tegelijkertijd weinig overtuigend zijn.
Het gebruik van gestructureerde testmethoden kosten meer tijd en geld
Bij de traditionele testmethoden worden nogal wat rijtjes met fasen, activiteiten en producten opgesomd en doorgeakkerd. Als de tester dat proces volgt, gaat dat inderdaad veel tijd en geld kosten. Niet doen dus. Neem niet alles klakkeloos over maar pas zaken aan in de context waarin je werkt. Eén activiteit is altijd een absolute must. De uitvoer van een productrisicoanalyse. En verder bepaal je samen met projectbetrokkenen wat nog meer nodig is. Op basis van de geïdentificeerde risico’s bekijk je welke activiteiten, technieken, producten en personen een rol spelen om die risico’s af te dekken. Ik zie dit als een eenvoudige legpuzzel. Je gebruikt, wijzigt of voegt alleen die stukjes toe die in jouw context passen. Ongeacht de methode (TMap, ISTQB, Testframe of ISO29119) die je gebruikt. De tester moet in staat zijn op adaptieve wijze een testaanpak in een bepaalde context te gebruiken. Anders gezegd, hij of zij moet een goede balans vinden tussen de af te dekken risico’s enerzijds en de daarmee gemoeide kosten en tijd anderzijds. Daarbij moet hij/zij een goede balans vinden tussen de af te dekken risico’s en de daarmee gemoeide kosten en tijd centraal staan.
De inzet van nieuwe ontwikkelaanpakken maakt testen overbodig
Met de inzet van een Agile ontwikkelaanpak, zoals het veelvuldig gebruikte Scrum, heeft ieder teamlid een testrol. Dus ontwerpers, programmeurs, beheerders en gebruikers testen allemaal. Dus daarmee is het plausibel te stellen dat testers overbodig zijn. Echter, twee kanttekening zijn hierbij cruciaal. Bij gedeelde verantwoordelijkheid is niemand verantwoordelijk, wordt wel gezegd. Dat is hier ook van toepassing. Als iedereen als de tester wordt beschouwd, is eigenlijk niemand de tester! En verder mag je niet verwachten dat alle teamleden opeens over dezelfde uitgebreide testvaardigheden beschikken als de ervaren tester. Dat betekent dat testers hun teamleden moeten helpen om deze rol in een Scrum-aanpak zo goed mogelijk vervullen. Bijvoorbeeld hulp bieden bij het opstellen van kwalitatief goede user stories. De tester kan daarbij de ontwerper of gebruiker toetstechnieken bijbrengen. Of de programmeur helpen bij het opstellen van unittesten en de gebruiker helpen bij de acceptatietest. Tenslotte moet de tester modereren bij de eerder genoemde productrisicoanalyse. En zo, is mijn stellige overtuiging, moet de testprofessional bewegen richting katalysator van kwaliteitsverbeteringen.
Testen is duurder dan het verhelpen van productieverstoringen
Testen kost veel geld en tijd. Soms is het beter de software zo snel mogelijk in productie te nemen. En daarmee eventuele fouten tijdens het productieproces op te lossen. Door de korte iteraties en vrijwel continue inproductiename-mogelijkheden die er zijn, kost dat immers minder tijd en geld. Eerst snelheid dan kwaliteit, is dan het motto. Dat kan ook zeker in een aantal omgeving zoals de inzet van mobile apps en websites. Echter, waar sprake is van serieuze risico’s is testen van cruciaal belang. Risico’s voor onze samenleving, reputatieschades, of grote impact op bedrijfsresultaten. Uiteindelijk gaat het om de balans tussen wat het kost om de fout tijdens het ontwikkeltraject op te sporen en de kosten van fouten tijdens het productieproces. Het is van belang dat de tester dichter tegen de business gaat zitten om hier inzicht in te krijgen. Daarmee kan hij of zij een goed advies geven over de te volgen teststrategie. Met name ook hoe eventuele risico’s kunnen worden afgedekt. Denk daarbij ook aan andere risicobeperkende maatregelen dan testen alleen!
Tooling zorgt ervoor, dat ontwikkelaars geen fouten meer maken
Al 25 jaar lang wordt geroepen dat testen voorbij is zodra tools voorhanden zijn die foutloze codes genereren op basis van functionele specificaties. Het bevestigt eens te meer hoe slecht we zijn in het voorspellen van de it-toekomst. We komen inderdaad steeds verder met de tooling die voorhanden is, en waar nog volop aan gewerkt wordt. Toch is dat helaas geen gemeengoed. En ook al zou de code uit requirements gegenereerd worden, en ook al zou dit foutloze code zijn, dan blijven acceptatietests nog noodzakelijk. Foutloze code is nog steeds geen garantie dat deze applicatie het werk van bijvoorbeeld de eindgebruiker op de gewenste wijze ondersteunt. Een tester kan ondersteuning geven bij het opstellen van de requirements, bijvoorbeeld door toetstechnieken te gebruiken, en bij het opstellen van de acceptatietests. Tegelijkertijd blijven de productieacceptatie- en ketentests ook nog steeds nodig.
In Nederland wordt een grote verscheidenheid van testsoorten gebruikt. Vaak in reeksen achter elkaar uitgevoerd. Soms krijg ik de indruk dat ontwikkelaars hier mis- dan wel gebruik van maken. ”Ik lever de code op tijd op en dan hoor ik wel of er fouten in zitten, want na mij wordt er toch nog uitgebreid getest.” Het valt op dat in landen waar het niet gebruikelijk is zoveel testsoorten in te richten en uit te voeren software met mindere fouten wordt opgeleverd. Hoe kan dat? Het antwoord is eigenlijk heel simpel. Door de vele tests voelt de programmeur zich minder verantwoordelijk voor de kwaliteit van zijn product. In situaties waar de software vrijwel direct na een unittest in productie wordt genomen, moet de programmeur wel zijn verantwoordelijkheid nemen. Als het fout gaat, weet tenslotte iedereen wie daarvoor verantwoordelijk is. Kortom, ik pleit voor het verminderen en/of samenvoegen van testsoorten en de programmeur meer verantwoordelijkheid geven. Dat vergroot de kwaliteit van de software.
Alles wordt al in de cloud getest
Laat de beta tests op de applicatie in de cloud uitvoeren en alle fouten worden gevonden. Voor de duidelijkheid, niet alle applicaties zijn hiervoor geschikt. Op basis van strategische redenen kiezen organisaties ervoor niet alle applicaties in de cloud te zetten. Maar inderdaad, beta testers vinden veel fouten. Dit zijn veelal de triviale en niet de ingewikkelde fouten waar je toch echt een testscenario voor moet schrijven. Daarbij wordt geen rekening gehouden met eventuele risico’s. Een ongeorganiseerde groep mensen vuurt een schot testhagel af op de applicatie. Onlangs hoorde ik van een medewerker van een ‘game design’-bedrijf dat er nog een ander nadeel aan zit. ‘De beta testers’, zei hij, ‘willen het spel spelen en rapporteren vaak alleen die fouten die hen verhinderen het spel verder te kunnen spelen. Dus rapporteren ze niet alle fouten.’ Nou zou het natuurlijk niet verstandig zijn de kracht van de cloud onbenut te laten. Maar in plaats van een applicatie zomaar in de cloud te laten testen, gaat mijn voorkeur uit naar crowd-sourced testing. Dus stel de applicatie aan bepaalde zorgvuldig geselecteerde mensen ter beschikking om te testen. Of nog beter, expert-sourced testing. Biedt de applicatie aan mensen met testexpertise en/of kennis van de applicatie om te testen.
Leo van Aalst, senior consultant, auteur en lector software kwaliteitszorg Sogeti
Over de auteur
Leo van der Aalst heeft ruim 25 jaar ervaring in de it. Na zijn carrièrepad van programmeur tot programmamanager, heeft hij zich gespecialiseerd in het testvak.
Van der Aalst is co-auteur van de TMap NEXT, TMap NEXT BDTM en TMap NEXT in Scrum boeken en ontwikkelde onder andere diensten voor Agile-testen, de inrichting van testorganisaties en voor testoutsourcing. Verder heeft Leo voor het Exin opgaven ontworpen voor zowel het TMap NEXT Test Engineer als het Test Management-examen. Tevens is Leo lector van het lectoraat Software Quality & Testing aan de Fontys Hogescholen, lid van de normcommissie NC 381007 ‘Software and System Engineering’ en Development Lead van de ISTQB Agile Add-On Syllabus.
Tenslotte is Van der Aalst een veelgevraagd docent voor testopleidingen, spreekt hij regelmatig op nationale- en internationale conferenties en is hij auteur van diverse artikelen.
Is de tekst nu ironische bedoeld?
Zo niet, dan begrijp ik er helemaal niets van. Agile betekent inmiddels:
– Niet meer ontwerpen
– Niet meer documenteren
En nu ook niet meer testen?
@Leen,
Dit is een van de meest betreden valkuilen betreffende Agile. Agile is alles wat niets toevoegt niet uitvoeren. Dus als ontwerpen niets toevoegen laat je inderdaad de ontwerpen weg. Als de documenten niets toevoegen laat je ze weg. Maar dan zijn deze keuzen bewust gemaakt.
Maar als er een instantie is die eerst ontwerpen wil zien voordat goedkeuring wordt gegeven dan voegen ontwerpen iets toe (namelijk verkregen toestemming). Als er een instantie is die bij het eindproduct documenten wil zien omdat anders geen invoer wordt toegestaan, dan voegen documenten iets toe. Maar dan zijn er aanwijsbare redenen om dit te doen, en is er in feite geen keuze.
Het zelfde geldt voor testen: als het product slechts eenmalig wordt gebruikt en er zijn geen risico’s (geld, levens, etc.) waarom dan testen? Als het falen van (een onderdeel van) het product levens gaat kosten (of het repareren van de gevolgen enorm veel geld) dan heeft testen wel degelijk nut.
Maar in alle gevallen is bewust gekozen voor het wel of niet uitvoeren van de betreffende stap.
Een product zo snel mogelijk in productie nemen en dan de fouten ontdekken omdat het goedkoper is dan testen? Ik moet zeggen dat ik dat minachtend vind ten op zichte van de gebruikers. Die is heilig. Uiteindelijk is dat wat de ict moet leveren, ondersteuning van de gebruiker op een zo goed mogelijk wijze maar om een gebruiker willens en wetens niet werkende software te geven om die de fouten maar te laten ontdekken dat kan naar mijn mening niet.
En hier weer die hele treurige agile discussie. Met zo een manifesto vraag je ook om dit soort dicussies. Wel of niet documentatie, wel of niet ontwerpen, wel of niet testen. Er moet ontworpen worden, er moet gedocumenteerd worden en er moet getest worden. Agile betekent alleen maar dat je ergens aan werkt zonder alle antwoorden al te weten en ruimte geeft aan voortschrijdend inzicht. Niets meer en niet minder maar het ontslaat je niet van wat je hoort te doen.
@cpt,
Ik zie de voordelen van agile werken wel, en wij doen steeds vaker projecten en productmanangement agile. Maar waar we nog wel mee worstelen is het aantonen van de kwaliteit van het resultaat. Bij een IT-project waar code wordt ontwikkeld heb ik regelmatig moeten constateren dat de opgeleverde code (werkend en getest(!)) heel veel losse einden bevatte. Dat is voor de korte termijn niet zo’n bezwaar maar vanuit onderhoudsperspectief kostenverhogend.
Misschien is dat wel de zoektocht: hoe bepaal je wat niet per sé nodig is, maar dan wel de korte en de lange termijn in gedachten blijven houden.
Aan mensen die menen dat testen niet nodig is vraag ik altijd of ze het door hun gemaakte apparaat zouden kopen/gebruiken als de SW niet getest was.
Bij een kranten-lees-app heb ik niet zo’n moeite met een “ja”, maar als we het gaan hebben over software in auto’s, vliegtuigen of medische apparatuur veranderd de visie gelukkig al snel
Testen is niet dood, maar er is afgelopen jaar een nieuwe markt-segment gegroeid (iets met -apps) waarbij snel op de markt inderdaad belangrijker is dan kwaliteit.
Een app die crasht op een smartphone is doorgaans hooguit vervelend.
Maar stel je voor dat je, 130 rijdend op de snelweg, even tussentijds een reboot moet doen van je hele motor managementsysteem.
Of een arts, die tijdens het dotteren van een patiënt even koffie kan gaan drinken omdat de röntgenapparatuur crasht en ‘even’ moet herstarten.
(gelukkig worden we hier beschermd door allerlei wetgevingen en andere instanties die je verplichten te testen en dit ook goed te documenteren)
De Spaceshuttle Discovery verongelukte als gevolg van het feit dat van een rubberen afdichtingsring van een paar dollar niet was getest of deze bestand was tegen bevriezing.
Omdat de ontwerpers en bouwers als groep overtuigd waren van de veiligheid van het toestel was de (wel beveiligde) cockpit niet uitgerust met noodparachutes (die het leven van de bemanning hadden kunnen redden). Een soort Titanic dus, maar dan anders.
Dit laatste fenomeen zou je in agile/scrum teams tegen kunnen komen: omdat de groep steeds snel op een lijn moet zitten kunnen individuen minder kritisch worden op details. Juist dan is testen het meest noodzakelijk.
Overigens maakt de auteur naar mijn mening voldoende duidelijk dat genoemde stellingen maar halve waarheden zijn.
“De Spaceshuttle Discovery verongelukte als gevolg van het feit dat van een rubberen afdichtingsring van een paar dollar niet was getest of deze bestand was tegen bevriezing.”
Incorrect. Het was precies bekend dat vanaf zekere temperaturen deze afdichtringen niet meer afdichtten. De werkelijke reden van het ongeluk was dat ontwikkelaars van de ringenfabrikant bij navraag door Nasa aangaven (onder GROTE DRUK gezet door het “maakt niet uit wat je managed toch, is een vak op zich” management van de fabrikant) dat lanceren bij de op dat moment geldende te lage temperaturen geen probleem zou moeten zijn!
Derhalve een prima voorbeeld van “laat de klant (ook nog) testen, dat is in alle commerciele opzichten beter”.
Onnodig te zeggen dat van dat betreffende management niemand op dit moment in de gevangenis zit, althans niet voor het zojuist geschetste feit.
@henk
Blijkt maar weer eens dat bij het falen de fouten de schuld al snel bij de mensen op de werkvloer wordt geschoven terwijl het vaak toch wel een genuanceerd verhaal blijkt te zijn.
Overigens dat dit stuk door tegenstellingen juist de confrontatie op zoekt en discussies uitlokt lijkt mij een zeer welkome vorm van schrijven. Vooral als je de lezers actief wil betrekken.
Wat testen betreft hoort het er gewoon bij. Een bakker proeft ook zijn eigen brood en een timmerman meet ook of de balk wel netjes waterpas zit. Het punt is dat het bij IT wat meer ingewikkeld wordt omdat je van alles kan testen.
@Johan
wat betreft je vergelijking met een bakker:
een bakker proeft zijn eigen brood
een bakker controleert de textuur van zijn brood
een bakker controleert de kleur van zijn brood
een bakker controleert …
Net als bij testen komt ook bij het bakken van brood veel kijken.
Maar wat vindt de bakker belangrijk aan zijn brood om een kwaliteitsproduct voor zijn klant neer te zetten? Dat is ook ingewikkeld. 😉
Bij testen moet je vooral naar de risico’s kijken en hierin een afweging maken wat te testen, daar ligt de kracht van een tester. Niet alles hoeft getest te worden. No risk, no test!
Een slager die zijn eigen vlees keurt?
Als ik dit stuk zo lees is testen zeker nog niet dood maar wordt dit gewoon verschoven naar de gebruikers waarbij Leo nog een beetje twijfelt of hier amateurs of experts gebruikt moeten worden. Ik betwijfel echter of die strategie ons uiteindelijk ‘hufterproof’ software op gaat leveren.
Uit reacties wordt al duidelijk dat er een LEVENSGROOT verschil zit tussen software, of zoals Pa Va Ke het eerder uiteen zette in een opinie is DE een lidwoord waar niet-leden nog weleens de dupe van worden. Inderdaad hebben we om die redenen dus allerlei controlerende instanties die helaas nog te vaak reactief optreden.