NieuwsMagazine

De leukste / ergste testervaring van Gerard Kruijff

Auteur:  Gerard Kruijf ● gerard.kruijff@centric.eu
Gerard_AG_03
Gerard Kruijf geeft op eigen wijze zijn ervaring en zienswijze weer over de ontwikkelingen in het testvak sinds 1996.
De pen werd mij aangereikt door Patrick Duisters. Met Patrick volgde ik tien jaar geleden de ISEB-Practitioner training, voorloper van ISTQB-Advanced. Ik denk daar nog altijd met veel plezier aan terug.
Voor mijn testervaring gaan we terug naar het jaar 1996. Ik werkte bij een softwarehuis, een bedrijf waar administratieve pakketten werden gebouwd. Testen was niet aan de orde. Gewoon goed je best doen als programmeur, dan hoeft er niet getest te worden. Dat bespaart tijd en geld. Wat de gevolgen waren, hoef ik niet te uit te leggen. ‘Bouw goeie software, doe allemaal je stinkende best. Ze knopen me op in de hoogste boom’, was een terugkerende uitspraak van de directeur. Het advies van een taskforce softwaretesten verdween in de prullenbak: te duur.
In datzelfde jaar werd ik via dat bedrijf gedetacheerd bij een uitkeringsinstantie, nota bene als softwaretester. De eerste versie van TMap was net van de persen gerold, de inkt was nog nat. Ik had nog nooit van gestructureerd testen gehoord, laat staan van het V-model. Ik moest het allemaal gaan leren. De testcoördinator had een exemplaar van TMap en ik begreep niet dat je zo’n dik boek over testen kon schrijven.
Bij dit bedrijf waren de ontwikkel- en testprocessen redelijk volwassen. Er was onder meer sprake van configuratiebeheer en een aantal uitgangspunten van testen volgens TMap werd goed nageleefd.
Het acceptatietestteam waar ik deel van uitmaakte, zat aan de ene kant van de gang. De ontwikkelaars aan de andere kant. Halverwege was een hok waar de gemeenschappelijke printer stond. Ik had opdracht gekregen een stukje software te testen dat aangepast was vanwege een bevinding in productie. Nu is het bepalen van een uitkering een lastige zaak. Je hebt met een groot aantal parameters te maken. Hoe de samenhang hiervan de uitkomst beïnvloedde, kon ik als niet-materiedeskundige moeilijk vaststellen.
Groot was mijn verbazing toen ik uit de printer een documentje met testgevallen zag komen van de programmeur die met de bewuste software bezig was. Mooi, dacht ik, kan ik controleren of wij op één lijn zitten, of ik de juiste testgevallen heb. Op dat moment kwam de programmeur het hok binnen en griste de printjes uit mijn handen. ‘Jullie moeten je eigen testgevallen opstellen’, riep hij. En ja, volgens TMap moest dat ook. De systeem- en acceptatietest zijn twee verschillende, los van elkaar staande testsoorten. Testen dient onafhankelijk te gebeuren, zoveel wist ik al. Ik probeerde nog iets te roepen over afstemming, samenwerking, overleg. Maar dat vond geen gehoor. De scheidslijn tussen de afzonderlijke disciplines kon niet duidelijker getoond worden.
Tegenwoordig gaat dit allemaal totaal anders. Het afstemmen, samenwerken en overleggen is onderdeel van het voortbrengingsproces. Als tester werk je nauw samen met de ontwerper, de programmeur, de architect en ook de gebruiker. Met elkaar werk je aan een ‘goed’ eindproduct. De schuttingen, waar vroeger de verschillende producten overheen werden gegooid, zijn afgebroken en er is transparantie en communicatie. Althans, daar wordt naar gestreefd. Maar toen, twintig jaar geleden, was dat niet aan de orde.
Na deze eerste kennismaking met het vakgebied, werd ik enthousiast. Met testen wilde ik verder.
Het was de tijd dat testen bij de meeste bedrijven en organisaties nog niet serieus werd genomen. Er moest geknokt worden om het op de agenda te krijgen: Testen is een vak! En dat is het geworden. Als docent en als consultant op het gebied van softwarekwaliteit en testen heb ik de volwassenwording van het vakgebied meegemaakt.
Het meeste plezier beleef ik aan het kweken van testbewustzijn bij, en aan het overdragen van kennis aan mensen die geen tester zijn, of als tester willen starten. Trainingen geven aan ontwerpers, ontwikkelaars, gebruikers die in Agile projecten werken en zich testbeginselen willen eigen maken. Of mensen met autisme, die softwaretester willen worden; een zeer dankbare categorie, waar goede resultaten mee te behalen zijn.
Testen is niet meer weg te denken, zelfs niet nu de afzonderlijke functie van tester ter discussie staat. Gaat die verdwijnen? Gaan we weer terug naar af? Of ontstaat er een nieuwe generatie van kwaliteitsbewuste developers? Een interessante ontwikkeling, dat is zeker.
De pen geef ik door aan Arthur van Rossum. Met Arthur deel ik de interesse in testen en doceren. En ook hebben wij allebei iets met goede muziek.

één reactie

  1. Hoi Gerard,
    Waarom testen programmeurs en gebruikers bij een wetgevingsondersteuningssysteem apart?
    Dat is nodig als er een verschillende testbasis is. Voor de gebruiker de wet, voor de programmeur een technisch ontwerp.

Geef een reactie

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *