Leiderschap bij testen: testen als team

Soms kan het betekenen dat er helemaal geen testers zijn (dun-dun-duuu), waarbij businessanalisten en ontwikkelaars de volledige verantwoordelijkheid voor het testen op zich nemen.

Naar links verschuiven is niet nieuw—voorvechters van testen verkondigen de leus "test vroeg, test vaak" al vele jaren. Al in 1993 werd voorgesteld dat alle artefacten in een gefaseerd proces—zowel documentatie als software—getest konden (en vaak moesten) worden.

Naar links verschuiven draait vooral om het eerder in het proces laten plaatsvinden van het nadenken over testen.

Hoewel Waterval destijds de dominante levenscyclusbenadering was, zijn het aantal of de duur van de fasen niet belangrijk. Het onderliggende principe was dat de kennisbronnen die richting geven aan het ontwerp en de ontwikkeling van software ter discussie moeten worden gesteld of getest. 

In een gefaseerd project kan dit formele beoordelingen omvatten. In een Agile-project kan de tester (of ontwikkelaar, businessanalist of gebruiker) scenario's aandragen die de auteur van een vereiste of gebruikersverhaal ertoe aanzetten concrete voorbeelden uit te werken en te bespreken voordat er code wordt geschreven.

Dit zijn de belangrijkste veranderingen die gepaard gaan met het verschijnsel van naar links verschuiven:

1. De benadering van gedragsgestuurde ontwikkeling (BDD) heeft ontwikkelaars, gebruikers/businessanalisten en testers in staat gesteld samen te werken rond wat zakelijke gebruikersverhalen genoemd kunnen worden. Testgestuurde ontwikkeling wordt al 15 jaar of langer door veel ontwikkelaars gebruikt. Tegenwoordig wordt BDD breder toegepast, omdat het betere samenwerking in agileteams stimuleert en daarnaast BDD-tools introduceert die door ontwikkelaars kunnen worden gebruikt. Het is een eenvoudigere test-eerstbenadering.
2. Continue oplevering (CD) bestaat al 5-10 jaar en vindt zijn oorsprong in de sterk geautomatiseerde benaderingen voor bouwen en releasebeheer die door grote onlinebedrijven zijn ontwikkeld. Het wordt nu door de meeste organisaties met een onlineaanwezigheid toegepast.
3. CD heeft het opleverproces door automatisering gesystematiseerd en versneld. Het bracht echter ook de vertragingen in productie, implementatie en infrastructuurwijzigingen aan het licht die eerder werden verhuld door trage processen voor bouwen, testen en opleveren. DevOps is een culturele mentaliteitsverandering waarbij ontwikkelaars veel nauwer samenwerken met operationele medewerkers. Op dit moment verschijnen er bijna dagelijks nieuwe tools en promoten leveranciers DevOps als 'de volgende grote ontwikkeling'. Het is een sterk gehypete en dynamische situatie.
4. SMAC, oftewel sociaal, mobiel, analyse en cloud, vertegenwoordigt een verschuiving in de manier waarop organisaties omgaan met veranderingen in bedrijfsvoering en systemen binnen het mobiele domein. Experimenten binnen het bedrijf, geïmplementeerd als wijzigingen in productiesystemen, worden op gedetailleerd niveau gemonitord. De vastgelegde "Big" data wordt verwerkt en op basis van de verkregen analyses worden zakelijke beslissingen genomen.

Veelvuldig experimenteren met productiesystemen maakt bedrijfsinnovatie mogelijk 'op de snelheid van marketing'. Experimenteren vormt de kern van wat in de jaren 2010 de belangrijkste hype was – digitale transformatie.

Get Free Access

Get regular tech leadership wisdom for delivering better software and systems.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Name*

First name Last name

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Business email*

Create Password*

This field is hidden when viewing the form

LinkedIn profile

This field is hidden when viewing the form

Company's AI adoption maturity

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

Testen als activiteit, niet als rol

