Interview met Bianca de Vree

Bianca de Vree ● bianca.de.vree@politie.nl
Redactie: Lisa Gelijns ● lisa.gelijns@mail.com
Na haar studies Bedrijfsgerichte- en Technische Informatica aan de Universiteit van Nijmegen (destijds de KUN), wil Bianca de Vree zoveel mogelijk werkervaring opdoen. Eerst denkt ze aan de detachering, maar ze kiest voor een grote organisatie met veel verschillende ICT-uitdagingen: de Nationale Politie.
Via opdrachten bij beheer en in projecten op allerlei testgebieden (analyse, coördinatie, management en procesverbetering) en nu als Scrum ontwikkelaar, gespecialiseerd in testen, heeft ze meegeholpen het testen binnen de politie op te zetten en te verbeteren.
Het team waarin je werkt, heeft vanmorgen een bug hunt uitgevoerd. Waarom een bug hunt?
Veel test effort in relatief korte tijd. Het vinden van bugs waar niet eerder aan gedacht was, door gebruik te maken van verschillende disciplines met andere perspectieven. Ook het samenwerken en van elkaar leren om op een andere manier naar de applicatie te kijken is een belangrijke reden.
We krijgen zo gezamenlijk een beeld van wat er is gerealiseerd en daarmee ook een stuk kennisoverdracht aan niet-Scrum teamleden, zoals functioneel- en applicatiebeheer.
We hebben sprints van drie weken en voeren in de ene sprint gebruikerstesten uit en in de andere sprint een bug hunt, als er voldoende functionaliteit is opgeleverd.
Je hebt aardig wat opdrachten op je naam staan. Aan welke opdracht heb je goede herinneringen?
Aan het Intranet project, ongeveer twee jaar geleden. Dit was het eerste project waarbij ik volgens Scrum werkte. Het bewust bezig zijn met toegevoegde waarde, spreekt me erg aan.
Het team raakte goed op elkaar ingespeeld. De vrijheid en het vertrouwen dat we van het management kregen, voelde goed.
In veel projecten heb ik gemerkt dat ik als tester mijn meerwaarde heb moeten bewijzen. Het is dan wel fijn als je op een gegeven moment merkt dat je collega’s wel de toegevoegde waarde van je werk zien met opmerkingen als: ‘Je hebt gelijk, fouten komen inderdaad terug’, ‘Ik wil dat jij er nog even naar kijkt voordat we het opleveren’ en ‘Fijn dat we die test nog hebben gedaan, anders waren die bevinding pas in productie gevonden’.
Als tester ben je veel met kritiek bezig.
Ja, dat voelt wel zo. Ik probeer het niet te zien als kritiek geven, maar als mijn bijdrage om tot het gewenste product te komen. Als ik iets zie wat anders is dan ik had verwacht dan ga ik, afhankelijk van de situatie, met een product owner, analist en/of ontwikkelaar in gesprek en geef ik aan wat ik had verwacht en waarom. Dit zonder direct een oordeel te geven. Alleen als iets overduidelijk een fout is, bijvoorbeeld een typefout, dan vraag ik direct of ze het aanpassen.
Een prettige manier van werken vond ik het om ’s ochtends samen met een ontwikkelaar zijn code van de dag ervoor door te lopen. Mee te denken over hoe verder te ontwikkelen. Samen de unittestscenario’s en functionele testscenario’s te bedenken. Hiermee deden we direct een review van de code, zodat er al veel bevindingen uithaalden. Ook kregen we een gezamenlijk beeld van de testdekking.
Wat is voor jou het verschil tussen een tester en een Scrum ontwikkelaar?
Als Scrumontwikkelaar ben je in staat om elke taak binnen het Scrumteam op te pakken. Helaas heb ik op het ogenblik mijn handen vol aan alle testtaken.
Hoe komen jullie tot de specificaties?
We doen het nu in twee stappen. Eerder was er alleen een workshop met het hele team en een product owner. Ons team heeft twee product owners met elk een andere achtergrond voor de applicatie, namelijk een echte doener van de straat en iemand die meer de achterliggende procesgang kent en alles coördineert. Beide product owners zijn in ons project voor het eerst met Scrum in aanraking gekomen.
Om tot een goed afgestemde backlog te komen is het belangrijk dat zij eerst een goed beeld hebben van wat het product moet doen. In een pre-refinement ondersteund door de informatieanalist stellen ze dit beeld vast als input voor de workshop met het hele Scrum-team. Dan kunnen we ons als team beter richten op het ‘hoe’ van de oplossing.
Zou je als Scrum-master willen werken?
Nee, ik ben een doener en als Scrum-master moet je jezelf buiten het proces plaatsen en het team het werk laten doen. Liever ga ik zelf aan de slag om een mooi product neer te zetten.
Ben je blij dat je in het testvak bent gerold?
Ja en nee. Ik vind het belangrijk dat fouten gevonden worden voordat de gebruiker er last van heeft, maar ik merk dat ik het tastbare daarin mis. Als ontwikkelaar kun je zeggen, kijk ik heb dit gebouwd, dat knopje staat daar. Dat is concreet.
Als tester registreer ik zaken als een teststrategie, automatische testgevallen, bevindingen en een rapportage over het afdekken van de besproken risico’s in relatie tot het in productie. Dit levert de eindgebruiker niet concreet iets op, maar is ondersteunend aan het team. Bijvoorbeeld om te achterhalen waarom we een bepaald productieprobleem niet hebben gevonden en om dit in de toekomst te voorkomen.
Soms weet ik wel dat we hebben afgesproken een deel niet te testen, waar dan toch een fout zit. Dat is altijd lastig; wat doe je wel en wat doe je niet. Voor mij is dit de kern van testen; bepalen wat je wel en niet doet.
Is: ‘Jij test toch alles’ een bekende opmerking?
Ja, die opmerking hoor ik vaak en is ook één van de eerste dingen die ik in een nieuwe team probeer te ontkrachten. Mijn doel is zo snel mogelijk als team vast te stellen, wat we wel en wat we niet gaan testen. En door wie.
Zo is het mooi als we in de al workshop bepalen dat het tonen van bijvoorbeeld een foutboodschap wordt afgedekt in de unittest.
Voel je je, als tester, extra aangesproken als er opmerkingen zijn over de opgeleverde applicatie?
Ja, dat heb ik wel. Voor mij verschilt dat per team. Ik heb dit in sommige teams, of in het begin bij een nieuw team, wel sterk zo ervaren. In de beheerteams en in Scrum-teams die goed draaien, voel ik dat minder. Dit komt volgens mij doordat iedereen in het team zich verantwoordelijk voelt voor de opgeleverde applicatie. En zich dus ook aangesproken voelt als er opmerkingen zijn over de opgeleverde applicatie.
Als er geen tester op een project zit, niemand met testskills, wat zou je dan missen?
Ik vind het lastig, want wat is een testskill? Een analist kijkt ook gestructureerd naar een applicatie en haalt er veel bevindingen uit. Je mist misschien een bepaalde visie. Maar bevindingen die je de eerste twee sprints uit productie terug krijgt, daarvan leert het team.
Een tester wordt wel eens ingezet als iemand die voor verduidelijking van de specificaties moet zorgen.
Dat vind ik tricky, naar mijn mening kan dat ook door een ontwikkelaar, product owner of analist worden gedaan.
Ik heb wel eens gedacht om meer richting informatieanalyse te gaan. Naar mijn mening focust een informatieanalist zich vooral op het inzichtelijk krijgen van het probleem om vanuit mensen te bepalen wat de gewenste oplossing is. Hierbij is het belangrijk om te zorgen dat iedereen eenzelfde beeld heeft bij het ‘wat’. Een tester focust zich meer op het systeem, of deze wel de gewenste oplossing is voor het gestelde probleem. Hierbij ga je van de informatie van de informatieanalist uit. Belangrijk is natuurlijk om scherp te blijven en niet alles voor waarheid aan te nemen. En ook mensen te helpen om vast te stellen of het systeem wel hun probleem oplost.
In een artikel over regressietesten wordt gesteld dat het opmerkelijk is dat een regressietest ‘het’ middel is tegen regressie . Hoe zie jij dat?
Ik ken het artikel niet. Ik zie dat veel systemen aan elkaar hangen. Ik denk dat één mens niet alles kan overzien. Doordat niet bekend is wat de wijziging in het ene systeem voor een effect heeft in het andere systeem treedt er regressie op. Daarom heb je een regressietest.
Dat zou niet opgelost kunnen worden door dingen minder complex te maken?
Ik denk dat we daartoe niet in staat zijn Juist iets simpel maken is het moeilijkste wat er is. Daarvoor heb je veel knappe koppen nodig, terwijl je die niet altijd hebt.
En een regressietest kan deze complexiteit wel overzien?
Nee. Bij het bespreken van een user story doen wij als team een risico-inschatting voor de story. Hiermee kiezen we heel bewust wat de regressietest moet afdekken en proberen we te voorkomen dat een gebruiker zijn dagelijkse werkzaamheden niet meer kan doen.
Heb jij een voorbeeld of een inspiratiebron?
Nee.
Mijn oorspronkelijke ambitie was om dierenarts worden. Nog steeds zijn dieren heel belangrijk voor mij. Echter, dierenarts zijn leek mij te moeilijk. Het is namelijk niet alleen een diagnose stellen, wat al heel lastig is, omdat je niet met dieren kunt praten. Echter, bij het behandelen van dieren speelt ook de emotionele factor van een eigenaar een rol, wat mij niet leuk leek. Het is geen exacte wetenschap. De IT is voor mij makkelijker, omdat het zwart-wit is. Het is nul of een.
Maar testen is ook niet zo zwart/wit. Vooral het bepalen van de risico’s blijft voor mij een grijs gebied. Nu, door ervaring en sparren met collega’s, kan ik daar beter mee omgaan.
Ervaar je de cultuur bij de politie als een machocultuur?
Ik heb niet het idee dat er een machocultuur is. Ik denk dat juist omdat ik een vrouw ben, ik daar geen last van heb. En werken met mannen vind ik prettig, omdat ik ze duidelijk vind. Ze zeggen gewoon wat ze vinden.
Ik wil ook kunnen zeggen wat ik vind en wat ik denk. Je hoeft het niet met me eens te zijn. Maar ik vind het wel belangrijk dat er geluisterd wordt en dat ik mijn mening mag  geven. Ik heb, binnen deze organisatie, ook nooit gedacht dat ik iets niet mocht of kon, omdat ik een vrouw ben.
Ik heb wel moeite met managers (m/v) met een dubbele agenda. Want, als je iets weet, waarom zou je het achterhouden.
Wat betekent ‘kwaliteit’ voor jou?
Kwaliteit is voor mij dat we als team een goed gevoel hebben bij het systeem. Dit is niet zwart-wit in cijfertjes te meten. Ik heb geleerd in een project dat dit echter veel meer zegt dan het aantal testgevallen, dat voor het afdekken van verschillende risico’s is uitgevoerd.
Zo was er een manager die zei, ‘leuk al je cijfertjes, maar ik wil weten wat je gevoel erbij is’. Ik zei: ‘Het voelt niet goed, ik kan het niet hard maken, maar het voelt niet goed’. We zijn toen samen als team gaan zitten. We kwamen er achter dat meerdere mensen dat gevoel hadden. Door er met elkaar over te praten, konden we ook in een richting gaan zoeken. Door een performance test kwamen we er achter dat er een memory leak in de applicatie bleek te zitten.
Is dat vergelijkbaar met exploratory testing? Dat je het gedrag van een applicatie logt en bepaalde dingen zijn niet zozeer goed of fout, maar eerder opmerkelijk.
Ik vind dat exploratory testing inderdaad een team helpt om dat gevoel bij het systeem te bepalen. Zo had ik tijdens een exploratory test al het gevoel bij een bepaald veld dat het niet op de goede plek op het scherm stond. Het leuke van de bug hunt vandaag was dat ook drie anderen met dezelfde bevinding kwamen. Het is geen harde eis, maar meerdere mensen zien dat iets niet goed zit. Dan blijkt kwaliteit echt een gevoelsding.