Een werkgever die brieven van testers leest, krijgt 10 keer hetzelfde verhaal over “bugs vinden”, “oog voor detail” en “passie voor kwaliteit”. Wie als 11e iets anders schrijft, valt op. En er is iets wat je in je voordeel kunt gebruiken: de brief zelf is je eerste testopdracht. De vacaturetekst zit vol aannames over wat het team zoekt, en als jij die aannames boven tafel haalt en in je brief weerlegt of bevestigt, demonstreer je de vaardigheid waarop een tester wordt aangenomen. In dit artikel zie je hoe je dat aanpakt, met een complete voorbeeldbrief.
Inhoudsopgave
Vind de aanname in de vacature
Iedere testvacature bevat impliciete aannames. Sommige zijn duidelijk, andere zitten verstopt in een zin. Voorbeelden:
- “We zoeken een tester voor ons multidisciplinaire scrumteam” suggereert handmatig én automatisering, met snelheid en samenwerking als kernpunten.
- “Je bent verantwoordelijk voor onze regressietests” wijst sterk op automatisering en CI/CD.
- “Je test onze app op verschillende devices en browsers” stuurt richting handmatig en exploratory.
- “Je werkt nauw samen met de business” duidt op een tester met een functionele inslag, dichter bij acceptatietesten dan bij testautomatisering.
Lees de vacature 2 keer goed door en stel jezelf de vraag: wat denkt dit team dat ik in de eerste 3 maanden ga doen? Het antwoord stuurt je hele brief. Een handmatig tester die op een automatiseringsrol solliciteert met een brief vol Cypress-ervaring komt geloofwaardig over. Dezelfde tester die op een exploratory-rol solliciteert met dezelfde brief schiet ernaast.
Wat een tester echt doet, en hoe je dat in 1 alinea bewijst
De aanname die ik in vrijwel elke vacature en brief tegenkom: “een tester vindt bugs”. Dat klopt deels, maar het is niet wat een tester onderscheidt. Wat een goede tester doet, is risico inschatten voordat hij test, een testontwerp maken dat de meeste impact afdekt met de minste cycli, exploratory denken inzetten waar test cases tekortschieten, automatiseren wat herhaling is, en de bevindingen zo terugkoppelen dat development ze ook echt kan oplossen.
In je brief weerleg je het cliché met 1 alinea waarin je dat aantoont. Een vondst werkt daarvoor het sterkst. Geen lijstje taken, maar 1 concrete situatie waarin jouw werk verschil maakte:
In een release van onze webshop ontdekte ik met een exploratory test dat het kortingsmechanisme verkeerd rondde bij combinaties van actiecodes. De fout zat niet in de geplande test cases, kwam pas naar voren bij ongewone klantflows en zou na release direct geld hebben gekost. Ik heb het defect gemeld met reproductiestappen en de mogelijke financiële impact erbij, zodat het team het binnen een sprint kon herstellen.
Eén voorbeeld als dit doet meer dan 5 alinea’s met zinnen zoals “ik ben analytisch en gestructureerd”. Geen vondst van dat kaliber paraat? Dan werkt ook een resultaat dat je proces betreft, zoals een regressietijd die je hebt teruggebracht of een testdekking die je hebt verhoogd. De truc is hetzelfde: laat zien dat je verder kijkt dan bugs.
Het cijfer dat een tester onderscheidt
Brieven met “ik werk gestructureerd” werken niet, brieven met 1 hard cijfer wel. Voor testers zijn dit de cijfers die echt aankomen:
- Regressietijd. “Van 8 uur handmatig naar 1,5 uur in Cypress” zegt meer dan elke kreet over efficiëntie.
- Defects vóór release. Aantal gevonden defects en het percentage dat als kritiek werd gekwalificeerd.
- Testdekking of automatiseringsgraad. Welk percentage van de kernfunctionaliteit je geautomatiseerd hebt afgedekt.
- First-time-pass na een release. Hoe vaak de testset bij de eerste run schoon liep.
Kies er 1 voor je brief, kies er 2 of 3 voor je cv, en wees eerlijk over welk cijfer welk product en welke periode betreft.
Voorbeeldbrief Software Tester
Hieronder zie je een complete voorbeeldbrief. Het is dezelfde Bram Kuipers uit het cv voor een software tester, zodat brief en cv 1 verhaal vertellen.
Bram Kuipers
Vestdijk 20, Eindhoven
06 12345678 | bram.kuipers@email.nl
[Naam organisatie]
T.a.v. [naam contactpersoon]
[Adres organisatie]
Eindhoven, [datum]
Betreft: sollicitatie software tester
Beste [naam contactpersoon],
In jullie vacature las ik 2 zinnen die mij naar het toetsenbord brachten: dat jullie regressietijd uit de hand loopt en dat het team intern strijdt over wat handmatig en wat geautomatiseerd moet. Dat is precies het soort vraagstuk waar ik graag aan werk, en waar ik bij TechFlow Solutions afgelopen jaren mee bezig ben geweest.
Bij TechFlow heb ik de regressietijd voor onze webapplicatie van ruim 8 uur teruggebracht naar 1,5 uur door een geautomatiseerde testsuite in Cypress op te bouwen voor de stabiele kerntests, en exploratory testing en risico-inschatting in te zetten voor de releases met veel wijzigingen. In een recente release vond ik op die manier een rondingsfout in het kortingsmechanisme die niet in de test cases stond, maar bij ongewone actiecode-combinaties zou zijn opgevallen door klanten. Door de impact en reproductiestappen direct mee te geven, was de fout binnen een sprint hersteld.
Wat me bij [naam organisatie] aanspreekt, is dat jullie het testteam dichter bij development willen zetten in plaats van als laatste schakel. Dat is precies waar de winst zit op regressietijd. Ik wil de eerste maanden gebruiken om met het team in kaart te brengen welke tests geautomatiseerd lonen en welke handmatig moeten blijven, zodat de balans bij volgende releases klopt.
Ik praat er graag over door in een gesprek. U bereikt mij op 06 12345678 of via bram.kuipers@email.nl.
Met vriendelijke groet,
Bram Kuipers
Let op de opening: die haakt direct aan op iets specifieks uit hun vacaturetekst. Dat doet 2 dingen tegelijk: het laat zien dat je de vacature hebt gelezen, en het positioneert je meteen als iemand die problemen ziet, niet alleen taken.
Starter of overstapper vanuit development
Heb je nog geen testfunctie op je naam staan, dan past dezelfde aanpak, maar haal je de vondst uit een eigen project of een aangrenzende rol. Stap je over vanuit development, dan is dat juist een kracht: je leest code en denkt mee over hoe iets stuk kan gaan. Maak dat expliciet:
Beste [naam contactpersoon],
Ik werk al 4 jaar als developer, maar de afgelopen 2 jaar betrap ik mezelf erop dat ik vooral plezier haal uit de stap voor en na de implementatie: het bedenken hoe iets stuk kan gaan, en de bevestiging dat een release schoon door de pijplijn rolt. Onlangs haalde ik mijn ISTQB Foundation en ik bouwde voor onze eigen webapp een kleine testset in Playwright, waarmee ik 3 bugs ving die in de PR-review niet waren opgevallen.
Heb je een traineeship gevolgd of zoek je er een, vermeld dat dan expliciet. Testdienstverleners leiden starters vaak op tot ISTQB-niveau, en een werkgever ziet liever een eerlijke startersbrief met richting dan een opgeklopt verhaal.
Cv Software Tester
Een brief leest pas overtuigend als het cv ernaast dezelfde verhaallijn doortrekt: hetzelfde testtype, dezelfde tools, dezelfde cijfers. Werk daarom je cv voor een software tester net zo zorgvuldig uit. Twijfel je of je niet eigenlijk de richting van een developer of functioneel beheerder op wilt, vergelijk dan met het cv voor een developer of het cv voor een functioneel beheerder, zodat je per vacature kiest welke rol je echt wilt.
