Testbash Testpeople
”Namens Testpeople was ik uitgenodigd om Testbash 2018 op vrijdag 13 april bij te wonen. Dit leek mij een mooie kans om zo eens kennis te maken met andere mensen binnen het testvak en om mijn kennis uit te breiden. Daar was Testbash dan ook erg geschikt voor; het is een evenement dat jaarlijks door en voor testers wordt georganiseerd. Dit jaar werd het in Utrecht gehouden, op een mooie locatie in het centrum.

De vrijdag begon officieel om 9 uur, maar ik was iets te vroeg aanwezig. Hier hebben de mensen achter Testbash ook aan gedacht; er werd een ‘Lean Coffee’ georganiseerd voor de vroege vogels. Hier kon je onder het genot van een koffie samen met andere testers in een agile-omgeving problemen of successen binnen je carrière bespreken. We werden in groepjes van ongeveer 7 personen gedeeld en vervolgens mocht iedereen een onderwerp aandragen die hij of zij graag wilde bespreken. Per onderwerp kregen we drie minuten de tijd om dit te bespreken. Er kwamen erg boeiende onderwerpen voorbij en het is altijd interessant om te horen waar andere testers tegenaan lopen of op welke manier zij juist succes ervaren hebben in hun loopbaan.

Na de Lean Coffee begaven we ons richting de zaal voor het officiële evenement. Op de vrijdag werden er in totaal 9 lezingen georganiseerd waarbij iedere lezing zich richt op een ander aspect binnen het testen. Ik heb een drietal lezingen uitgekozen om te bespreken: Bij “Go Old School – Why Test Techniques Aren’t Dead” door Sue Atkins en “Kill the Mutants!” door Nico Jansen en Simon de Lang, heb ik gerichte handvatten aangereikt gekregen die ik zou kunnen toepassen binnen het testvak. Een andere lezing, “Lessons From Famous Detectives For Testers” door Geoffrey van der Tas, vond ik erg leuk in elkaar gezet en deze lezing is mij ook goed bijgebleven. Alle lezingen waren interessant, maar in dit blog wil ik wat dieper ingaan op de bovenstaande lezingen.

Go Old School – Why Test Techniques Aren’t Dead

In de lezing “Go Old School – Why Test Techniques Aren’t Dead” door Sue Atkins, haalde Sue twee testtechnieken aan die ook tegenwoordig nog goed van pas kunnen komen bij het testen, aangezien er tegenwoordig veel nadruk wordt gelegd op testautomatisering. Een van deze technieken is ‘State Transition Testing’. Dit is een techniek waarbij de tester het gedrag van een applicatie analyseert, terwijl er verschillende testwaardes in een bepaalde volgorde worden ingevoerd. De tester voert zowel de positieve als negatieve testwaardes in en bekijkt vervolgens hoe het systeem hierop reageert. Deze waardes kan je invoeren in een tabel, waarbij de status van het systeem aan de linkerzijde wordt geplaatst en de gebeurtenissen aan de bovenkant worden geplaatst. Vervolgens kan je in de hokjes aflezen wat de status is van het systeem nadat een bepaalde gebeurtenis heeft plaatsgevonden.

Een andere techniek die Sue besprak is het zogenaamde ‘Pairwise Testing’ aan de hand van ‘orthogonal arrays’. Deze techniek kan worden gebruikt wanneer er veel testwaardes getest moeten worden aan de hand van gecombineerde waardes. Het voordeel van deze techniek is dat het aantal testgevallen behoorlijk omlaag gebracht kan worden en dat deze testgevallen alle combinaties van de verschillende variabelen wel meepakt. De productiviteit wordt verhoogd doordat er minder testgevallen zijn om te testen. Volgens Sue hebben testtechnieken een negatief imago, doordat zij als ouderwets en onhandelbaar worden beschouwd. Maar wanneer deze technieken op de juiste momenten worden toegepast kunnen zij juist een toegevoegde waarde zijn.

Kill the Mutants!