Het naar links verschuiven verandert de rol van testers. De herverdeling van testen die door de aanpak van naar links verschuiven in gang is gezet, maakt duidelijk dat testers niet uitsluitend verantwoordelijk zijn voor testen; testers zijn niet langer eigenaar van het testen. 

Als je erover nadenkt, hadden zij nooit echt het testen in eigendom, maar in projecten bestond er een stilzwijgend begrip dat testers een vangnet boden voor alles wat de rest van het team, en dan met name ontwikkelaars, tijdens het testen deed. Als ontwikkelaars onder tijdsdruk stonden en hun testen beperkten om op te leveren, werd het vangnet door de testers geboden.

Testen is nu een activiteit, geen rol.

Ontwikkelaars passen betere testpraktijken toe en zorgen voor meer inzicht in hun werk. Goed testen op componentniveau of met unittests heeft specifieke doelen die zich onderscheiden van systeemtesten (als voorbeeld). Daarom kan de reikwijdte (of hoeveelheid) van testen op systeemniveau worden verminderd. 

De juiste verdeling van testdoelen en het testen om die doelen te bereiken is het primaire doel van de teststrategie. Helaas werden ontwikkelaars tot voor kort niet effectief verantwoordelijk gehouden, waardoor zij vertrouwden op late systeemtests als compensatie.

Een verschuiving naar links maakt ontwikkelaars meer verantwoordelijk.

Over het geheel genomen wordt de verantwoordelijkheid voor het testen herverdeeld, waardoor de rol van de tester verandert. Testers doen mogelijk minder tactische tests, maar hun strategische bijdrage neemt toe. Testers kunnen eigenaar zijn van de teststrategie, vereisten ter discussie stellen, overleggen met belanghebbenden en een nauwere relatie met ontwikkelaars opbouwen om beter testen door ontwikkelaars en testautomatisering te ondersteunen.

Een nieuwe rol

Verschuiving naar links houdt in dat feedback moet worden gegeven zodra het mogelijk is om daarmee het team te helpen doelen, vereisten, ontwerp of implementatie te begrijpen, ter discussie te stellen en te verbeteren. 

Gebruikers, businessanalisten, ontwikkelaars en het hele softwareteam moeten bereid zijn om op deze manier feedback uit te wisselen. Soms is er weerstand, maar het algemene doel is simpelweg om een beter, beter geïnformeerd project uit te voeren.

De eenvoudigste manier om dit gedrag samen te vatten is: ‘vroeg betrokken raken’—zo vroeg mogelijk. Neem deel aan de discussie en werk samen aan ideeën, vereisten en aan elke fase waarin de uitkomst van die fase invloed heeft op de waarde van het uiteindelijke projectresultaat. 

Kort gezegd stelt de tester informatiebronnen ter discussie, ongeacht of deze bronnen belanghebbenden, gebruikers, ontwikkelaars, bedrijfsverhalen, documenten of precedenten zijn.

De meest gebruikelijke aanpak is om door middel van voorbeelden kritische vragen te stellen. In alle fasen kunnen deze voorbeelden als tests worden beschouwd. Ze kunnen na gebruik snel worden weggegooid of worden vastgelegd in testautomatisering of handmatige controles. Deze voorbeelden kunnen puur tactisch worden gebruikt om denkfouten van mensen aan te wijzen, of aan ontwikkelaars worden verstrekt als ideeën of uitgangspunten voor ontwikkelaarstests. Ze kunnen ook als hulpmiddel bij coaching worden gebruikt om gebruikers of ontwikkelaars te laten zien hoe betere tests kunnen worden gemaakt.

Beschouw je softwareproject als een proces waarin kennis wordt verworven. Deze kennis wordt gedurende het hele project verzameld en ontwikkelt zich vaak in de loop van de tijd. Het doel van een verschuiving naar links is deze kennis te waarborgen door dicht bij de bron ervan kritische vragen te stellen en te testen, en er waar mogelijk voor te zorgen dat de kennis wordt vertrouwd voordat deze in code wordt vastgelegd.

