Je hebt misschien weleens gedacht dat medior tester worden vooral een kwestie van tijd is. Nog wat ervaring erbij, nog een paar projecten, en dan rol je vanzelf een niveau omhoog. Logisch dat je dat denkt, want zo wordt het vaak gebracht.
Maar zo werkt het meestal niet.
Wat we in de praktijk zien bij testers die we begeleiden, is dit: de één blijft vooral test cases afvinken, de ander stuurt al mee op wélke release wel of niet live mag. Het verschil zit niet alleen in ervaring. Het zit vooral in de impact die je maakt op kwaliteit en op de beslissingen daaromheen.
Het patroon dat we vaak zien: testers groeien sneller zodra ze niet alleen melden wat er stuk is, maar ook uitleggen wat het risico betekent voor de release, de klant en het team.
Die impact kun je bewust opbouwen.
Hieronder staat dat kader: zeven vaardigheden, drie valkuilen en een plan voor de komende 90 dagen.
Van junior naar medior: wat verandert er nou echt in je rol?
De kern van de overstap is verantwoordelijkheid. Als junior ben je vooral bezig met uitvoeren: je krijgt test cases, je voert ze uit, je meldt wat er misgaat. Als medior stuur je mee op kwaliteit. Je bepaalt niet alleen óf iets werkt, maar ook wat dat betekent voor de release.
Even concreet, want dat verschil klinkt abstracter dan het is.
Stel: er zit nog een uur in de sprint en er komen twee bugs binnen. De ene: een tekstlabel in de footer staat verkeerd gespeld. De andere: bij afrekenen met creditcard blijft de bevestigingsknop soms hangen. Een junior meldt netjes allebei de bugs en wacht op wat het team ermee doet. Een medior zegt erbij: "die footer los ik na de release wel op, maar die bug in de checkout houdt de release tegen. Want een klant die niet kan afrekenen, haakt af, en dat raakt direct conversie en klantvertrouwen."
Dezelfde twee bugs, maar de medior vertaalt ze naar een keuze. Dat is het verschil.
In de praktijk betekent die stap dat je:
- Test op risico, niet op volledigheid. Je vraagt je bij elke wijziging af: wat gaat hier het meeste pijn doen als het stukgaat, en test ik dát eerst?
- Ziet vroeg waar de kwaliteit inzakt, zodat het team nog kan bijsturen. Niet pas op de laatste dag.
- Testresultaten omzet in advies. Niet "hier zijn 14 bugs", maar "hier zijn 14 bugs, deze 3 blokkeren, de rest kan mee naar de volgende sprint".
- Ownership neemt op het proces. Je wacht minder op instructie en denkt actief mee over hóé het team beter test.
Kortom: een junior zorgt dat de tests kloppen. Een medior zorgt dat het team de juiste beslissingen neemt.
7 software tester vaardigheden die je als medior tester direct impact geven
Niet elke vaardigheid weegt even zwaar voor je volgende stap. Deze zeven maken in de praktijk het grootste verschil. Bij elke vaardigheid staat wat het is, hoe het er op een werkdag uitziet, én waarom het je verder brengt.
1. Risicogestuurd denken
Je bepaalt de volgorde van je tests op basis van risico. Je doet aan risicogestuurd testen, ook wel risk-based testen, in plaats van de lijst gewoon van boven naar beneden af te werken.
Stel: er staat een release klaar met wijzigingen in vijf schermen. In plaats van alles even grondig te testen, vraag je je af: welke van deze vijf raakt geld, data of veiligheid? Zit er een wijziging vlak bij de checkout of bij de login? Daar begin je. De "over ons"-pagina die ook iets veranderde? Die komt achteraan.
Onder tijdsdruk kun je nooit alles testen. Wie op risico stuurt, vangt de dure bugs vroeg en durft te zeggen "dit stukje test ik bewust niet, want het risico is klein". Dat maakt je betrouwbaar, juist als het spannend wordt.
2. Sterk testontwerp
Bij sterk testontwerp schrijf je test cases die niet alleen kloppen, maar die een ander ook snel kan uitvoeren en reproduceren.
Vergelijk deze twee. "Test of het inloggen werkt" versus "Log in met geldige gegevens, verwacht resultaat: je komt op je eigen dashboard. Log in met een bestaande gebruikersnaam maar een fout wachtwoord, verwacht resultaat: een nette, algemene foutmelding ('gebruikersnaam of wachtwoord onjuist'), geen technische fout of witte pagina." De tweede kan een junior, een developer of jij later opnieuw uitvoeren, zonder jou erbij.
Een test case die alleen jij begrijpt, is de helft waard. Zodra je scenario's reproduceerbaar en overdraagbaar zijn, kan het hele team ermee werken. Zo schaalt je werk verder dan je eigen uren. (Meer hierover lees je in UAT test cases en effectieve gebruikersscenario's.)
3. Heldere bugcommunicatie
Een goede bugmelding zorgt dat een developer meteen kan doorpakken, zonder eerst drie keer terug te hoeven vragen.
Het verschil zit 'm in de details. Niet: "de knop doet het niet". Wel: "bij afrekenen met iDEAL op Safari 17 blijft de knop 'betalen' grijs. Reproduceerbaar in 3 van de 3 pogingen. Blokkeert de checkout. Screenshot + console-log in de bijlage." De developer weet nu wát er misgaat, wáár, hoe vaak, en hoe erg.
Een vage bugmelding kost een developer onnodig veel tijd om te reproduceren, als het al lukt. Een scherpe melding is snel duidelijk en vergroot de kans dat je bug meteen goed wordt opgepakt.
4. Samenwerken met development en product
Je zoekt afstemming vroeg, in de refinement en tijdens de sprint, niet pas als iets al af zou moeten zijn.
In de refinement wordt een nieuwe feature besproken. In plaats van te wachten tot hij "testklaar" is, stel je nu al de lastige vragen: "wat gebeurt er als de gebruiker halverwege wegklikt? En als het bedrag nul is?" Vaak blijkt dan dat niemand daaraan gedacht heeft.
Een randgeval dat je in de refinement benoemt, kost weinig om op te lossen. Datzelfde randgeval dat je pas als bug meldt op de laatste testdag, kan leiden tot een hotfix, een herplanning en een lastige sprint. Vroeg meepraten voorkomt verrassingen aan het eind.
5. Basiskennis van test automation
Je hoeft geen fulltime automation engineer te zijn, maar je snapt wat wél en niet slim is om te automatiseren.
In de praktijk herken je de saaie, herhaalbare checks die elke release opnieuw moeten: de login, de checkout, een paar kritische formulieren. Díé stel je voor om te automatiseren. De eenmalige, verkennende test van een nieuw scherm doe je gewoon met de hand, want daar is een script zonde van de tijd.
Automatisering op de verkeerde plek kost meer onderhoud dan het oplevert. Wie de juiste dingen automatiseert, houdt tijd over voor het denkwerk dat een mens wél moet doen. En je maakt de brug naar development kleiner. (Wil je die kant op? Lees dan van handmatig testen naar test automation.)
6. Patronen in je bugs en metrics lezen
Hier gaat het om signalen gebruiken: bug trends, regressie en root cause. Niet om elke sprint opnieuw blanco beginnen.
Aan het eind van een paar sprints kijk je terug en zie je dat opvallend veel bugs uit dezelfde module komen. Dat is waarschijnlijk geen toeval. In plaats van daar alsmaar losse bugs te blijven melden, trek je aan de bel: "deze module levert structureel problemen op, zullen we hem eens goed onder de loep nemen?"
Losse bugs melden is symptoombestrijding. Een patroon zien en benoemen raakt de oorzaak. Daarmee groei je van "iemand die fouten vindt" naar "iemand die het team helpt betere software te bouwen". (Die beweging beschrijven we ook in soft skills die jou een betere tester maken.)
7. Ownership en durven adviseren
Ownership betekent hier: je durft een kwaliteitsadvies te geven, mét onderbouwing én mét de afweging die erbij hoort.
Voorbeeld: de product owner vraagt of de release vrijdag live kan. In plaats van "ik weet het niet, er zijn nog wat open puntjes" zeg je: "de kernfunctie is getest en stabiel. Er staan nog twee kleine bugs open in het profielscherm. Mijn advies: ga live, maar zet die twee bovenaan voor maandag. Wachten kost ons een week, en het risico is klein." Je geeft een advies, geen slag om de arm.
Een team kan pas op je bouwen als je een kant durft te kiezen. Advies mét trade-off ("dit wint tijd, dit is het risico") laat zien dat je meedenkt op het niveau waarop beslissingen vallen. Dat is een belangrijk verschil tussen uitvoeren en meebeslissen.
De 3 valkuilen die je groei het vaakst afremmen
Zelfs sterke testers blijven soms hangen. Niet omdat ze iets verkeerd doen, maar omdat bepaalde gewoontes logisch voelen terwijl ze je groei ongemerkt kleiner maken. Herken je er één, dan weet je meteen waar je winst zit.
Valkuil 1: alleen technisch willen excelleren.
Je duikt diep in tooling, frameworks en scripts, en dat is knap. Maar zonder zicht op wat het product moet doen, test je soms heel goed op de verkeerde plek. We zien testers die een geautomatiseerde test suite bouwen voor een feature die nauwelijks gebruikt wordt, terwijl de checkout ondergetest blijft. Techniek wordt pas echt sterk als je hem koppelt aan productrisico.
Valkuil 2: wachten tot je het helemaal zeker weet.
Je ziet een risico, maar je wacht met melden tot je het volledig hebt uitgezocht. Heel begrijpelijk, want je wilt zorgvuldig zijn. Alleen is het dan soms al de laatste sprintdag, en wordt bijsturen lastig. De vuistregel: een voorlopig risico dat je op dag twee deelt, is vaak waardevoller dan een perfect uitgewerkt risico op dag tien. Je hoeft niet alles zeker te weten om het team alvast alert te maken.
Valkuil 3: je impact te stil houden.
Je doet goed werk. Je voorkomt bugs, je vangt risico's af. Maar als je het niet benoemt, ziet het team vooral dat de sprint rustig doorloopt. Dat is fijn, maar voor jouw groei soms lastig, want voorkomen werk is minder zichtbaar dan gevonden werk. Daar kun je iets aan doen zonder te gaan opscheppen: maak kort duidelijk welk risico je zag, wat je deed en wat dat opleverde. Daar helpen de volgende twee secties bij.
Een 90-dagenplan om medior-impact te bouwen
Je hoeft niet te wachten op een officieel opleidingstraject of een functioneringsgesprek. Dit ritme kun je zelf starten: drie maanden, drie fases.
Maand 1: focus kiezen.
Kies eerst één kernvaardigheid uit de zeven hierboven. Niet drie, één. Zeg dat het risicogestuurd testen wordt. Leg dan een eerlijke nulmeting vast: hoe bepaal je nu je testvolgorde? Waarschijnlijk vooral op gevoel of op volgorde van het ticket. Prima, dat is je startpunt. Vraag tot slot een developer en je product owner om gerichte feedback: "waar mis ik volgens jullie nu risico's?" Zo weet je waar je aan werkt.
Maand 2: toepassen in sprints.
Nu ga je het bewust doen. Bij elke sprint stel je jezelf hardop de vraag: wat is hier het grootste risico, en test ik dát eerst? Documenteer twee concrete situaties waarin je aanpak verschil maakte. Bijvoorbeeld: "week 3: ik zette de nieuwe kortingsberekening bovenaan omdat die geld raakt; bleek inderdaad een rekenfout bij stapelbare kortingen, gevonden vóór de release." Bespreek wekelijks even kort wat werkte en wat niet. Klein houden, elke week.
Maand 3: zichtbaar maken en uitbouwen.
Vat je resultaten samen in een korte samenvatting van een paar regels (zie het volgende kopje voor hoe). Koppel je leerpunten aan een teamafspraak: stel bijvoorbeeld voor om risico's voortaan standaard in de refinement te benoemen. En kies dan je tweede vaardigheid om op voort te bouwen.
Na 90 dagen heb je niet alleen een nieuwe vaardigheid, maar ook voorbeelden waarmee je laat zien dat je hem toepast. Dat helpt bij je volgende stap.
Hoe je als tester je impact zichtbaar maakt
Doorgroeien gaat sneller als je je bijdrage kunt laten zien. En nee, dat hoeft niet met ingewikkelde dashboards of urenlange rapportages. Drie simpele formats zijn genoeg. Elk kost je vijf minuten.
1. Korte testupdate per sprint.
Drie zinnen: wat was het grootste risico, wat heb je gedaan, wat was het effect? Bijvoorbeeld: "Grootste risico deze sprint: de nieuwe importfunctie kon dubbele records aanmaken. Ik heb dat vroeg gemeld en met de developer een controle toegevoegd. Effect: geen datavervuiling bij de livegang."
2. Korte go/no-go update.
Vlak voor een release: wat is getest, welke risico's staan nog open, en wat is je advies? Bijvoorbeeld: "Kern getest en stabiel. Open: twee kleine UI-bugs in het profielscherm. Advies: live, deze twee maandag oppakken."
3. Maandelijkse leerpunten.
Eén keer per maand: welk patroon zie je in de bugs, en wat stel je voor? Bijvoorbeeld: "Veel regressiebugs rond de kortingslogica. Voorstel: die module een vaste plek geven in de regressietest."
Doe dit een paar sprints, en er gebeurt iets. Je laat zien dat je niet alleen test, maar actief meestuurt op kwaliteit. En dát is precies het beeld dat je nodig hebt om die medior-stap te maken.
Veelgestelde vragen
Welke software tester vaardigheden zijn het belangrijkst voor medior niveau?
Als je er drie moet kiezen: risicogestuurd denken, sterk testontwerp en heldere communicatie. Dat zijn meestal de grootste versnellers, want ze bepalen of je onder druk de juiste dingen test én of je bevindingen ook echt worden opgepakt.
Wat is belangrijker, technische kennis of communicatie?
Allebei nodig, maar ze doen iets anders. Technische kennis bepaalt hoe goed je analyse is. Communicatie bepaalt of die analyse ook impact krijgt. Een scherpe bug die niemand begrijpt, verandert niks. Een goed uitgelegde bug wél.
Hoe laat ik zien dat ik klaar ben voor de volgende stap?
Door consequent te laten zien welke kwaliteitsbeslissingen jij hebt verbeterd. Welke risico's ving je vroeg af? Welk advies gaf je, en wat leverde het op? Gebruik de drie formats hierboven, dan bouw je vanzelf een dossier van je eigen impact op.
Hoelang duurt het om van junior naar medior te groeien?
Dat hangt minder af van jaren dan je denkt. Sommige testers maken de stap relatief snel, anderen blijven langer hangen in uitvoerend testwerk. Het verschil zit vaak in bewust werken aan de juiste vaardigheden én je impact zichtbaar maken. Precies wat dit artikel behandelt.
Tot slot
Een sterke medior tester herken je aan impact, niet aan een functietitel. Of je nou junior op je kaartje hebt staan of niet: zodra je op risico stuurt, vroeg meepraat en je bijdrage zichtbaar maakt, gedraag je je al als een medior. De titel volgt dan vanzelf.
Je hoeft er niet op te wachten. Kies deze week één vaardigheid, pas hem bewust toe in je volgende sprint, en schrijf op wat het opleverde. Begin klein, houd het praktisch, en geef jezelf de ruimte om erin te groeien.
Wil je die stap maken in een team waar kwaliteit écht serieus wordt genomen, en waar meedenken juist wordt gewaardeerd? Kijk dan eens rond bij onze open QA-vacatures en zie welke rol past bij jouw volgende niveau.
Gerelateerde artikelen:
