Integrated unit-testen

Na een lange dag noeste arbeid, knikt de ontwikkelaar tevreden. Het stuk code dat hij schreef om een leenbedrag in termijnen terug te betalen is klaar. Hij heeft een aantal testjes uitgevoerd al is dit eigenlijk niet nodig, hij maakt zelden fouten. Nog snel even inchecken en dan kan hij naar huis. Morgen zal zijn programmatuur geïntegreerd zijn in het financiele systeem en is het de beurt aan de testers.

De volgende ochtend start de tester vol goede moed. De geautomatiseerde testen zijn goed doorlopen. Hij wil allen nog wat laatste functionele testen uitvoeren voordat de module die verantwoordelijk is voor termijnbetalingen op leningen uitgerold kan worden. Meer uit nieuwsgierigheid dan dat het een van te voren gedefinieerde test is, voert de tester een terugbetaling is van 0 termijn. Het systeem loopt onmiddellijk vast. Dit is toch niet te geloven? Slechts 1 test en het systeem loopt vast?! Dit had de ontwikkelaar moeten vinden!!

Bovenstaande is een goed voorbeeld van de frustratie waar testers en ontwikkelaars dagelijks mee te maken hebben. Welke bevindingen horen uit een unittest te komen en welke testen voer je uit tijdens de functionele acceptatietest? Had de tester überhaupt een division by zero uit moeten voeren of had hij erop moeten vertrouwen dat de ontwikkelaar dit reeds gedaan had.

Hoe mooi zou het zijn als de verschillende testsoorten geen losse quality gates waren maar een onderdeel van cumulatieve kwaliteitszorg. Iedere testsoort is het begin van de volgende. Geen dubbel werk, geen irritatie en frustratie maar fantastisch teamwerk tussen de ontwerpen, ontwikkelaar en tester? In de komende blogs laten wij zien hoe Qualitier dit principe voor ogen heeft.