Verschuiving naar links bouwt voort op de test-eerstfilosofie. Agile heeft samenwerking en snelle feedback altijd gestimuleerd—een verschuiving naar links kan worden gezien als een doelgerichte aanpak voor snelle feedback. Als je team een aanpak voor testen met een verschuiving naar links toepast, kunnen de juiste hulpmiddelen het verschil maken. Bekijk onze samengestelde lijst met hulpmiddelen voor softwaretesten om de beste keuze voor je team te vinden.

Agile testinterventies

De aanpak van verschuiving naar links is fundamenteel voor een teststrategie voor agileprojecten. In een agilecontext kan een teststrategie worden gezien als een reeks testinterventies. In alle projecten zijn er cruciale momenten waarop mogelijkheden ontstaan om feedback te verzamelen en te geven. De tester moet zich op deze cruciale momenten richten en klaarstaan om op die momenten bij te dragen.

In je eigen projecten moet je cruciale momenten identificeren waarop interventie mogelijk is en vaststellen welke keuzes je als team tijdens het testen kunt maken. Moet de tester bijvoorbeeld unittests voor ontwikkelaars schrijven, voorbeelden geven om hen op weg te helpen, of hen coachen om hun testvaardigheid te verbeteren? Alleen jij en je nieuwe softwaretestteam kunnen dit beslissen.

We gebruiken een typisch Scrumproces om te laten zien hoe testinterventies binnen de Scrumaanpak kunnen worden gepositioneerd. Interventies vinden plaats op projectniveau (of releaseniveau) of op het niveau van een sprint. Het onderstaande diagram toont een weergave op projectniveau en de vijf belangrijkste interventies.

Het ter discussie stellen en definiëren van gebruikersverhalen zijn de momenten waarop de tester respectievelijk een gebruikersverhaal en de voorgestelde acceptatiecriteria voor een verhaal valideert. Integratietests controleren of nieuwe functies correct met andere functies en met het systeem als geheel zijn verbonden. Systeem- en gebruikersacceptatietests worden uitgevoerd wanneer dat passend is.

Een project heeft meestal meerdere sprints en de vier sprintinterventies worden in het onderstaande diagram weergegeven. De dagelijkse stand-up biedt de mogelijkheid om de voortgang te melden, zorgen te uiten, risico’s te identificeren of tijdens de sprint opgeworpen vragen en ontvangen antwoorden te bespreken. 

Het verfijnen van gebruikersverhalen en bijdragen aan testen door ontwikkelaars zijn dagelijkse activiteiten die plaatsvinden als onderdeel van gesprekken met gebruikers, analisten en ontwikkelaars. De tester voegt tests van ontwikkelaars en nieuwe systeemtests toe aan een groeiende verzameling tests die geautomatiseerd moeten worden.

In de onderstaande tabel ziet u een tabeloverzicht van interventies door testers. Uw proces kan anders zijn of gebaseerd zijn op Scrum met variaties, maar de tabel identificeert typische interventietypen in een typisch Scrum-proces. Mogelijk hebt u op verschillende momenten in uw eigen unieke proces meer of minder actieve interventies.

Ik raad u aan de kritieke momenten te identificeren, uw bijdrage voor te stellen en met uw team te onderhandelen. U biedt meer leiderschap en begeleiding op het gebied van testen, in plaats van u simpelweg vrijwillig aan te melden om de verantwoordelijkheid voor het testwerk op u te nemen. Deze aanpak maakt het veel eenvoudiger om uw waarde voor het team aan te tonen, maar het team heeft mogelijk niet zoveel testers nodig.

Relaties met ontwikkelaars

In sommige organisaties kan de relatie tussen ontwikkelaars en testers worden gekenmerkt door wantrouwen, verwijten en antagonisme. In het ergste geval is de relatie toxisch: ontwikkelaars testen nauwelijks en testers worden beschouwd als de dienaren van ontwikkelaars. Testers nemen gedrag aan dat co-afhankelijk kan worden genoemd en gedragen zich als slachtoffers. Deze situatie is precies wat de naar-linksverschuivingsaanpak probeert te voorkomen.

