Testen in een Agile team: "Vertrouw niemand, maar vertrouw iedereen"

Als tester is het je taak om alles en iedereen te controleren. Er niet vanuit te gaan dat iemand altijd goed werk levert. Als Agile teamlid is het je taak om je team te vertrouwen. Ervan uit te gaan dat iedereen altijd goed werk wil leveren. Hoe werk je binnen deze tegenstrijdigheid? Wanneer vertrouw je iemand en wanneer niet?

Het woord "Vertrouwen" is wel veelgebruikt, maar niet altijd in dezelfde betekenis. Je kan er bijvoorbeeld op vertrouwen, dat iemand altijd voor je klaar staat. Maar tegelijkertijd er niet op vertrouwen, dat deze persoon goede code oplevert. Het belangrijkste vertrouwen van een tester is gericht op het opleveren van goed werk. En dan maakt het niet uit of dit een deel van de applicatie of een document is.

Zelf kom ik tot een lijst van drie manieren van vertrouwen, die voor een tester van belang zijn:

1. Het vertrouwen dat iemand goed werk oplevert
2. Het vertrouwen dat iemand goed werk WIL opleveren
3. Het vertrouwen dat iemand goed werk KAN opleveren

Het vertrouwen dat iemand goed werk oplevert

Wat moet je hierover aan een tester uitleggen? Het werk van een tester is controleren. Controleren of een ontwikkelaar goed werk heeft geleverd. Controleren of de specificaties goed zijn opgeleverd. Dus zelfs als je dit vertrouwen hebt, moet je handelen alsof je het vertrouwen niet hebt.

Het vertrouwen dat iemand goed werk wil opleveren

Een Agile team kan alleen goed werken als de teamleden elkaar vertrouwen. Maar als je er niet op mag vertrouwen, dat iemand goed werk oplevert, waar vertrouw je dan op binnen een team? Simpel: je vertrouwt erop dat iemand goed werk wil opleveren. Dat er niemand in het team als doel wil hebben om een slecht product op te leveren. Dat iedereen in het team er alles aan doet om het product zo goed op te leveren als mogelijk is. Als het niet lukt, vertrouw je erop dat hier redenen voor zijn. Redenen, die in de ogen van de ander goed zijn. Of anders oorzaken, die een ander niet wist bij het maken van het eindproduct. Dit vertrouwen is centraal, zonder dat kan een Agile team geen team zijn. Dus zelfs als je dit vertrouwen niet hebt, moet je doen alsof je het vertouwen wel hebt.

Dit is echter niet zo simpel als bij het vorige onderwerp. Niet alleen is het vaak moeilijk op te brengen, zelfs als je het hebt is het soms moeilijk te bewijzen aan de ander. Want hoe toon je het vertrouwen dat iemand goed werk wil opleveren?

Het antwoord ligt in je woordgebruik. Voorkom zinnen als "Je bent fout", "Je hebt je vergist", "Je hebt slecht werk geleverd". En vervang ze door zinnen als "Ik snap niet waarom", "Kan je me uitleggen waarom". Combineer dit bij voorkeur met een compliment als "Ik zie dit soort fouten anders niet bij je", "Ik weet dat je X ook belangrijk vind", "Ik weet dat je een goede X bent". En daarna: luisteren, doorvragen, luisteren, doorvragen. Net zo lang tot je het besluit begrijpt. Je hoeft het er nog steeds niet mee eens te zijn, maar zorg ervoor dat je het begrijpt. En als je het begrijpt, maar nog niet overtuigd bent, dan is het moment om te vertellen wat jij had gewild. En vergeet dan ook vooral niet te vertellen waarom.

Centraal staat een positieve benadering, waarbij de wil om goed werk te leveren niet ter discussie wordt gesteld. Wat wel ter discussie wordt gesteld is het resultaat en het proces naar het resultaat. Maar het vertrouwen blijft onbesproken en daarmee overeind. Uit eigen ervaring kan ik je vertellen: je zal vaker overtuigd worden, dan je van tevoren verwacht.

Het vertrouwen dat iemand goed werk kan opleveren

