De vraag hoe noodzakelijk testing is en vanaf waar in het proces een tester moet worden ingeroepen is niet nieuw. Meer en meer ligt de nadruk op zo snel mogelijk beginnen testen en de tester zelf ook zo vroeg mogelijk in het proces te betrekken. Nog voor de eerste lijn code wordt geschreven zou er al een idee moeten zijn wat het testen gaat inhouden. Het is echter nog geen alomtegenwoordige waarheid. Dat het echter een goede praktijk is om een tester zo snel mogelijk deel te laten nemen werd pijnlijk duidelijk toen ik de opdracht kreeg om een nieuwe functionaliteit te testen binnen mijn project – een nieuwe betaalmethode.

Het moment dat ik werd toegevoegd aan dit project waren de specificaties uitgeschreven en waren de tickets gecreëerd. Kortom, ik kreeg de boodschap: de documentatie is volledig en al het noodzakelijke was in de tickets gegoten. De ontwikkeling was reeds een tijdje gaande en de eerste versie van de software was testklaar. Gezien de voorgaande boodschap dacht ik dat aan alles was gedacht en dat ik rustig mij kon richten op de tickets zonder teveel vrees iets over het hoofd te zien. Een aanname die ik niet had horen maken.

Gaandeweg werd namelijk duidelijk dat de documentatie die er was wel volledig was, maar dat in de analyse niet aan alles was gedacht. Laat – te laat – in het proces kwamen er nog vragen naar boven die veel vroeger hadden horen te zijn beantwoord. Het werd duidelijk dat een tester een ruimer of soms vollediger beeld heeft van hoe verschillende zaken in elkaar haken. In dit geval was het mijn ervaring met het systeem als geheel in vergelijking met zowel de developer als de analist die het verschil maakte.  

Wanneer je voor iets betaalt, had je dat product ook graag ontvangen. Er moet dus stock zijn en deze moet worden gereserveerd. Nu dit gedeelte vond met de nieuwe betaalmethode op een ander moment plaats. Wat wil zeggen dat ook de reservering van de stock opnieuw ging moeten worden getest. Hier was niet aan gedacht. Het gevolg was niet enkel dat de deadline in gevaar kwam – gezien er meer ging moeten worden getest als verwacht – maar ook dat er nieuwe documentatie moest worden uitgeschreven.

Het is dus altijd een wijze les om iedereen dat aan een project gaat werken zo vroeg mogelijk te betrekken, ‘zelfs’ de tester. Het perspectief als tester mag niet worden onderschat. Deze ziet een systeem niet enkel in delen, maar ook als geheel. De radertjes zowel als de machine. Wat kan helpen bij het creëren van volledige documentatie, vroege teststrategiën en op termijn dus een snel opgeleverd product, van goede kwaliteit!

Bekijk ons GRATIS ON DEMAND WEBINAR over Shift Left Testing

Blog: Matthias.Ingelbrecht