Er zijn veel metaforen gebruikt om een goede relatie tussen ontwikkelaars en testers te beschrijven. We gebruiken een manier van samenwerken tussen piloot en navigator om te illustreren hoe een vergelijkbare relatie tussen ontwikkelaars en testers kan werken. Maar laten we eerst naar een disfunctionele situatie kijken.

De navigator stapt niet in het vliegtuig, maar zwaait naar de piloot wanneer die opstijgt. De navigator reist afzonderlijk en langzaam met de bus. Uiteindelijk komt de navigator op de bestemming aan, maar na enige tijd blijkt dat het vliegtuig in de verkeerde richting is gevlogen en tegen een berg is neergestort.

De navigator had toch in het vliegtuig moeten zitten? Stel u voor hoe piloten en navigators in werkelijkheid samenwerken.

• De piloot kan het vliegtuig niet zonder navigator besturen. De navigator kan het vliegtuig niet besturen.
• De piloot en navigator stemmen het vluchtplan af voordat de reis begint.
• De piloot stijgt op en bestuurt het vliegtuig.
• De navigator volgt de koers en vergelijkt die met het vluchtplan en/of de eindbestemming, rekening houdend met ongunstige gebeurtenissen, in het bijzonder het weer.
• De navigator zoekt naar afwijkingen, zet een nieuwe koers uit en informeert de piloot, die de vliegroute aanpast.
• Enzovoort.

De relatie tussen piloot en navigator is vergelijkbaar met die tussen programmeur en tester. Het heeft evenmin zin om ontwikkelaars en testers in afzonderlijke teams onder te brengen die opeenvolgend werken. Toch is dat wat we de afgelopen dertig jaar of zo traditioneel hebben gedaan – vooral bij grotere, langdurige projecten.

De naar-linksverschuiving herverdeelt het denken over testen en haalt dit in feite naar voren. Testers werken als volwaardige partners van ontwikkelaars, net zoals navigators dat doen met piloten:

• De tester en ontwikkelaar verzamelen gezamenlijk informatie over de vereisten.
• Doorgaans stelt de tester vereisten ter discussie aan de hand van voorbeelden (mogelijke of daadwerkelijke testideeën).
• De ontwikkelaar denkt na over de implementatie en gebruikt voorbeelden om richting te geven aan het ontwerp.
• De tester, ontwikkelaar, belanghebbenden, gebruikers en analisten komen tot een gedeeld begrip van een betrouwbare vereiste.
• De tester staat voortdurend in contact met de ontwikkelaar en bespreekt wijzigingen in vereisten, risico's op fouten en hoe testen kan aantonen dat functies werken of fouten aan het licht kan brengen.
• De tester bekijkt hoe de functie waaraan wordt gewerkt zowel op technisch niveau als op het niveau van de gebruikersreis wordt geïntegreerd en hoe de integratie kan worden getest.
• De tester kijkt verder dan de directe functie waaraan de ontwikkelaar werkt om toekomstige uitdagingen, risico's, wijzigingen en onzekerheden te identificeren.
• Enzovoort.

De zojuist beschreven ideale relatie tussen ontwikkelaar en tester ontstaat niet automatisch. Het team moet deze uitwerken. U kunt elk van de bovenstaande activiteiten zien als interventies, maar interventies zijn niet altijd comfortabel voor alle betrokkenen. Geef deze aanpak de beste kans van slagen door elk interventietype helemaal aan het begin met uw partners te bespreken – zodra u weet dat u nauw zult samenwerken.

Interventies zijn, net als goede gebruikersverhalen, aanleidingen voor gesprekken.

Voor elk interventietype is instemming van beide partijen nodig dat het een geldige handeling is. Om zich daar prettig bij te voelen, moeten beiden erop vertrouwen dat de ander een goede reden heeft om vragen te stellen, kwesties aan te kaarten en vereisten of begrip ter discussie te stellen tijdens stand-upbijeenkomsten, planningssessies of retrospectieven.

More Articles

• Kwetsbaarheidsscanning versus penetratietesten
• 5 belangrijkste fasen van het proces voor kwetsbaarhedenbeheer
• Een handleiding voor QA’s over databasetests in 2026