Soms wil je wel, maar kan je niet geloven dat iemand goed werk op wil leveren. Want als hij het wil en hij kan het, waarom gebeurt het dan niet? Om het makkelijker te maken, kan het handig zijn om na te gaan of iemand het wel echt kan. Heeft iemand de kennis en vaardigheden om goed werk te leveren? Als je weet dat iemand een junior developer is, is het ook veel logischer als er meer fouten in het opgeleverde werk zitten. En als iemand pas sinds kort aan het product werkt, is het makkelijker te geloven dat deze persoon iets over het hoofd heeft gezien. Maar het gaat hier ook om andere factoren. Wanneer de druk hoog is, bijvoorbeeld door een harde deadline, voelen mensen zich vaak gedwongen stappen over te slaan. Stappen, die de kans op een goed product niet ten goede komen.  Als mensen een opdracht hebben gekregen, die tegenstrijdig is met een goed product, bijvoorbeeld "Doe gewoon wat er staat", kan dit ook de kwaliteit niet ten goede komen.

Het vertrouwen dat iemand goed werk op kan leveren kan dus terecht zijn, maar er kunnen zaken spelen die je niet weet. Zaken waardoor een persoon nog moet leren hoe je goed werk oplevert, zich gedwongen voelt slechter werk op te leveren of misschien zelfs andere prioriteiten heeft. Deze zaken weten, maakt het makkelijker een persoon te begrijpen. Waar het op neerkomt, is dat je weet hoe je teamleden aankijken tegen organisatie en werk. Hoe lang ze werken in hun functie, in het bedrijf en in het team. En tegen welke problemen ze aanlopen. Hier interesse in tonen geeft anderen al meer het gevoel dat je echt deel van het team wil zijn. Maar daarnaast kan jij ook hopelijk beter begrijpen, wat er speelt, als het werk niet het gewenste niveau heeft. En dat kan flink schelen in emoties, als je onverwachts slecht werk onder ogen krijgt.

Testdata management als al je klanten anders zijn

De testdata beschikbaar in de database is belangrijk. Zowel om je testen betrouwbaar, als om je testen reproduceerbaar te houden. Als je slechts 1 klant heb, kan je de data van deze klant eenvoudig als basis gebruiken. Als je klanten veel overeenkomsten hebben, kan je de deze overeenkomsten als basis gebruiken. Maar wat als al je klanten uniek zijn? Door een applicatie met een oneindig aantal mogelijkheden? Hoe kom je dan tot een basis?

Bepaal de datagroepen

De testdata is te verdelen in vier groepen. Elke groep vraagt een andere aanpak. Het is daarom van belang om eerst goed te beseffen welke data in welke groep hoort.

De gebruikersdata met regelmatig onderhoud
Het aanmaken van opdrachten of het opstellen van een planning. Het zijn werkzaamheden die regelmatig plaatsvinden. Aan de data van deze groep wordt minimaal een keer per week wel data toegevoegd, data gewijzigd en data verwijderd. Ze bevinden zich vaak in de hoofdprocessen van de applicatie, juist door hun regelmatige gebruik. En het is daarom ook van groot belang dat juist deze processen altijd goed blijven werken, ongeacht wat de gebruiker invoert.

De gebruikersdata met incidenteel onderhoud
Voor deze groep is het moeilijker om voorbeelden te geven. Waar het ene bedrijf een vaste groep klanten heeft, waardoor deze nauwelijks onderhouden worden, zal het andere bedrijf elke dag klanten toevoegen, wijzigen of verwijderen. Waar het ene bedrijf een vaste groep producten heeft, zal een ander bedrijf bijna elke week de producten moeten onderhouden. Maar het gaat hier om data die door de gebruikers van de applicatie zelden ingevoerd worden. Mocht er zich een probleem voordoen, is dat zeker lastig, maar een probleem in deze groep zal niet snel blokkerend zijn voor het gebruik van de applicatie.

De systeemmanagementdata met regelmatig onderhoud
Een systeembeheerder, applicatiebeheerder of iemand anders in een soortgelijke functie kan vaak data invoeren, waar andere gebruikers niet zomaar bij kunnen. Hierbij gaat het om zaken als modules, parameters, instellingen en gebruikersrechten. Hoewel ook hier het onderscheid tussen regelmatig en incidenteel van belang is, liggen de periodes wel anders. De data met regelmatig onderhoud in deze groep, kan rustig een keer in de paar maanden zijn. Het is data, die gebruikt wordt om de processen te optimaliseren. Of data die gebruikt wordt om een bedrijf te laten groeien of inkrimpen. Of misschien data, die gebruikt wordt om processen aan de wensen van klanten of andere belangrijke partijen aan de passen. Denk hierbij aan de velden, die je op je scherm ziet. Dit kan voor iedereen slechts eenmalig ingesteld worden. Maar er kan ook behoefte zijn om hierin flexibel te zijn, zodat het scherm niet het werkproces bepaald, maar het werkproces het scherm. En je regelmatig kan kijken of de huidige indeling nog naar tevredenheid is.

