Redactie: Gerben de la Rambelje
Auteur: Sander Mol ● sandermol@chello.nl
Een simpele benadering van testen. Zo simpel, dat ook niet-testers goed kunnen volgen wat wij testers doen en waarom. Deze uitdaging lag in 2012 voor mij klaar bij een nieuwe werkgever, een groot financieel intermediair, waar op dat moment nog geen testers werkten.
De eerste stap was het mee-testen bij één van de lopende projecten. Daarna begon het opzetten van een algemene testaanpak die héél praktisch en ook heel goed schaalbaar moest zijn. In juni 2013 was die aanpak klaar en kon ik de website www.simpeltesten.nu lanceren tijdens een presentatie bij TestNet op 24 juni 2013 voor de thema-avond Praktijkervaring.
Een menukaart; kiest u maar!
En dan in een rechte lijn naar de finish? Uiteraard niet. Bij geen enkel bedrijf is het rustig, maar bij ons bedrijf is er sinds juni 2013 een echte vloedgolf aan veranderingen geweest. Bijna alles is vervangen of grootschalig aangepast; de website en de inlogomgeving voor klanten, de verzekeringenadministratie, financiële en HR-applicaties, beheertools. Daarnaast zijn er ook veel kleine wijzigingen geweest. Kortgezegd een ideale omgeving om de testaanpak verder uit te werken.
Laten we beginnen met het tastbaar maken van schaalbaarheid. Voor iedere wijziging leg ik tegenwoordig de verantwoordelijke uitvoerder een ‘menukaart voor testen’ voor. Het gaat dan om projectleiders en beheerders. Zo kunnen ze zelf een eerste inschatting maken van het risico dat ze lopen en dus van de testbehoefte. Daarna heb je natuurlijk nog een gesprek hierover, om de nodige kritische vragen te stellen én om zelf vast wat inzicht in de wijziging op te doen. Hieronder zie je de menukaart, waarbij het testen van boven naar beneden steeds een stapje zwaarder wordt ingezet.
Het V-model als praatplaatje
Ik hou van plaatjes. Zo heb ik ook een plaatje om het onderscheid tussen systeemtesten en acceptatietesten duidelijk te maken. Voor onze business, de verzekeringsmannen en -vrouwen, maakt het meteen inzichtelijk dat ze op een andere manier moeten testen dan ‘even kijken of-ie het doet’. Want dat deel is voor hen onder water. De focus zou op gebruiksvriendelijkheid en op de aansluiting bij de werkprocessen moeten liggen; een cruciaal onderdeel, maar niet expliciet getest. En als je tóch even onder water wilt kijken, zet dan even een duikbril op en werp een korte blik totdat je weer een hap lucht nodig hebt.
De Functionele Acceptatie Test: http://sandermol.com/duidelijkheid-over-de-functionele-acceptatie-test.
Hetzelfde plaatje heeft ook aan enkele van onze leveranciers laten zien wat wij nodig hebben als klant. We willen de zekerheid dat het systeem werkt zoals afgesproken. Die zekerheid moet aan het wateroppervlak komen bovendrijven in de vorm van bewijs dat de juiste dingen bekeken zijn. Het is aan de leverancier om in te schatten hoe uitgebreid dit nodig is. En hadden we daar niet een menukaart voor?
Een blik in de toekomst
De eerste ervaringen met de menukaart zijn positief. Het geeft snel inzicht en zorgt er achteraf voor dat de keuze voor een bepaalde testzwaarte geëvalueerd kan worden. Misschien is het ook iets voor jouw bedrijf? In dat geval hoor ik graag jouw ideeën en ervaringen!
Ondertussen ga ik volop door met het simpel en begrijpelijk maken van testen. Zonder al te veel toe te geven op diepgang en kwaliteit. Een hele klus, waardoor ik inmiddels een bureaublad vol met plaatjes en schema’s heb. Een volgende keer, wat mij betreft in de TestNetNieuws in aanloop naar het voorjaarsevent, zal ik daar eens een selectie uit laten zien.
Succes met schaalbaar en simpel testen!
NieuwsMagazine
Ik wil even ingaan op de alinea “We willen de zekerheid dat het systeem werkt zoals afgesproken.” etc. Deze zekerheid dient de leverancier te bieden door haar systeemtest. In de afgelopen jaren heb ik bij de acceptatietesten van mijn opdrachtgever moeten constateren dat zijn leverancier niet in staat bleek om releases (vrijwel) foutloos aan te leveren. Het blijkt dus ook “boven water” heel belangrijk te zijn om te testen dat het systeem werkt zoals afgesproken. Wat er overigens weer toe kan leiden dat “onder water” de leverancier nog meer bezuinigt op haar testinspanning, want de klant haalt zelf wel de rest van de fouten eruit…
Bedankt voor je reactie, Ton. Dit is precies het dilemma waar we bij ons bedrijf mee zitten. We hebben veel leveranciers en niet één kon aantonen dat hun product voldoende werkt. Of ze zagen de noodzaak er niet van, omdat we ‘een standaard pakket afnemen dat het altijd doet’. Inmiddels heb ik een ‘track record’ opgebouwd, dat een ander beeld laat zien.
Maar ondertussen zijn zowel onze ICT’ers als verzekeringsmannen en -vrouwen het normaal zijn gaan vinden dat ze zelf alles testen, om zo vertrouwen te krijgen. Zonder hulpmiddelen om dekking te bepalen. Vertrouwen staat hier niet gelijk aan zekerheid. Net als bij jouw opdrachtgever is ook bij ons dus nog genoeg werk te doen!