De tweede lezing waar ik kort op in wil gaan is “Kill the Mutants!” door Nico Jansen en Simon de Lang. Deze lezing is weer meer gericht op geautomatiseerd testen en op welke manier geautomatiseerde testen geoptimaliseerd kunnen worden. Hiervoor gebruiken zij de zogenaamde ‘mutatietesten’. Dit is een manier van testen waarbij er bugs of mutanten in de code worden geplaatst. Als de test faalt, dan is de mutant gedood en als de test slaagt, dan heeft de mutant het overleefd. Hoe meer mutanten er zijn gedood, hoe effectiever de testen zijn. Er zijn verschillende frameworks beschikbaar voor de talen Javascript, Java en Python. Voor de testers onder ons die werken met geautomatiseerde testen, kunnen mutatietesten een nuttige toevoeging zijn.

Lessons From Famous Detectives For Testers

De laatste talk die ik hier wil bespreken is “Lessons From Famous Detectives For Testers” door Geoffrey van der Tas. Deze talk is vooral gericht op het verkennende deel van het testen. Details over het waar en wanneer, het onderzoeken van relevante informatie en weten hoe om te gaan met tijdsdruk zijn belangrijke factoren bij het testen. Hetzelfde geldt voor detectives, vandaar dat er in deze talk de link wordt gelegd met Sherlock Holmes. Volgens Geoffrey werkt Sherlock via een bepaald model, dat ook relevant is voor testers: hij ontdekt iets en neemt de tijd om de waarheid te achterhalen. Dit doet hij onder andere aan de hand van feiten. Vervolgens absorbeert hij de informatie op een manier zodat hij alles beter kan onthouden. Dit doet hij door alle informatie in kleine stukjes te hakken. Daarna leidt hij informatie af aan de hand van opgedane kennis en door terug te redeneren. Dit is vergelijkbaar met Gherkin dat testers gebruiken: Given – when – then, waarbij ‘then’ het effect voorstelt en ‘given’ de oorzaak. Door naar het effect te kijken is de oorzaak vaak te achterhalen. Het beschreven model is ook van toepassing op het verkennende testen van een systeem; bij verkennend testen is het ook belangrijk om te beschikken over genoeg achtergrondinformatie en om genoeg kennis op te doen van het systeem, zodat je die kennis kan gebruiken bij het testen van een systeem.

Ik denk dat ik niet alleen voor mijzelf spreek als ik zeg dat Testbash 2018 een groot succes was. Ik zou iedereen in het testvak dan ook aanraden om dit evenement een keertje bij te wonen.”

-Renate van Munster, Software tester bij Testpeople

Renate van Munster Testpeople

”AT, PP, SAP, FRISS, CVS, ADN. Dit zijn zomaar een paar termen waarmee ik gedurende de eerste weken werd geconfronteerd en die mij, als beginnend junior test consultant, eigenlijk niets zeiden. Dit had misschien ook wel te maken met mijn achtergrond; ik heb een master behaald in de Engelse literatuur en vervolgens heb ik een opleiding gedaan tot docent Engels.

Toch zat ik niet op mijn plek als docent Engels en hierdoor was ik in de tussentijd bezig met het volgen van verschillende online cursussen over computerwetenschappen. Mijn interesse in de IT-branche was meteen gewekt, ook al wist ik stiekem wel dat mijn passie hier altijd heeft gelegen; als klein meisje vond ik computers al erg interessant en ik kon het destijds ook niet laten om in DOS allemaal verschillende ‘commands’ uit te proberen. Dit tot de frustratie van mijn vader die tot de ontdekking kwam dat al zijn bestanden ineens gewist waren. Het willen ontdekken en uitproberen zijn twee eigenschappen die later goed van pas zouden komen tijdens mijn eerste weken als junior test consultant.

Op 1 februari mocht ik samen met twee andere junior test consultants, Luuk en Sjors, starten bij Testpeople. De eerste drie weken hebben we samen hard gestudeerd om onder andere het SCRUM-examen te halen. De examens bleken nog erg pittig te zijn, maar we hebben ze uiteindelijk gehaald. Daarnaast had ik samen met Luuk tijdens de tweede week al een intakegesprek bij een verzekeraar. Dit vonden wij natuurlijk erg spannend, maar het ging gelukkig goed en ik mocht eind februari al starten bij deze verzekeraar, slechts vier weken nadat ik bij Testpeople was aangenomen.