Uitdagingen van gedistribueerde en uitbestede teams

In de bovenstaande discussies is stilzwijgend aangenomen dat iedereen in hetzelfde team werkt en op dezelfde locatie zit. Wanneer de werklast van een softwaretestteam wordt uitbesteed en/of naar het buitenland wordt verplaatst, spelen verschillende negatieve factoren een rol. De tabel toont drie typische factoren om rekening mee te houden.

Fysieke (en temporele) scheiding	Teams kunnen verspreid zijn over een kantoor, verschillende gebouwen, plaatsen, landen en tijdzones. De communicatie wordt verstoord, de kanalen zijn beperkt en er stroomt minder informatie.
Verschillende motivaties	Het leveranciersteam werkt voor een organisatie die wordt betaald om het testwerk uit te voeren. Uiteindelijk is hun motivatie winst maken. Bij contracten met een vaste prijs bestaat de druk om snel te werken. Bij contracten op basis van tijd en materialen bestaat de verleiding om het werk te rekken.
Culturele verschillen	Nationale en culturele verschillen kunnen aanzienlijk zijn. Soms kost het tijd om deze te erkennen en er rekening mee te houden.
Bedrijfs- en organisatiecultuur	Ook bedrijfsculturen verschillen – bedrijven werken doorgaans het best samen met bedrijven van vergelijkbare omvang, flexibiliteit en formaliteit. Bedrijven zijn in meer of mindere mate voorzichtig als het gaat om privacy, beveiliging, vertrouwelijkheid enzovoort. Bedrijven hebben verschillende leiderschapsstijlen en ook aan het verschil tussen overheidsorganisaties en commerciële organisaties moet men soms wennen.
Leveranciers werken volgens contracten	Uw leverancier is niet loyaal aan de belanghebbenden van uw project of aan hun bedrijfsdoelen. Zij werken volgens de regels die in hun contract zijn vastgelegd. Zorg er indien mogelijk voor dat uw contracten alle verantwoordelijkheden van beide partijen benoemen en dat het contract goed gedrag beloont en slecht gedrag bestraft.

Sommige bedrijven breiden bestaande softwaretestteams uit om capaciteiten op te bouwen voor grotere projecten, of huren gespecialiseerde testbedrijven in in plaats van voor het testen te vertrouwen op contractanten of interne gebruikers. In andere situaties kunnen alle ontwikkel- en/of testwerkzaamheden worden overgedragen aan leveranciers. In alle gevallen moet het klantbedrijf zijn leveranciers aansturen. Dit betekent niet dat het schrijven van een beperkend contract met zware boeteclausules voldoende is.

Wanneer er dingen misgaan, wilt u snelle reacties en samenwerking van uw leverancier; u wilt niet dat zij zich achter juridische clausules in contracten verschuilen.

De geheimen van succes zijn:

• Als u uw leverancier niet aanstuurt, zal deze u aansturen (als u geen volwaardige partners bent en de leverancier de voorwaarden laat bepalen, heeft de leverancier alle troeven in handen).
• Het doel is een goede werkrelatie te definiëren. Deze moet op alle niveaus tot stand worden gebracht – bij belanghebbenden, managers en uitvoerende medewerkers.
• Contracten moeten zo worden opgesteld dat alle verantwoordelijkheden van beide partijen worden benoemd, met passende maatregelen, drempelwaarden, termijnbetalingen en acceptatiecriteria die zijn vastgelegd om goed gedrag te stimuleren (aan beide kanten van de overeenkomst).
• Overeenkomsten moeten openheid en draagvlak voor het gezamenlijke doel van projectsucces stimuleren.

Stof tot nadenken

En tot slot enkele vragen om u aan het denken te zetten. 

Welke relatie hebt u als tester met uw ontwikkelaars? Of, als u een ontwikkelaar bent die dit leest, wat is uw relatie met testers? Vraag misschien aan uw partners in ontwikkeling of testen hoe zij uw relatie zouden beschrijven. Vergelijk de antwoorden!

Om productief te zijn, moeten softwaretestteams communiceren en samenwerken.