De metamorfose van het vak testen

In 1994 begon mijn test-carrière, inmiddels dus zo’n 25 jaar geleden. Als ik terugblik wat een complete metamorfose maakte het vak testen dan door! In de loop der jaren ontwikkelde het testen zich tot een volwassen en cruciaal vak binnen de IT. De afgelopen decennia zag ik het testen veranderen en het is alleen maar belangrijker geworden. Inmiddels is het zelfs niet meer weg te denken en van cruciaal belang.

metamorfose vak testen

Overtuigingskracht nodig

In de jaren ‘90 was dat wel anders. “Testen? O, dat doen we er wel even bij aan het eind van het traject. Tenminste als er nog geld en tijd beschikbaar is,” was destijds vaak te horen.

Bij mijn 1e testproject had ik direct geluk. Zij zagen, toen al, het nut ervan in het nieuwe systeem te testen. Testprojecten daarna, waren soms hele andere koek. Om het management en/of projectteam te overtuigen van het nut van testen, moest ik van goeden huize komen. Het was te kostbaar in geld of tijd. Ja, testen is duur, maar niet testen is veel duurder! Het kostte soms heel veel moeite het testen daadwerkelijk begroot en ingepland te krijgen.

Specificaties en testen

Ook de discussies omtrent het nut van functionele specificaties herinner ik me nog goed. Hoe vaak ze me wel niet vroegen het systeem maar even te testen, zonder enige specificaties. Echter, hoe kan een ontwikkelaar nou weten, zonder specificaties, in welke vorm dan ook, wat te bouwen? En hoe moest ik dan tijdens het testen beoordelen of iets goed of fout was?

Mijn doel was immers niet het gebouwde te testen, want met dat als referentiekader, was het altijd goed. Nee, mijn doel was en is juist; het verschil tussen de wens/eis van de klant/gebruiker én het systeem gedurende het testen naar boven halen. Zo bied ik inzicht in de kwaliteit van het systeem.

Testplan formaliteit

Dan was er nog het opstellen van het testplan (ook nog eens per testsoort), het Detail testplan, een Overkoepelend testplan en Master testplan. Wat ik me herinner, uit deze periode, is dat het schrijven van het testplan meer een formaliteit was. Eigenlijk las niemand het echt. Later werd het dan ook meer een kopieeractie vanuit voorgaande projecten. Tot men uiteindelijk het testplan steeds minder en minder opstelde. 

Tijdrovende testgevallen

Ook de testgevallen hebben een metamorfose ondergaan in het vak testen. Destijds moest je voor het opstellen hiervan aardig wat tijd uittrekken. Dit was namelijk een enorme klus, want alles gebeurde handmatig. Vanaf het uitwerken van de gebruikte testspecificatietechniek t/m het uitschrijven van de teststappen, précondities en de te verwachten testresultaten tot een soort testontwerp.

Vaak gebruikte ik de testspecificatietechniek ‘Proefgevallenanalyse’. Een techniek die nu vergelijkbaar is met Model Based Testen, maar dan geheel handmatig, uitgezonderd het tekenen van het testmodel in ABC Flowcharter en later Visio. In het model nummerde je de testpaden en schreef deze uit in Word, waarbij je alle opvolgende testpaden combineerde voor een hoge testdekking. Op zich nog niet eens het meeste werk. Maar wat te denken van het uitschrijven van de gevonden combinaties (testgevallen) in tekst? Een aardige klus en dan hoopte je altijd maar dat er daarna niets aan de testbasis zou veranderen. Anders kon je (deels) opnieuw beginnen 😉

metamorfose vak testen

Als je dan eindelijk klaar was, met het opstellen en uitwerken van de testgevallen, en daadwerkelijk startte met testen, mocht je hopen op nog voldoende tijd om al die testen handmatig uit te voeren.

Sterk in je schoenen

Als tester moest je destijds ook sterk in je schoenen staan. Immers, als je een fout vond, moest je, weliswaar gewapend met een probleemformulier, naar de ontwikkelaar. Op dit papieren formulier noteerden we als tester het probleem dat we tijdens het testen tegenkwamen. Ikzelf ging vaak met trillende benen op weg naar de ontwikkelaar. Het voelde namelijk alsof ik die ontwikkelaar op zijn vingers kwam tikken voor gemaakte fout(en). Het idee van samenwerken aan één gezamenlijk product kenden we destijds nog niet. Ik moest dus maar hopen dat de betreffende ontwikkelaar het probleem direct oploste zodat ik de her-test op tijd kon uitvoeren. Het gebeurde dan ook regelmatig dat de stapel probleemformulieren op het bureau van de ontwikkelaar hoger en hoger werd. Ondertussen zat ik in de stress, want de einddatum voor het testen naderde of was zelfs al verstreken.

Verandering is uitdaging

Die tijden liggen inmiddels achter ons. Vele onderdelen binnen het testproces zijn inmiddels geautomatiseerd. Echter, ondanks die metamorfose van het vak testen, blijft de IT aan veel verandering onderhevig. Dit kan van invloed zijn op de manier en aanpak van testen. Wat te denken van bijvoorbeeld de introductie van Artificial Intelligence, Machine Learning of nieuwe tooling voor testautomatisering.

metamorfose vak testen

Al deze nieuwe ontwikkelingen binnen de IT volgen we dan ook nauwlettend bij Newspark. Hiervoor hebben we zelfs de KnowledgeSquad opgericht. Hoe delen we alle kennis die we binnen Newspark bezitten en waar zien we nieuwe uitdagingen?

Ook benieuwd naar onze testvisie en de ontwikkelingen binnen Newspark? Je bent van harte welkom om een bak koffie met me te drinken zodat ik je er alles over kan vertellen.

Silvio Cacace