De eerste weken verliepen eigenlijk zoals ik aan het begin beschreef. Ik kende de vaktermen nog niet en was bovendien niet echt thuis in de verzekeringswereld. Het was allemaal nogal overweldigend: veel nieuwe mensen, nieuwe termen, een groot kantoorgebouw en dan ik, de junior. Ik werd gelukkig erg goed opgevangen door mijn collega’s, en dan met name door Daniëlle, en ik kon met elke vraag bij hen terecht. Daniëlle praatte mij elke dag weer een beetje bij over het verloop van het project waar me op dit moment volop mee bezig zijn en hierdoor werd het steeds makkelijker om precies te begrijpen hoe het project en de vaktermen nu precies in elkaar steken en zich tot elkaar verhouden. Daarnaast heb ik de eerste twee weken bij mijn opdrachtgever vooral veel uitgeprobeerd en op die manier ontdekt hoe het programma dat wij moesten testen precies in elkaar stak.

Het gaat nu, drie maanden na mijn start bij Testpeople, erg goed met mij. Ik zit helemaal op mijn plek bij Testpeople en ik vind het erg fijn dat ik elke dag weer iets nieuws leer. Zo hield ik mij aan het begin vooral bezig met het aanmaken en beheren van bugs in Quality Center en Bugzilla, maar inmiddels krijg ik steeds meer verantwoordelijkheden en ben ik ook bezig met het testen van conversie en het uitvoeren van regressie- en acceptatietesten. De eerste fase zijn we inmiddels bijna voorbij met het project en ik ben dan ook erg benieuwd naar de volgende fase. Verder zijn de termen die ik aan het begin van deze blog noemde mij inmiddels helemaal duidelijk en ik hoop er de komende tijd nog veel bij te leren.”

Renate van Munster, Software Tester bij Testpeople

Testpeople agile rollen

”De wereld van software testen is al enige tijd flink in beweging. Klanten willen meer en meer geautomatiseerd testen en ontwikkelaars worden vaker verantwoordelijk voor het testen van hun eigen software. De omarming van ‘agile software development’ brengt deze ontwikkeling zelfs in een stroomversnelling.

Door deze beweging verandert ook het gewenste profiel van testers. Grofweg wordt technische kennis een vereiste en worden leidinggevende en organisatorische kwaliteiten minder belangrijk gevonden. Ideaal voor de techneuten onder ons, een uitdaging voor functionele testers en testmanagers, zoals ik.

Mocht dat sceptisch klinken, alsof ik de agilekentering niet toejuich, dan moet ik dat meteen ontkrachten. Mijn huidige functie als ‘traditionele tester’ staat wellicht op de tocht. En het lijkt misschien verstandig om mij technische kennis bij te spijkeren. Maar ik zie andere kansen, en met mij Testpeople.

In een agile-omgeving ligt een belangrijke taak bij de product owner, die de schakel vormt tussen business en development. Hij vertaalt de wensen van de opdrachtgevers naar hapklare brokken werk, in de vorm van stories, waarmee ontwikkelteams aan de slag kunnen. Hij is vraagbaak voor zowel de business als ontwikkelaars en communiceert met shareholders over de voortgang.

Waarom zeg ik dit? De rol van product owner biedt kansen voor Testpeople, en daarmee voor mijn carrière. Bepaalde kwaliteiten van de product owner herken ik namelijk in de traditionele tester. In beide rollen ben je scherp op correcte, volledige requirements, sta je tussen de business en development en ben je communicatief sterk. Daarnaast doet een testmanager organisatorische ervaring op, die steeds van pas komt.