De systeemmanagementdata met incidenteel onderhoud
In de meeste gevallen is dit data die na installatie eenmaal wordt ingevoerd en daarna (bijna) nooit meer wordt aangepast. De ingevoerde data is de werkelijkheid en daar kan vaak ook niet van afgeweken worden. Bijvoorbeeld door regels, wetten of voorschriften. Of omdat aanpassingen niet alleen vraagt om een aanpassing in data, maar ook vraagt om een hele andere werkwijze of proces. Of men besluit natuurlijk gewoon dat de huidige situatie voldoet, waardoor er geen behoefte is aan aanpassing. Een typisch voorbeeld hiervan is de modules, die in een applicatie staan ingesteld. Dit wordt vooral bij installatie bepaald en zal daarna nauwelijks meer wijzigen.

Bepaal de data

De gebruikersdata met regelmatig onderhoud
Het onderhouden van deze data is zo belangrijk, dat het verstandig is weinig gebruik te maken van testdata in de database. Juist om zoveel mogelijk varianten in onderhoud te testen, maak je de data zoveel mogelijk keer op keer opnieuw aan. Gebruik makend van je kennis, ervaring of testtechnieken kan je bepalen wat er nodig is. Om tijd te besparen bij handmatig testen of om een automatische test niet te lang te maken, kan het toch verstandig zijn om wat data beschikbaar te hebben. Deze data is dan het gevolg van opgestelde testcases en kan dan ook volgens deze criteria in de database worden opgenomen.

De gebruikersdata met incidenteel onderhoud
Omdat het niet altijd belangrijk is dit in de test mee te nemen, is het wel verstandig hiervoor een goede set in je database te krijgen. Wat hiervoor van belang is, is dat je weet welke data effect heeft op de andere gebruikersdata of hun bijbehorende schermen. Een logische gedachte is een relatie waar instellingen ingevoerd kunnen worden hoe de factuur eruit moet zien. Maar denk ook aan verschillende varianten in namen, zoals wel of geen tussenvoegsels en de keuze tussen Dhr. of Mevr. Als deze belangrijke varianten in je database voorkomen, kan je snel en flexibel testen.

De systeemdata met regelmatig onderhoud
Deze data hoort eigenlijk niet te bepalen hoe de database bepaalt wordt, maar vooral hoeveel testdatabases je eigenlijk tot je beschikking wilt hebben. De redenering rond deze data is eigenlijk gelijk aan de redenering rond gebruikersdata met incidenteel onderhoud. Dus als dit mogelijk is, kies voor verschillende varianten. Maar systeemdata is vaak maar op 1 plek in te stellen, waardoor het niet mogelijk is deze varianten toe te voegen. De varianten zijn echter zo belangrijk, dat je ze uitgebreid mee wil testen, zonder steeds veel tijd aan voorbereiding kwijt te zijn. De meest verstandige keuze is daarom hiervoor meerdere databases te maken. B.v. per belangrijke groep klanten (overheid of particulier) of grootte van de klant (veel of weinig medewerkers). Mocht dit niet mogelijk zijn, zal je geen keus hebben om de voorbereiding toch in je testcases te doen.

De systeemdata met weinig onderhoud
Hier gaat het vooral om het neerzetten van een goede basis. Belangrijke variaties in deze instellingen, zoals de keuze of een veld wel of niet verplicht is, moeten worden opgevangen als aanpassingen/voorbereidingen in je testcases. Maar de basis moet zoveel mogelijk voldoen aan de instellingen van zoveel mogelijk klanten. Noem het de database van de "gemiddelde klant". De instellingen, die het meest gebruikt worden. De waardes, die het meest ingevoerd worden. Dit zorgt ervoor dat, als het werkt, de kans ook het grootste is dat het werkt voor het grootste deel van je klanten.

Het vervolg

Besef dat dit onderwerp altijd aandacht blijft vereisen. Je klanten veranderen, je applicatie verandert, je bedrijf verandert. Dit is dan ook geen eenmalige actie, waarna je er nooit meer bij stil hoeft te staan. Als je je testen uitvoert, blijf dan regelmatig stilstaan of je data nog voldoet. Als de applicatie wordt uitgebreid of aangepast, kijk of de data in de huidige database nog steeds alle groepen goed afdekt. En besef ook dat je de eerste keer vergissingen kan maken, hoe zeer je ook je best doet. Blijf hier aandacht aan besteden en blijf er goed over nadenken. Zodat jouw testdata in de database je optimaal blijven ondersteunen bij je testen.