Er zijn de laatste tijd nogal wat artikelen verschenen over de toekomst van het testen, waarbij gesuggereerd wordt dat het handmatig testen, door gespecialiseerde testers niet meer nodig is. Er worden verschillende oplossingen aangedragen die het schrijven en ontwikkelen van adequate software dichterbij brengen. Dat wil echter niet zeggen dat de software echt foutloos is. Het blijft tenslotte mensenwerk.
De meest gehoorde oplossingen die volgens menigeen voldoende zijn om de tester buitenspel te zetten zijn het schrijven van zeer goede requirements en ontwerp documentatie, het volledig automatiseren van te testen onderdelen, de gebruiker zelf laten testen en zo snel mogelijk updates leveren van de software bij eventuele problemen. Is het met dit soort oplossingen nog nodig om (handmatig) te testen? Hebben we de testspecialist nog nodig?
Goede requirements en ontwerpen
‘Het schrijven van goede requirements en ontwerpen voorkomt het maken van verkeerde software', klinkt prima. Als je de requirements goed beschrijft, zodat iedereen echt begrijpt wat we gaan maken, dan zullen er minder klachten achteraf zijn. Het samen uitwerken van requirements en daarna realiseren kan een hoop ellende wegnemen. Het vermindert in ieder geval een groot risico: Bouwen we wel wat we willen hebben? Toch zul je rekening moeten houden met menselijke fouten. Je zal altijd willen controleren of het systeem dat we met zijn alle bedacht hebben ook wel zo gerealiseerd is.
Hoe goed je ook documentatie maakt, er zal altijd een mate van interpretatie aanwezig zijn. Zo is de mens gebouwd, we bekijken de wereld allemaal vanuit ons eigen perspectief en we geven er een eigen invulling aan. De controle of dit ook het gedeelde belang dekt mag je testen noemen.
Volledig automatiseren
Stel je nu eens voor dat we heel goed zijn in het maken van documentatie. De documentatie is dan goed beschreven en zo gedetailleerd geworden, dat we in principe een model van het te bouwen systeem hebben gemaakt. Als je nog een stap verder gaat dan kan je in plaats van dit te beschrijven in Word-documenten ook denken aan een beschrijving in een ‘model' taal, zoals UML (Unfied Modeling Language). En dit dan opbouwen in een tool die dit ondersteunt.
Als je dit zo opbouwt, dan heb je alle onderdelen al klaar staan in software en kan aan de hand van een dergelijk model de code (gedeeltelijk) automatisch gegenereerd worden. Ook kan je dan de testgevallen automatisch laten genereren (dit valt onder de noemer ‘Model Based Testing'). Hiermee heb je in principe de klassieke testmethode geautomatiseerd: Verifiëren van ontwerpen tegen de werkelijkheid.
Maar de echte wereld is grimmig en verandert vaak. Een model is sneller aan te passen (als deze slim is opgebouwd) dan uitgebreide beschrijvingen in Word. Toch kan het gebeuren dat er behoefte is aan een verandering die toch lastig is in te passen in het model. Moeten er snel aanpassingen worden gemaakt, dan heb je kans dat de code ‘even' wordt aangepast en niet het model. Pragmatische oplossingen worden dan snel geïntroduceerd. Als organisatie moet dan je heel sterk in je processen staan en geen ad hoc aanpassingen in de code toelaten.
Model Based Testing is niet een testaanpak, maar meer een ontwikkelmethodiek, waar ontwerp, test en programmeren uit één bron komen. Je neemt het risico niet weg dat als het model een fout bevat, de automatische testen die aan de hand van het model gegenereerd worden deze fout niet zullen zien. We gaan er van uit dat het model klopt binnen deze methodiek. Het model moet eerst goed gecontroleerd worden. En de ‘denkende' mens zal nog steeds de software handmatig moeten onderzoeken. De scope van model based testing is te beperkt om geheel op geautomatiseerde tests te vertrouwen.
Gebruiker test de software
Google test eerst de software in zijn eigen organisatie door het te gebruiken (‘eat your own dog food' principe) en levert vervolgens de software aan een beperkt aantal gebruikers. De bevindingen die hier uit komen zijn realistisch, omdat er in een echte productie omgeving, met echte live situaties getest wordt. Als er een probleem wordt gevonden, dan is dat snel gerapporteerd en snel opgelost met een update.
Als full time software gebruiker wil ik niet lastig gevallen worden met bèta versies van software. Ik wil mijn werk niet verloren zien gaan in een 0x0038947328EEFF melding. Voor grote bedrijven als Google is dit geen probleem, ze hebben genoeg gebruikers die dat wel willen. Voor kleinere organisaties is dit geen optie, want als de gebruikers teveel problemen tegenkomen zullen zij snel geneigd zijn om voor andere software te kiezen. Ook het in de krant staan met een vervelende softwarefout is niet iets wat kleinere organisaties zich kunnen veroorloven.
En dan zijn er nog problemen die niet gelijk opvallen door normaal gebruik. Bijvoorbeeld: Een berekening die er prima uitziet bij alle gebruikers. Totdat het 1 januari 2013 is en men er achter komt dat na een jaar boekhouding de cijfers eigenlijk fout liepen vanaf een update in januari 2012. Dit zijn realistische scenario's. Een vliegtuig daalt sneller dan de bedoeling is, mensen krijgen geen pensioen meer omdat ze -65 jaar oud zijn. Een cent per tienduizend Euro verdwijnt in het niets.
Software extreem goed bouwen
‘Hierbij hanteerde het bedrijf een ontwikkelmethode waarbij de kwaliteit van het begin af aan gewaarborgd en gecontroleerd werd, omdat de betrouwbaarheid van de software niet door testen aan te tonen is', schreef Computable begin december 2011in een artikel over het beheer van de Europoortkering.
Ik sta nog steeds verbaasd over deze uitspraak. Dit kan natuurlijk een misinterpretatie zijn van de journalist die het artikel heeft geschreven, maar deze zin spreekt zichzelf tegen. De kwaliteit is vanaf het begin af aan gecontroleerd. Controleren van systemen is testen. Documentatie reviewen is testen, over product risico's nadenken en deze meenemen in het ontwikkelproces is testen. Een controle systeem inbouwen die constant controles uitvoert tijdens de operationele werking is ook een onderdeel van testen.
Je zou graag willen weten waar eventuele problemen zich mogelijk kunnen voordoen en deze in kritische situaties toch wel afgedekt willen zien met een soort van alarm systeem (monitoren van systemen). Deze monitor tools worden ook getest of deze goed werken.
We blijven dus testen
Een ontwerper, architect, projectmanager, secretaresse, gebruiker, support medewerker, programmeur, functioneel beheerder, manager, et cetera, zijn rollen die aan bepaalde mensen worden gegeven. Tester is ook een rol. Een combinatie van meerdere rollen is goed te doen. De programmeur wordt steeds beter in het testen van zijn eigen werk. De gebruiker krijgt steeds meer door hoe hij/zij de acceptatietest kan uitvoeren.
Testen is te leren door iedereen. Je kunt het als saai beschouwen of onnodig. Maar waarschijnlijk doe je het op dit moment al. De volgende punten vallen allemaal onder het vakgebied van testen:
– Je bekijkt of je met dit nieuwe systeem nog wel je bedrijfsprocessen kan uitvoeren
– Je controleert een model dat opgezet is op juistheid
– Je voert een onderzoek uit op de mogelijkheden van vergelijkbare software
– Je praat met een eindgebruiker hoe hij of zijn de nieuwe feature ziet
– Je schrijft een document en leest deze nog eens goed na
– Je bespreekt de risico's van het in productie brengen
– Je zorgt ervoor dat het projectteam samen gaat zitten voor een brainstorm sessie
Hoe goed de controles zijn ligt aan de technieken die je gebruikt, je ervaring en kennis. Daar hoef je geen apart testteam of aparte testers voor te hebben. Alhoewel het wel een vakgebied is met zijn eigen specialisatie. We gaan bijvoorbeeld een secretaresse ook niet vragen om software te programmeren. Je moet wel willen testen en het vinden van problemen als een uitdaging zien. Testen is daarnaast een studie op zich.
Hoeveel tooling je hebt, hoe goed je ontwerp documentatie en je model is, hoe goed je de software ook bouwt. Er is altijd een mate van controle nodig en veel van deze controles zullen niet geautomatiseerd zijn. Het is zelfs zo dat je waarschijnlijk al testen uitvoert in je eigen discipline, maar dat nooit onder de noemer ‘testen' hebt geplaatst. De aparte testfunctie zal zeker blijven bestaan, we hebben allemaal andere drijfveren en ideeën over wat we willen doen. Misschien wat minder handmatig testen in de toekomst, maar specialisaties in de ict blijven bestaan, ook testen.
Rob van Steenbergen, software tester bij Chickenwings Test Consultancy
Ik deel je kritieken op Model-Based Testing. Het probleem met model-based testing is dat om iets perfect te specificeren, je een vergelijkbare hoeveelheid ontwikkeltijd kwijt bent als het bouwen van het programma. (Je kan namelijk het model gebruiken om het programma te genereren.)
In het artikel over de Europoortkering gaat het over de activiteit testen en niet over het vakgebied testen. Het probleem van de activiteit testen is dat je van specifieke gevallen aantoont of het wel of niet werkt. Voor een kernreactor is het vereist dat je bewijst dat voor alle mogelijke testgevallen de software functioneert zoals gespecificeerd in de requirements. Als je formele requirements (een model) hebt is dit mogelijk met een model-checker.
Hoe goed model-based testing ook als idee moge zijn, mijn ervaring is juist dat het “model”-product goed blijkt te werken, maar dat in een keten-test de relatie met andere componenten niet goed functioneert of dat een wijziging in één component goed is voor die wijziging, maar uiteindelijk doorwerkt op andere punten waarbij dat minder gewenst is.
Er is altijd een helicopterview nodig om de test ook op andere niveaus te accepteren, al zit daar natuurlijk ook een rol voor de ontwerper
Zolang het principe “Meten is weten” geldt, zal er altijd getest worden waar en hoe dan ook.