Kijk ik puur naar mezelf, dan zijn er zeker ook eigenschappen van de product owner die ik nog ontbeer. Samen met Testpeople heb ik die in kaart gebracht. En, net als andere geïnteresseerde collega’s, word ik klaargestoomd voor een rol als product owner. Meer in het algemeen sleutelen we bij Testpeople voortdurend aan de organisatie, om de markt te blijven bieden wat ze nodig heeft. Onze wereld is in beweging, dus bewegen wij mee.”

Marc Quirijnen

Johan Codepeople Testpeople

”Software testers worden eigenlijk maar zelden ontwikkelaar. De stap die ik heb gezet, is zeker geen gebruikelijke. Toch trok die andere kant mij aan en ik ben erg blij de ambitie te hebben uitgesproken. Want nu ben ik de eerste medewerker van het nieuwe initiatief Codepeople, onderdeel van mijn huidige werkgever. Spreek dus vooral je ambitie uit, want dat kan tot de grootste verrassingen leiden.

De voorgeschiedenis: ik ben een 30-jarige softwaretester met ervaring bij zowel Testpeople als een ‘grote’ detacheerder. Mooi werk, waarin ik me goed heb kunnen ontwikkelen. In het vak kom je uiteraard voortdurend in contact met de makers van onze testproducten, de programmeurs. Aanvankelijk had dat gewoon mijn beroepsmatige interesse, later kreeg ik steeds meer gevoel voor die creatieve kant van software, het creëren van een nieuw product. Maar ik zag het vooralsnog als twee -haast per definitie- gescheiden werelden.

Na lang wikken en wegen besloot ik dat gevoel te delen met Aldo en Philippe van Testpeople. Welke kant het op zou gaan, wist ik ècht niet. Misschien zouden we afscheid moeten nemen, Testpeople is immers geen ontwikkelaar. Maar de reactie was juist enorm positief: zij zagen het als een kans om de activiteiten uit te breiden, volgens dezelfde filosofie en cultuur. Het nieuwe initiatief hebben we Codepeople genoemd. Een andere naam, omdat programmeurs bij Codepeople niet noodzakelijkerwijs iets met testen hebben.

In mijn geval is dat wel zo, en dan zien wij vanuit Testpeople het als een pluspunt. Wij stellen dat testervaring waardevol is voor het ontwikkelvak: testers zijn gewend vanuit kwaliteit te redeneren, terwijl ontwikkelaars nog weleens te weinig focussen op de edge cases. Dat klinkt natuurlijk generaliserend, wij willen slechts aangeven dat een testachtergrond nuttig is voor een programmeur. Bij Codepeople zullen vooral programmeurs zonder testervaring werken, maar ze groeien wel op in de kritische, onafhankelijke cultuur van Testpeople.

Het zal duidelijk zijn, ik ben ontzettend blij met alle ontwikkelingen. Ik kan me verder verdiepen in het vak dat mij het meeste aanspreekt en dat mag ik ook nog eens doen bij het bedrijf dat mij het meeste aanspreekt. Dat geeft weer nieuwe energie, energie die ik de laatste tijd een beetje kwijt was voor het testvak. De komende maanden gaan we Codepeople verder vormgeven. Een spannend proces, net als het creëren van software.”

Johan Bastiaan

Thomas de Graaf Testpeople

Als we straks allemaal een elektrische auto hebben die we na het werk willen opladen, zou het net daar niet tegen kunnen. Vervanging van het net is evenwel enorm duur. Een slimmere optie is de behoefte te nivelleren. De meeste auto’s hoeven immers pas de volgende ochtend te zijn opgeladen.

De standaard die de organisatie wil neerzetten, staat beschreven in een dik boek met specificaties, dat regelmatig werd bijgewerkt door het designteam. Dit team was geen onderdeel van het scrum team waarin ik zat, maar leverde wel de product owner voor ons team en de user stories. Ons teamhet bouwteam bestond uit een architect, een scrum master, 6 ontwikkelaars en in eerste instantie 1 en later 2 testers. Doel van ons team was het bouwen van een referentieimplementatie.

