Interview met Jeroen Bultje

Interview met Jeroen Bultje ● jeroen.bultje@nice.com

Kan je iets over jezelf vertellen?
Ik ben 34 jaar oud en ben geboren in Groningen. Tijdens mijn eind-stage op het HBO ben ik in 2003 met testen in aanraking gekomen. Eerst verliep dit ongestructureerd. In 2004 ben ik als trainee bij Sogeti in dienst gekomen en ben daar met ‘testen volgens TMap’ opgeleid. Na een aantal jaren ben ik bij Polteq in dienst gekomen en sinds 2012 werk ik bij NICE als teamlead QA.
Ik ben getrouwd met Manon en onze dochter Fien is nu alweer bijna 2 jaar oud. Elke dag rijd ik met de auto van mijn woonplaats Velserbroek naar NICE in Alkmaar. Heerlijk, tegen de file inrijden. In mijn vrije tijd duik ik veel, zowel in Nederland als in het buitenland. Ik ben op dit moment Master Scuba Diver en heb 100+ gelogde duiken.
Hoe ziet je werk er uit als tester bij NICE?
Bij NICE werk ik als teamleider QA voor de afdeling ‘Compliance Recording Platform’. De afdeling maakt software die wordt gebruikt voor call recording binnen organisaties (bijvoorbeeld: financiële organisaties en call centers). Voor financiële organisaties is dit belangrijk om op deze manier alle klantinteracties op te nemen en hiermee te voldoen aan wetgeving als Dodd-Frank. Het team bestaat uit zeven QA engineers in Alkmaar en zes QA engineers en developers in Odessa (Oekraïne).
Wij werken in Scrumteams en elke ochtend start met de daily stand-ups van de teams. Na de stand-ups volgen reguliere gesprekken met de teams, met product owners en met leveranciers. Daarnaast worden ook (test)verbeteringen doorgevoerd binnen teams, projecten of binnen het bedrijf. Dit wordt geïnitieerd door middel van een TPI assessment maar ook op basis van feedback van klanten.
Ik vind het werken in Agile teams een verademing. De teams nemen zelf verantwoordelijkheid voor de projecten, voor de sprints en voor de kwaliteit. Dit is een leuke manier van werken.
Met zo’n internationaal verspreid team, is het dan niet lastig om Agile te zijn’?
Agile werken gaat juist erg goed in internationaal verspreide teams. De teams zitten bij elkaar in één locatie. Het is dus niet zo dat mensen binnen één team in verschillende landen (met dito tijdzones) werken aan projecten. De teams werken net als de Nederlandse teams, alleen de product owners zitten op een andere locatie. Communicatie gaat via telefoon, conference calls, Skype, e-mail. Het prettige is dat er maar één uur tijdsverschil met Odessa is, dus kunnen ze dezelfde werkuren aanhouden.
Waarom heet de rol QA engineer? Doe je ook echt aan Quality Assurance?
Als je naar de betekenis van QA kijkt, passen de werkzaamheden meer bij ‘testen’. Maar omdat wij een internationaal bedrijf zijn en de functienamen gelijk willen hebben, noemen wij het QA engineers, QA leads, etc. Wij merken dat dit makkelijker werkt met leveranciers en klanten.
De focus is gericht op het goed (vooral functioneel en performance) testen van producten. Veel van onze software wordt (na onze interne R&D en QA testen) gecertificeerd door onze leveranciers. Dit is omdat enerzijds de leveranciers de kwaliteit willen controleren en anderzijds omdat onze eindklanten alleen gecertificeerde software willen hebben draaien.
Heb je een bepaalde kennisgebied als tester?
Ik heb veel gewerkt bij banken, verzekeraars en bij utility bedrijven. De focus is altijd per project en bedrijf verschillend. Verder bemoei ik mij de laatste paar jaar (onder andere binnen de werkgroepen van TestNet) met usability testing. Een interessant onderwerp, waar weinig bedrijven écht de focus op hebben. Daarentegen is testautomatisering nog steeds een gebied waar ik niet heel vertrouwd mee ben. Het afgelopen jaar ben ik mij hierin aan het bijscholen, en het is een prachtige specialisatie.
Wat vind je ‘prachtig’ aan testautomatisering?
Testautomatisering is iets wat al erg lang bestaat, maar zeker in agile projecten belangrijk voor de toekomst is. Omdat gedurende sprints steeds meer functionaliteit wordt toegevoegd aan een applicatie, zal de hoeveelheid testen (nieuwe testen + regressietesten) ook toenemen. De beste manier om hier grip op te houden is, volgens mij, door testen te automatiseren.
De ontwikkelteams kunnen vaker en sneller builds opleveren, die al geslaagd zijn in een unittest. Als de testers in deze teams ook sneller deze build kunnen deployen op de testomgeving en een serie tests kunnen uitvoeren, kun je als team je kwaliteit bewijzen in een fractie van de vroegere doorlooptijd. Dat vind ik ‘prachtig’ aan testautomatisering.
Heb je tips voor andere testers hoe men het best kan beginnen met testautomatisering volgens jou?
Het is belangrijk te analyseren wat je waarom wilt automatiseren. Als je naar handmatige tests kijkt, zijn veel verificaties en checks impliciet. Pas als deze expliciet zijn, kun je een methode bedenken om de test- en controlestappen geautomatiseerd te laten uitvoeren. Kies eerst voor een methode en daarna voor een tool die dit kan. Als je dit omgekeerd uitvoert, maak je het voor jezelf nodeloos moeilijk.
Hoe voer jij usability uit?
Bij usability testing wordt al snel de link gelegd naar usability labs met eye-tracking, heat maps en andere complexe technieken. Voor veel projecten een stap te ver.
In de afgelopen twee jaar hebben de leden van kennisgroep Usabililty testing (één van de werkgroepen binnen TestNet) laten zien dat je binnen korte tijd veel toegevoegde waarde kan creëren met technieken als ‘paper prototyping’ en ‘thinking aloud’.
Paper prototyping is een goedkope methode voor testontwerp om in een vroeg stadium design ideeën uit te proberen. Met materialen die voorhanden zijn, maak je ruwe schetsen. Het voordeel van een prototype is dat je weinig tijd kwijt bent aan bijeenkomsten waarin alle voors en tegens besproken moeten worden. Natuurlijk kun je de paper prototypes ook digitaal opstellen. Goede tooling hiervoor is onder andere Fleks Ray (http://fleksray.org/skins/edding/Edding.html) en Balsamiq (http://builds.balsamiq.com/b/mockups-web-demo/)
Thinking aloud is een techniek waarbij aan de tester wordt gevraagd om, tijdens de uitvoer van een vooraf opgesteld scenario, hardop alle gedachten te vertellen. De zaken die je normaal alleen bedenkt (‘hé, deze melding had ik eerder in het proces verwacht’ of ‘dit snap ik niet’) worden expliciet gemaakt omdat ze uitgesproken worden. Leuk en leerzaam, zeker als je het projectteam mee laat kijken en luisteren.