Op een testevenement van Sogeti over agile-testen hoorde je regelmatig de opmerking 'Er zijn geen testers meer nodig in de toekomst'. Dit sloeg op het feit dat bijvoorbeeld automatisering van testen – model based testing – hiervoor gaat zorgen. Het was een tussendoor opmerking, maar het wordt de laatste tijd steeds vaker gezegd. Het is echter maar de vraag of oplossingen als model based testing de toekomst zijn.
Er zijn nog meer voorbeelden aan te dragen waarin de toekomst van de tester wordt afgeschreven. Hier volgen er een aantal met hun 'twijfelachtige' motivatie.
Agile ontwikkeling: ' Iedereen test'
Elk teamlid kan alle soorten activiteiten uitvoeren wat binnen het project gedaan moet worden. Men spreekt hier over multidisciplinaire teams. Testen is geen aparte activiteit voor één functie, maar iedereen draagt bij. De projectleden zijn samen verantwoordelijk voor de kwaliteit van een product. De tester heeft in dit geval een begeleidende rol.
Mainframe wereld: 'Stabiel'
Het mainframe is zo stabiel dat een tester niet nodig is. Het bestaat al dertig jaar, sommige bedrijven draaien op software van dertig jaar oud en dat allemaal zonder problemen.
Netwerken in infrastructuur: Eenvoudig te analyseren'
Er gaat bijna niets fout bij het bouwen van infrastructurele snelwegen. Dit in tegenstelling tot het maken van software. Als er iets fout gaat is het probleem zeer snel gevonden en daarna ook snel verholpen.
Testautomatisering: 'Vervang het testbrein'
Compleet geautomatiseerde teststraten. We kunnen geautomatiseerd een model opbouwen aan de hand van de specificaties. Vervolgens automatisch testscripts laten genereren die afgespeeld worden door een playback tool of andere testsoftware.
Bewaak je eigen kwaliteit: 'Iedereen levert kwaliteit'
Een ontwerper moet de kwaliteit van zijn ontwerp bewaken en zodra er fouten instaan aanpassen. Een programmeur moet hetzelfde doen. Dit is de meest efficiënte manier van testen. Je vind iets en de persoon zelf kan het ook meteen oplossen. Een aparte tester levert alleen extra communicatiepaden op via test- en bevindingen rapportages. Omdat testers pas testen als alles af is komen ze vaak te laat met bevindingen die dan ook niet meer opgelost kunnen worden.
Onterecht
Deze voorbeelden spreken vele automatiseerders aan, maar zijn onterecht. Adequaat testen van software en systemen blijft altijd noodzaak.
– Je hebt altijd iemand anders nodig die je helpt om met je mee te kijken, je ziet je eigen fouten niet. Dat hebben we nu toch wel geleerd na meer dan veertig jaar automatisering?
– Wie kan deze fouten het best vinden? Iemand die zich heeft verdiept in hoe je fouten het best kan ontdekken of door gewoon logisch na te denken? Het eerste is effectiever.
– Het snel kunnen analyseren en verhelpen van fouten in productie zijn nog steeds extra kosten die vaak niet nodig zijn. Dit wordt helaas nog niet overal zo gezien, omdat budgetten om problemen op te lossen vaak bij een andere afdeling liggen.
– Mainframe wereld, houdt eens op met zeggen dat het zo stabiel is. 30 jaar stabiel op dezelfde software draaien is mooi, maar dat komt vaak omdat niemand meer durft om software aan te passen, omdat er zoveel aan veranderd is en nooit gedocumenteerd is.
– Iedereen moet zijn werk goed controleren, elke functie binnen een team. Maar heeft iedereen er wel zin in? Een programmeur wil creëren, iets maken, een tester is meer een analist en het testen past beter zijn gehele karakter.
– Test automatisering: We proberen het nu al meer dan tien jaar. Model based testing? Op basis van wat? Specificaties zijn nooit tot in detail uitgeschreven, dus een goed model bouw je niet zo snel op. De beste manier blijft creatief en goed na te denken. Dan vindt je de bugs, niet door een standaard script af te spelen.
Leve de tester!
Testers worden ‘geboren' vanuit een kwaliteitsbesef. We willen graag dat software systemen bruikbaar zijn voor de mensen die er echt mee gaan werken. En we hebben de karaktereigenschappen om hierbij te helpen.
Een goede tester komt snel op snelheid, kijkt vanuit het gedrag van de gebruiker, focust op fouten en de ernst van het probleem, is sceptisch, kan tegen verveling, rapporteert graag problemen en voelt zich comfortabel in conflicten. Deze eigenschappen zijn niet altijd aanwezig bij een programmeur of ontwerper.
Dat laatste is ook wel logisch. Je kan niet alles in één persoon stoppen. Zoiets complex als software en technische systemen zul je dit toch vanuit meerdere perspectieven moeten benaderen. In plaats van aan te geven dat iedereen moet testen kan er beter ingezet worden op samenwerking tussen projectleden. Daar heeft iedereen de mond vol van, maar de dagelijkse praktijk is compleet anders.
Rob van Steenbergen, Chickenwings Test Consultancy
Door het testwerk te verschuiven aan ontwikkelaars schuif je in feite het bestaande testwerk alleen maar, geen besparing in de hoeveelheid werk. Een tester kan het werk efficenter/doelmatiger uitvoeren omdat hij daarin gespecialiseerd is. Bovendien is tijdens de integratie geen ontwikkelaar in zijn geheel voor het product verantwoordelijk, er is niet zoiets als eigenproduct.
Volledig geautomatiseerd testen bestaat niet. Testen is niet alleen testgevallen opstellen en deze uitvoeren maar ook bijvoorbeeld reviewen van de specs. Het is ook maar de vraag of automatisch testgevallen genereren altijd mogelijk is: kan men elke type wijzigingen in het ontwerp op voorhand bepalen dat elke type wijziging geanticipeerd kan worden in de automatisatie?
Op een testevenement van Sogeti over agile-testen hoorde je regelmatig de opmerking ‘Er zijn geen testers meer nodig in de toekomst’. Dit sloeg op het feit dat bijvoorbeeld automatisering van testen – model based testing – hiervoor gaat zorgen.
‘We’ leren het ook echt nooit… Elke keer doen we weer van die boude uitspraken. Toen we Case tools hadden, was de programmeur ook niet meer nodig… ja,ja……
De volgende uitspraak heeft hetzelfde waarheidsgehalte:
“Een projectleider is in de toekomst niet meer nodig. Elk projectlid kan zijn eigen parameters en projectgegevens in een projecttool invoeren die daarna het projectplan volledig automatisch genereert en dit voortdurend bewaakt”
Als ik even zo vrij mag zijn e.e.a. aan te vullen:
– Mainframe is zo stabiel omdat er eerst goed getest!!! wordt voordat men iets veranderd, omdat de mainframe omgeving een zeer gecontroleerde omgeving is (geen last van nerds die met hun iphone op een mainframe willen) waarbij de beheerder alles in de hand heeft, en niet de hacker (alias programmeur) op de werkvloer
– Testers zijn doorgaans neutraal. Een programmeur die zelf de testcode schrijft voor zijn eigen werk, is als een kok die een recensie schrijft voor zijn eigen restaurant.
– Niet al het testen is te automatiseren. Er kan veel, en daar moeten we ook zeker gebruik van maken. Maar complexe mens-machine interfaces worden al lastiger te automatiseren. Er is niets zo onberekenbaar (en daarmee te automatiseren) als de factor mens. Als mensen aan alle hendels en knoppen zitten, in onberekenbare volgorde, kun je hele leuke effecten krijgen
– Teststrategie en filosofie is al weer veel lastiger te automatiseren dan een testcase. Sommige producten zijn zo groot en complex geworden dat simpelweg niet alles meer te testen is binnen een acceptabele tijd. De kennis en ervaring van een tester om een goede teststrategie te bepalen is dan onontbeerlijk
Ik onderschrijf de stelling dat testers onontbeerlijk zijn dan ook van harte
Op dit moment ben ik bezig het TMap Next boek door te ploeteren. Er is één ding in dit artikel wat ik onderschrijf, testers kunnen tegen verveling.
Wat ik in bovenstaande stuk niet begrijp is dat TMap het nooit heeft over fouten en problemen. Om deze termen positief tegemoet te treden wordt er gesproken over bevindingen.
“Testers worden ‘geboren’ vanuit een kwaliteitsbesef”.
Als IT’er heb ik een aantal opmerkingen hierover.
Wat is kwaliteit? Dat is datgene wat de klant wil. Ik krijg de indruk bij dit stuk dat de tester gaat bepalen wat kwaliteit is en niet de klant.
Wat is de kwaliteit van een stuk waarin termen gebruikt worden, waarvan gezegd wordt dat testers die termen moeten vermijden? Woorden als fouten en problemen geven iets negatiefs aan. Waar in TMap wordt aangegeven dat je als tester iets positiefs moet benaderen, wordt in dit stuk weer het negatieve benadrukt.
Zeker met RUP moet je uitkijken om het te hebben over fouten. Wat vandaag in een ontwerp wordt opgenomen kan morgen al weer achterhaald zijn.
Als een tester kwaliteitsbesef heeft dan kan de tester ook rekening houden met de ontwikkeling binnen de IT. Ik mis dat in dit stuk.
@Christian: Even reageren op jouw opmerkingen. Ik vind het goed dat er gereageerd wordt op dit stuk, dat betekent dat ik in ieder geval één doel heb bereikt. Mijn mening geven en ook dat andere mensen hier iets mee kunnen en meedenken over dit onderwerp. Dus bedankt voor je reactie.
De tweede zin na het “geboren worden” zin geeft toch aan dat ik bedoel dat we software systemen willen die bruikbaar zijn voor “de mensen die er echt mee gaan werken”. Daarmee bedoel ik ook dat de klant/eindgebruiker (en andere stakeholders) bepalen wat de kwaliteit is en dat de tester hierbij helpt.
Verder gebruik ik het woord bevinding inderdaad niet, dit zwakt mijn verhaal wat af, daarom noem ik het maar wat directer: fout, probleem. Ik had het ook ‘bug’ kunnen noemen of de kreet ‘defect’ kunnen gebruiken zoals binnen RUP wordt gebruikt. Ik hoop dat het niet te negatief overkomt, deze woordkeuze is om het stuk scherp te houden.
Mijn hele stelling gaat over de ontwikkeling in de IT, maar dan gericht op de discussie over testen en de toekomst van de tester. Een opinie stuk mag niet al te lang worden en ik kan natuurlijk iets gemist (foutje?) hebben. Zou je kunnen aangeven wat je bedoelt met je laatste zin?
@Rob van Steenbergen
Wat ik met de laatste zin bedoel is dat er bij RUP niet meer wordt uitgegaan dat er alleen getest wordt als een systeem af is. Ook TMap geeft aan dat het (denken over) testen al begint voordat de ontwikkelaar aan de unittest begint.
Wat ik mis in dit stuk is:
– Een wijziging van een ontwerper heeft niet altijd te maken met een fout. De klant kan een ander inzicht hebben gekregen in wat hij/zij wil hebben, waardoor een ontwerp gewijzigd moet worden (RUP).
– De testers testen niet pas op laatste moment (zie opmerking over TMap). Ook een review van de documentatie hoort bij testen. Nog voordat er gebouwd wordt moet een tester op basis van de informatie analyse / functionele beschrijving zijn testset al ontwerpen. Uit deze review kunnen ook bevindingen komen.
Het automatiseren van testen gebeurt vaak op het laatste moment, maar het denken over wat er getest moet worden vindt eerder plaats. Ik mis de tijdslijn die wel bij RUP en TMap wordt gehanteerd, waardoor er beter aan te geven is waarom het inzetten/inhuren van testers nodig blijft.
Het ontbreken van deze punten verzwakt het stuk. Door het reviewen niet te benoemen wordt het grootste minpunt van testautomatisering niet benoemd.
Om dit in de bewoording van het stuk te houden:
Een fout is menselijk, dus ook als de specificaties tot in detail zijn uitgeschreven kunnen er fouten worden gemaakt. Alleen door de specificaties te laten reviewen kun je een goed model bouwen. Maar zelfs met het beste model zal niet alles getest worden.
@Christian, Ik ben het roerend met je eens dat de eerste winst van een tester al is als deze het functioneel ontwerp test. Iemand met oog voor compleetheid haalt veel meer dingen boven water dan een ontwikkelaar of technisch ontwerper. Dat is mijn persoonlijke ervaring van de afgelopen vijf jaar!
Testers zullen altijd nodig blijven, zeker voor de systeemtest. Een ontwikkelaar maakt de unit en integratietesten. Die testen zijn erop gericht te bewijzen dat de units en groepen units doen wat ze moeten doen. Systeemtesten kijken meer naar het geheel, en van de buitenkant. Systeemtesten zijn black-box testen. Verder is het de vraag of het niet een goed idee is, een speciale unit test ontwikkelaar aan te stellen, omdat goede unit tests schrijven een net iets ander vak is dan ontwikkelen zelf, hoewel iedere ontwikkelaar dat wel zou moeten kunnen.