Mijn ervaring tot dan toe lag vooral in backofficeapplicaties in de financiële sector met 99,9.. % up time. In mijn referentiekader was daarom de eigenschap productiewaardig naadloos verbonden met de definitie van een backofficesysteem. Toen ik in het project kwam was er een test achterstand van een paar sprints. Het testen van het werk van 6 ontwikkelaars in combinatie met de test achterstand leek daarom op het eerste oog een onmogelijke opgave. Hoe zou jij dit hebben aangepakt?

Een referentie-implementatie

Er lag een duidelijke nadruk op de definitie van referentie-implementatie toen mij werd verteld wat we aan het bouwen waren. Dit triggerde mij gelukkig om door te vragen: Wat is een referentie-implementatie in jullie ogen en wat is het doel? Hier kwam gelukkig een zeer helder antwoord op terug:

  • De referentie-implementatie moet de specificaties toetsen;
  • De referentie-implementatie moet gebruikt kunnen worden om simulaties te kunnen draaien t.b.v. onderzoek;
  • De referentie-implementatie moet gebruikt kunnen worden als uitgangspunt voor partijen die de standaard willen implementeren in JAVA.

Na verder te hebben doorgevraagd over deze doelen kon ik bepalen wat de consequenties waren voor de testaanpak.

Toetsen van de specificaties

De specificaties bestaan hoofdzakelijk uit procesbeschrijvingen en interfacespecificaties. Met een review kun je fouten uit specificaties halen, maar als specificaties als standaard je belangrijkste deliverable is, wil je dat elk detail klopt. Pas als je er mee aan de slag gaat, kijk je goed naar details. Een soortgelijke situatie herken ik vaak bij grooming/refinementsessies; je denkt alles helder te hebben, maar loopt tijdens de voorbereiding toch tegen vragen aan.

Hoe heb ik dit vertaald naar een testaanpak?

De waarde van de specificaties is dusdanig groot, dat je als tester niet alleen de individuele stukken functionaliteit moet begrijpen, maar ook waar deze stukken in het proces passen. En dat je dit als proces moet toetsen. Het variëren in mogelijke flows door het proces is daarnaast belangrijker dan het testen van foutsituaties binnen stukken functionaliteit.

Om te beginnen heb ik functionele testen opgezet om vervolgens snel een procesgerichte test op te zetten. Omdat het proces over meerdere rollen loopt, heb ik dit als integratietest aangeduid en om de test elke sprint te kunnen uitvoeren, heb ik dit net als de functionele testen geautomatiseerd in SoapUI. (In een volgende blog zou ik hierop in kunnen gaan, als daar behoefte aan is.)

Simulaties draaien t.b.v. onderzoek

Het nivelleren van de energiebehoefte gaat niet vanzelf, daarvoor wil de standaard marktwerking gebruiken. Omdat het lastig is te voorspellen hoe een nog niet bestaande markt zal functioneren, en waarbij verschillende partijen verschillende belangen hebben, is het belangrijk simulaties te kunnen draaien. Tijdens de simulatie moet aan knoppen kunnen worden gedraaid, om te zien wat het effect is. Dit moet bij voorkeur versneld kunnen worden uitgevoerd, zodat niet meerdere dagen hoeft te worden gewacht op concrete resultaten.

Hoe heb ik dit vertaald naar een testaanpak?

Tijdens een simulatie wil je ervan uit kunnen gaan dat de applicatie een happy flow goed verwerkt. Syntactische fouten zijn niet relevant, omdat men zich daar aan de beschreven standaard dient te houden. Wél relevant is de performance. Als initieel uitgangspunt is een performance requirement neergelegd. Toen snel bleek dat deze eis niet reëel was, hebben we gekeken waar de limieten van de applicatie lag. Performance in deze context is niet iets waar je tegenaan wilt lopen gedurende een simulatie, maar het kon zowel door performance-verbetering worden voorkomen als door het managen van verwachtingen van de mensen die hiermee simulaties willen maken.

Uitgangspunt bij implementatie

Deliverable van het bouwteam is feitelijk de sourcecode met scripts om een omgeving op te kunnen zetten. Daarnaast zijn simpele stubs gemaakt op de punten waar een klant een link moet leggen met zijn eigen back end-systeem en interactie vereist is.

