Tester, praat ook eens met een ontwikkelaar

Veel mensen die me op conferenties horen spreken weten dat ik graag de kloof tussen IT en business wil overbruggen. Ik denk dat het belangrijk is om ons te richten op de behoeften van onze managers en stakeholders.  Testen wil een antwoord geven op de vragen van de business en de eventuele zorgen die zij hebben met betrekking tot de IT-oplossing reduceren. Goed begrip van de business en communicatie met onze stakeholders is daarom cruciaal voor succes.  

Testers praten gelukkig steeds meer met de business  en we leren onze stakeholders steeds beter begrijpen. Maar hoe goed begrijpen we de ontwikkelaars?

Inzicht in implementatiekeuzen
Recent woonde ik een tutorial bij van BJ Rollins over combinatorisch testen.  Tijdens de sessie besefte ik nog eens dat om echt goede testscripts te maken, je inzicht moet hebben in de keuzes die ontwikkelaars maken. BJ Rollins heeft zelf een ontwikkelachtergrond en maakte nog eens duidelijk dat je zonder deze kennis, eigenlijk niet echt weet wat je test.

Vaak testen we tijdens systeem- en acceptatietesten op functioneel niveau. Als we dit doen zonder kennis te hebben van de technische keuzen loop je als tester kans om veel tijd te verliezen met triviale zaken en belangrijke situaties te missen.

Voorkom het dubbel uitvoeren van testen
Technische kennis van generieke componenten en libraries helpen je te voorkomen dat  je testen dubbel uitvoert of overbodige bevindingen registreert.  Recent ving ik een stukje van een conversatie op tussen een tester en een ontwikkelaar. De ontwikkelaar had de bevindingenregistratie bekeken en concludeerde het volgende:   “Ik zie dat je voor elk scherm de sortering hebt getest en bevindingen hebt aangemaakt. Dat is hartstikke mooi, maar weet je dan niet dat elk scherm dezelfde sorteerroutine aanroept. Als je een fout vindt in de sortering, dan horen we dat graag, maar daarvoor hoef je niet alle schermen af te testen.  Als het mis gaat op het ene scherm, dan gaat het ook mis in de andere schermen.”

Functioneel gezien kan het interessant lijken om te kijken hoe het systeem omgaat met invalide invoerwaardes. Technisch gezien is het belangrijk om invalide invoer zo vroeg  af te vangen, dat de achterliggende applicatie er geen last van heeft. De ontwikkelaar kiest er daarom vaak voor om  een eventhandler de invoer te laten valideren. Als je voorbij de eventhandler wilt komen om de achterliggende code te raken, moet je als tester valide invoer aanbieden.  Om  de juiste keuzes in te maken en de applicatie goed te prikkelen, dien je uiteraard goed inzicht in de beslislogica te hebben.  Als tester kun je helemaal los gaan op de interface en veel nadruk leggen op het testen van invalide invoer, maar zonder kennis van de oplossing,  loop je het risico dat 99% van je testen triviaal is.

Testen op functioneel of technisch niveau
Op basis van functionele specificaties kunnen we goed testsituaties (zoals bijv. beslispunten en equivalentieklassen)  afleiden en opnemen in onze testgevallen. In de onderliggende code zitten echter vaak nog veel en andere testsituaties.
Bij het toepassen van combinatorisch maken we veelvuldig gebruik van equivalentieklassen op functioneel niveau . Inhoudelijke kennis van de implementatie-keuzen helpt ons  om ook equivalentieklassen op technsch niveau  mee te nemen in onze testen. 

Dezelfde argumentatie gaat ook op voor het testen van berichtinterfaces, maar er zijn meer situaties te bedenken waar implementatiekeuzes bepalen wat we werkelijk zouden willen testen.  Wanneer worden bijvoorbeeld gegevens opgeslagen bij het doorlopen van een wizard, welke conversies worden er uitgevoerd op de Enterprise Service  bus, hoe wordt er gequeried op de DB en hoe worden taken afgehandeld en geprioriteerd in het systeem?

Kennisuitwisseling op dieper technisch niveau
Goed inzicht in ontwerpkeuzes is een must voor adequate test scripts. Samenwerking met ontwikkelaars en begrip van software ontwikkeling is hiervoor cruciaal.
Binnen Agile groeien test en ontwikkeling naar elkaar. Kruisbestuiving en kennisuitwisseling tussen beide disciplines is daarmee een stuk gemakkelijker. Ook in een traditionele omgeving is het belangrijk om technische kennis te gebruiken bij het testontwerp. We werken wel samen met de ontwikkelaars maar dit gebeurt voornamelijk op een functioneel niveau. Kennisuitwisseling op dieper technisch niveau zie ik veel minder vaak.

Betekenisvolle en nauwkeurige testresultaten
Tijdens de Tutorial van BJ Rollins werd me duidelijk dat we als tester goed de brug kunnen slaan tussen de business en IT.  Door goed aan te sluiten bij de wereld van de business zorgen we ervoor dat onze testresultaten worden begrepen, gebruikt en gewaardeerd. Door aan te haken bij de ontwikkelaars  kunnen we ervoor zorgen dat we geen triviale maar daadwerkelijk relevante testen uitvoeren. Dit maakt dat onze resultaten nauwkeurig zijn en daarom betekenisvol.

Laten we daarom bij de risicoanalyse een goede rol te geven aan de senior ontwikkelaar. Hij kan aangeven welke risico’s voortvloeien uit de gemaakte implementatiekeuzes. Een walk-through door ontwikkelaars en business analisten vlak voor de  oplevering van de release aan het testteam draagt bij aan gepaste aandacht voor de kritische onderdelen.  De eerder aangehaalde  dialoog geeft een voorbeeld van waardevolle inzichten die we kunnen krijgen als we de tijd nemen om naast de ontwikkelaar gaan zitten.

———————————————
Derk-Jan de Grood werkt als testexpert bij Valori. Hij adviseert organisaties bij het inrichten en verbeteren van hun testactiviteiten. Als productmanager werkt hij aan innovaties in het Valori dienstaanbod. Daarnaast spreekt en publiceert hij met groot enthousiasme over ontwikkelingen in het testvak.

© Derk-Jan de Grood.