Het zou mij niet verbazen als dit een van de oudste vraagstukken is binnen testen: waar stopt het testen van een developer en waar begint de tester? Als de developer te lang doorgaat, wat is dan nog de waarde van een tester? En als de developer te kort test, wordt de tester dan niet misbruikt om als developer slecht werk te kunnen leveren?
Om dit duidelijk te krijgen, is het verstandig om eerst goed te kijken wat het verschil is tussen het testen van een developer en van een tester. Een developer heeft bij het testen als voornaamste doel zijn/haar eigen werk te controleren. Dit houdt in dat de gebouwde story moet voldoen aan de acceptatiecriteria en de binnen het bedrijf of product geldende standaarden. Een tester heeft vaak twee aparte doelen: de second opinion en de testuitbreiding. Bij de second opinion test de tester vaak hetzelfde als de ontwikkelaar, om te controleren of de ontwikkelaar inderdaad het juiste gebouwd heeft. Dit is heel simpel met de reden: iedereen maakt fouten. De uitbreiding van het testen is een ander verhaal. Dit kan per bedrijf verschillen, maar het gaat hier om testen waarvoor binnen het bedrijf geen standaarden zijn. Naast een regressietest, vat hier in ieder geval ook een integratie test in. Een test, waarbij de wijziging niet alleen los wordt getest, maar ook binnen een geheel proces. Of zelfs binnen een keten van applicaties. Maar ook zaken als gebruikersvriendelijkheid, performance, security, enz. kunnen hier invallen. Zaken, die belangrijk zijn, maar niet in concrete, algemeen geldende, criteria zijn vastgelegd.
Als dit het verschil is, waar moet een developer dan op testen? Twee punten blijken al uit het vorige:
- Voldoet een story aan de acceptatiecriteria?
- Voldoet een story aan de geldende standaarden?
Maar developer en tester vormen een team. Wat ik hiermee bedoel? Als je uit gaat van een samenwerking, wil je niet dat een developer iets oplevert, wat door de tester niet of nauwelijks getest kan worden. Iets wat bij de tester op het bordje komt en vervolgens binnen de kortste keren weer teruggestuurd wordt. Omdat de tester al vastloopt, voordat de test ook maar enigszins gevorderd is. Daarom vind ik ook deze twee vragen bij de developer test horen?
- Werkt de wijziging in de applicatie?
- Kan de tester de wijziging testen?
De eerste vraag klinkt misschien alsnog als een ketentest. Laat me daarom het verschil uitleggen. Stel je hebt twee applicaties. In de ene doe je de invoer, in de andere worden rapporten gemaakt. Nu is er een rapport voor een adressenlijst toegevoegd. De invoer is al aanwezig. Maar om het de ontwikkelaar makkelijk te maken, zijn de gegevens voor de adressenlijst gesimuleerd. Dan is het niet de bedoeling dat de ontwikkelaar alsnog alle varianten gaat lopen invoeren, om de adressenlijst te testen. Dat is een integratie test. Wat wel de bedoeling is, is dat de developer zelf adressen invoert via de ene applicatie (twee is al voldoende) en kijkt of deze inderdaad in de adressenlijst komen in de andere. Een korte test, om na te gaan of er geen misverstanden zijn ontstaan tussen de verschillende developers of teams.
De tweede vraag is eigenlijk meer een overdrachtsvraag. Als een developer gebruik heeft gemaakt van technische truukjes om te testen, is de kans groot dat de tester problemen gaat tegenkomen. Nu kan je dat probleem natuurlijk direct naar de tester schuiven. Maar ten eerste is dat vaak maar van korte duur. De tester komt meestal bij je terug met de vragen. Daarnaast heb jij al technische truukjes. En deze kunnen regelmatig de basis vormen om de tester bij testen te helpen. Een teamgenoot vragen een probleem op te lossen, wat jij al hebt opgelost, waarom zou je?
Nee, bovenstaande is niet in beton gegoten. Want wat veel belangrijker is dan een Definition of Testable is een goede samenwerking. Veel beter dan een DoT op basis van een of ander geschreven blog, is een DoT, die is ontstaan, doordat ontwikkelaars en testers met elkaar praten. Elkaars problemen begrijpen.. Proberen het elkaar zo makkelijk mogelijk te maken. Maar tegelijkertijd in de gaten houden, dat het niet de bedoeling is 8 uur extra development tijd te besteden om 1 uur testen te besparen. Net zo min als je 1 uur development tijd wil uitsparen, door de tester 8 uur langer te laten testen. Gebruik de bovenstaande vragen gerust als startpunt. Maar boven alles: praat met elkaar!