Dit zou geschikt moeten zijn voor een partij om een volwaardige implementatie te maken. Belangrijk hierin is dat de applicatie functioneel helemaal in lijn is met de specificaties. Eisen aan de productiewaardigheid dienen door de betreffende partij zelf aangebracht te worden, evenals de koppeling met back endsystemen van die partij.

Hoe heb ik dit vertaald naar een testaanpak?

Dit doel was het lastigste te begrijpen en vertalen naar een concrete aanpak. Waar ik gewend was een complete oplossing te testen, moest ik nu een deeloplossing testen die enkel als voorbeeld diende.

Om te beginnen, is duidelijk dat het functioneel testen van de happy flow belangrijk is, net als het testen van het proces. Het testen van aanpasbaarheid van de applicatie is een ander verhaal. Vanuit een ontwikkelperspectief was dit al wel snel duidelijk: Als code je deliverable is, en niet een gecompileerd object, moet de code goed leesbaar zijn. Coding-standaarden en code reviews moesten ervoor zorgen dat de code goed leesbaar was (alsof ze door 1 persoon was geschreven).

Vanuit een testperspectief werd dit pas duidelijk toen we daadwerkelijk met de testen waren begonnen. De stubs die standaard waren gebouwd, waren vaak niet afdoende om alle relevante paden in het proces te dekken of om een goede uitgangssituatie te creëren voor functionele testen van stukken functionaliteit aan de achterkant van het proces. Een optie in zo’n geval is om de testdata aan te passen, maar een alternatief was de meegeleverde stubs aan te passen.

Omdat we als testers met enige programmeerervaring blanco naar een stub konden kijken en beoordelen of we deze konden aanpassen, waren we in feite precies hetzelfde aan het doen als een externe partij zou doen. Daarbij werd geaccepteerd dat als wij, als testers, de applicatie konden aanpassen, andere ontwikkelaars dat ook moeten kunnen. Bijkomend voordeel was dat we functionele testen verderop in de keten deden op basis van door de hele keten gegenereerde data, niet door de database handmatig aan te passen.

Het testen of je van de applicatie een productiewaardig systeem kan maken, hebben we bijvoorbeeld gedaan door te testen of de applicatie database-onafhankelijk is. We hebben H2 database als uitgangspunt genomen, een database waarvan niet wordt aangeraden om deze in een productie-omgeving te draaien. We hebben aangetoond dat de applicatie ook met Maria DB valt te configureren.

Tot slot

Belangrijke les voor mij was om als tester niet enkel het correct functioneren van het systeem als vanzelfsprekend te zien, maar ook eisen rondom een systeem als productiewaardigheid. Ik ben benieuwd naar jullie ervaringen!”

Thomas de Graaf Testpeople

”Als je meer wilt weten over een politieke partij, vind je al snel een pakkende visie, samengevat in een pakkende slogan. Maar in verkiezingstijd is diezelfde partij vooral druk bezig met het vertellen waarom je niet op andere partijen moet stemmen. Iets soortgelijks merkte ik toen ik me ging verdiepen in context driven testing.

Als je daarop googelt, vind je al snel 7 pakkende principes. Daarvan werd ik dan ook erg enthousiast, toen ik anderhalf jaar geleden met het begrip in aanraking kwam. Mijn visie op testen bleek een mooie naam te hebben. Eindelijk werd erkend dat ons werk een goed stel hersens vereist, naast een kast vol dikke boeken.

Als zelfbenoemde context driven tester was ik hongerig naar kennis en dompelde me onder in de community. Daar zag ik veel passie, maar nog meer onvermogen om iets concreets mee te geven om over na te denken. In plaats daarvan werd alles bekritiseerd dat de context driven-gedachte zou kunnen ‘bedreigen’. Ik waande mij even in een politieke discussie: interessant maar verre van leerzaam. Met de 7 principes in het achterhoofd ben ik maar verder gegaan met het werk.

Inmiddels heb ik context driven testing concreet kunnen maken. Het feit dat ‘context’ een zo veel omvattende definitie kent, moet ons niet afschrikken. Als junior tester leer je dat testbasis je belangrijkste ‘context’ is. Later leer je dat eisen aan je applicatie, met zowel beschreven als vanzelfsprekende eisen, onderdeel van de context zijn.

Als je erover na gaat denken, is zelfs de temperatuur van de ruimte waarin gebouwd en getest wordt, onderdeel van de context. Context is geen checklist, context is alles. Het is aan de tester om de context te observeren en daaruit relevante zaken te halen, die hij vervolgens vertaalt naar een aanpak.

Wat valt er dan te leren, als de context altijd anders is? Ik geloof dat de community van elkaar kan leren door praktijkvoorbeelden te delen: de geobserveerde context, het selecteren van relevante context, de vertaling naar de testaanpak en evaluatie. Niet om te kopiëren, maar om elkaar te helpen herinneren wat allemaal niet vanzelfsprekend is en impact kan hebben op de aanpak.

In mijn komende blogs hoop ik context driven testing zo te presenteren, dat een nieuweling in de community ons eerder zal vergelijken met een Tesla of Apple, dan met een politieke partij.”

Thomas de Graaf

Philippe Metz Testpeople
”Er is maar één manier om kinderen te leren fietsen: loslaten. Dat vinden we best eng, maar we doen het toch. Want we beseffen: Om te leren, moet je de schijnzekerheid van het vertrouwde loslaten. Als dat lukt met onze eigen kwetsbare kinderen, waarom dan niet met een organisatie van volwassen professionals? Met die vraag worstel ik al geruime tijd. Maar, hoe kan het ook anders, het antwoord komt van Testpeople zelf.

De inmiddels wereldberoemde Braziliaan Ricardo Semler voerde ooit ‘democratische bedrijfsvoering’ in bij zijn bedrijf Semco. De drieduizend werknemers bepalen daar alles zelf: hun salaris, hun werktijden, hun leidinggevende. Managers kennen er geen enkel privilege, de macht is aan de meerderheid. Hoe je werkt, maakt niet uit: Het resultaat telt. Semler stelt: Als je creatieve werknemers wilt, verstik ze dan niet met een keurslijf van onzinnige regels.

Meer vertrouwen in medewerkers is kennelijk erg lastig. Management is vaak gebaseerd op wantrouwen en controle. Denk alleen al aan zoiets als een aanwezigheidsplicht, waardoor we ’s ochtends massaal aanschuiven in de file. Of aan een beperkte tekenbevoegdheid. De helaas onlangs overleden Arend van Randen, met zijn Learn-methode een volgeling van Semler, zei daarover: “Als mensen zich gedragen als dieren in een kooi, ligt dat niet aan de mensen, maar aan de kooi.”

Al bij de start van Testpeople zag ik voor me dat medewerkers op enig moment uit hun functie zouden groeien. Dat ze méér zouden willen doen, of iets heel anders. Ik zie het bedrijf liever als een platform voor ideeën, een incubator, dan enkel als een softwaretester. Begrijp me niet verkeerd, ik ben trots op het succes dat we met Testpeople hebben behaald. Maar om succesvol te blijven, en (veel belangrijker) om het beetje leuk te houden, moet je jezelf uitdagen. Testpeople streeft niet naar winstmaximalisatie, maar naar pleziermaximalisatie.

Daarom ben ik ontzettend blij dat de laatste tijd nieuwe ideeën worden gepitcht door medewerkers. Waar ik al langere tijd op hoopte (misschien stond de kooi niet wijd genoeg open), komt nu los. De een wil met big data aan de slag, de ander denkt aan software-ontwikkeling en een derde wil zich toeleggen op de product owner-rol in Agile-omgevingen. Ik juich het van harte toe, voel me geïnspireerd door collega’s en ben buiten mijn comfort zone gestapt om zoveel mogelijk ideeën in praktijk te brengen. Opeens ben ik een dienende business developer geworden. Best democratisch, toch?”

Philippe Metz