De Definition of Testable

De meeste met ervaring in Agile en/of Scrum zullen de termen Definition of Done en Definiton of Ready wel kennen. De eerste geeft aan, wanneer een story gereed is voor productie. De tweede geeft aan, wanneer een story in de sprint kan worden opgenomen. Maar er is zeker nog een andere belangrijke stap: wanneer kan een story van bouw naar test.

Het zou mij niet verbazen als dit een van de oudste vraagstukken is binnen testen: waar stopt het testen van een developer en waar begint de tester? Als de developer te lang doorgaat, wat is dan nog de waarde van een tester? En als de developer te kort test, wordt de tester dan niet misbruikt om als developer slecht werk te kunnen leveren?

Om dit duidelijk te krijgen, is het verstandig om eerst goed te kijken wat het verschil is tussen het testen van een developer en van een tester. Een developer heeft bij het testen als voornaamste doel zijn/haar eigen werk te controleren. Dit houdt in dat de gebouwde story moet voldoen aan de acceptatiecriteria en de binnen het bedrijf of product geldende standaarden. Een tester heeft vaak twee aparte doelen: de second opinion en de testuitbreiding. Bij de second opinion test de tester vaak hetzelfde als de ontwikkelaar, om te controleren of de ontwikkelaar inderdaad het juiste gebouwd heeft. Dit is heel simpel met de reden: iedereen maakt fouten. De uitbreiding van het testen is een ander verhaal. Dit kan per bedrijf verschillen, maar het gaat hier om testen waarvoor binnen het bedrijf geen standaarden zijn. Naast een regressietest, vat hier in ieder geval ook een integratie test in. Een test, waarbij de wijziging niet alleen los wordt getest, maar ook binnen een geheel proces. Of zelfs binnen een keten van applicaties. Maar ook zaken als gebruikersvriendelijkheid, performance, security, enz. kunnen hier invallen. Zaken, die belangrijk zijn, maar niet in concrete, algemeen geldende, criteria zijn vastgelegd.

Als dit het verschil is, waar moet een developer dan op testen? Twee punten blijken al uit het vorige:

• Voldoet een story aan de acceptatiecriteria?
• Voldoet een story aan de geldende standaarden?

Maar developer en tester vormen een team. Wat ik hiermee bedoel? Als je uit gaat van een samenwerking, wil je niet dat een developer iets oplevert, wat door de tester niet of nauwelijks getest kan worden. Iets wat bij de tester op het bordje komt en vervolgens binnen de kortste keren weer teruggestuurd wordt. Omdat de tester al vastloopt, voordat de test ook maar enigszins gevorderd is. Daarom vind ik ook deze twee vragen bij de developer test horen?

• Werkt de wijziging in de applicatie?
• Kan de tester de wijziging testen?

De eerste vraag klinkt misschien alsnog als een ketentest. Laat me daarom het verschil uitleggen. Stel je hebt twee applicaties. In de ene doe je de invoer, in de andere worden rapporten gemaakt. Nu is er een rapport voor een adressenlijst toegevoegd. De invoer is al aanwezig. Maar om het de ontwikkelaar makkelijk te maken, zijn de gegevens voor de adressenlijst gesimuleerd. Dan is het niet de bedoeling dat de ontwikkelaar alsnog alle varianten gaat lopen invoeren, om de adressenlijst te testen. Dat is een integratie test. Wat wel de bedoeling is, is dat de developer zelf adressen invoert via de ene applicatie (twee is al voldoende) en kijkt of deze inderdaad in de adressenlijst komen in de andere. Een korte test, om na te gaan of er geen misverstanden zijn ontstaan tussen de verschillende developers of teams.

De tweede vraag is eigenlijk meer een overdrachtsvraag. Als een developer gebruik heeft gemaakt van technische truukjes om te testen, is de kans groot dat de tester problemen gaat tegenkomen. Nu kan je dat probleem natuurlijk direct naar de tester schuiven. Maar ten eerste is dat vaak maar van korte duur. De tester komt meestal bij je terug met de vragen. Daarnaast heb jij al technische truukjes. En deze kunnen regelmatig de basis vormen om de tester bij testen te helpen. Een teamgenoot vragen een probleem op te lossen, wat jij al hebt opgelost, waarom zou je?

Nee, bovenstaande is niet in beton gegoten. Want wat veel belangrijker is dan een Definition of Testable is een goede samenwerking. Veel beter dan een DoT op basis van een of ander geschreven blog, is een DoT, die is ontstaan, doordat ontwikkelaars en testers met elkaar praten. Elkaars problemen begrijpen.. Proberen het elkaar zo makkelijk mogelijk te maken. Maar tegelijkertijd in de gaten houden, dat het niet de bedoeling is 8 uur extra development tijd te besteden om 1 uur testen te besparen. Net zo min als je 1 uur development tijd wil uitsparen, door de tester 8 uur langer te laten testen. Gebruik de bovenstaande vragen gerust als startpunt. Maar boven alles: praat met elkaar!

Hoe haal je het meeste uit een Senior tester

Ik weet niet of het omgaan met senior testers veel moeilijker dan met andere senior IT'ers. Wat ik wel weet, is dat ik het vaak mis zie gaan. Senior testers, die onderpresteren. Senior testers, waarbij juist over hun testen geklaagd wordt. Hoe komt dit? En daarmee: hoe voorkom je dit?

Eerst even een belangrijk punt voor deze blog. Wat is een senior tester? Voor wat ik hier schrijf, gaat het niet om de prestaties, die iemand levert. Of de geleverde prestaties van een senior niveau zijn. Waar het hier om gaat is kennis en ervaring vergeleken met andere aanwezige testers. Als testers gemiddeld 5 jaren testervaring hebben, maakt 3 jaar ervaring iemand geen senior. Maar in een bedrijf met voornamelijk beginnende testers, kan dezelfde 3 jaar je een senior maken. En het kan ook gaan om een bepaalde specialiteit. Als alle testers 5 jaar ervaring hebben, maar nog nooit aan testautomatisering hebben gedaan, kan een nieuw persoon met 2 jaar ervaring in testautomatisering toch al een senior tester zijn. En een speciaal, maar belangrijk geval is de "bedrijfservaring". Als je ergens nieuw binnen komt, ongeacht je aantal jaren ervaring, is elke tester, die daar werkt automatisch voor jou een senior. Waarom? Zij hebben meer kennis en ervaring van het bedrijf, de mensen, die er werken, de procedures, die gevolgd worden. En deze kennis heb je nodig om zelf succesvol te zijn. Om ervoor te zorgen, dat wat je wil, ook werkelijk bij de organisatie past. Dus ja, in een groep met testers, kan er voor bijna iedereen wel een reden zijn om senior tester te zijn.

Waar komt het onderpresteren vandaan? In mijn ervaring komt dit voornamelijk door twee problemen: blind vertrouwen en de blinde weg. Bij blind vertrouwen gaat het erom dat de andere testers of meerderen openlijk erkennen, dat ze van testen of een bepaald testonderwerp geen verstand hebben. Ze geven daarom de senior tester de vrije hand om met zijn/haar kennis of ervaring de juiste weg te bepalen. Elke beslissing is juist, want hij/zij is de senior. Er zijn echter weinig mensen, die groeien, als ze op geen enkele manier gevraagd worden om te veranderen. Niet uitgedaagd worden, omdat ze zelf hun doelen bepalen. Niet leren van hun fouten, omdat alles wat ze doen automatisch goed is of niet beter kan.

De andere kant is de blinde weg. Soms is hier sprake van wantrouwen in de kennis en kunde van anderen, maar het is meestal meer een vorm van "we moeten nu eenmaal een bepaalde kant op". Binnen het bedrijf is iemand, die de lijn uitzet. Deze persoon komt, ook of juist op het gebied van testen, zeer overtuigend over. Dit is wat er moet gebeuren. Er ligt veel nadruk op de uit te voeren verbeteringen: we moeten testautomatisering toevoegen, we moeten bugs volgens een template vast gaan leggen, enz. Waarom haalt een zo uitdagende omgeving niet het beste van senior testers naar boven? Soms bewust, soms onbewust wordt het idee gecreëerd dat de input van anderen niet belangrijk is. Het plan is al uitgestippeld, de weg is al bepaald, de oplossing al bedacht. Dus de "ik kan ook wat inbrengen" fase is al voorbij, voordat je ook maar over het plan gehoord hebt. Als je niet bent uitgenodigd voor de voorbereidende fase, zal je input dan waarschijnlijk ook niet welkom zijn. Niet dat dit altijd zo is, maar een zeer overtuigende presentatie van "de weg" creëert vaak wel dat gevoel.

Hoe moet het wel? Je moet een senior tester een weg tonen, zonder de input weg te nemen. Door een doel te stellen, geef je een tester geen volledige zelfstandigheid. Door om input te vragen, voorkom je dat een tester zijn of haar kennis voor zich houdt. Dit doe je door minder de nadruk te leggen op de oplossing en meer op het doel. En het doel heeft bijna altijd een van deze drie begrippen in zich: kwaliteit, tijd of geld. Iets moet sneller, beter of goedkoper worden. Hoewel ik graag zou willen, dat elke senior tester vrij is om helemaal zelf de oplossing te bepalen, weet ik dat dat niet altijd gaat. Dus ja: je kan een senior tester de opdracht geven meer automatische testen te maken, mits je vooral uitlegt waarom. Is het om de kwaliteit te verbeteren? Is het om sneller te kunnen testen? Is het om de hoge kosten van een helpdesk terug te brengen?

Van een senior tester mag, nee moet, je daarna verwachten dat deze of met oplossingen komt of de gegeven oplossing verder invult. Mocht voor dat probleem of die oplossing de kennis of ervaring niet aanwezig zijn, dan is het in eerste instantie aan de tester om dit aan te geven. En het allerbelangrijkste: het is aan de tester om te bewaken of het doel behaald wordt. Verbetert de oplossing inderdaad de kwaliteit, vermindert het de kosten en/of de tijd? Maar: het is aan "wegbepaler" om hiernaar te vragen. De "wegbepaler" blijft verantwoordelijk voor het succes van de weg. De senior tester is "slechts" verantwoordelijk voor het bewaken van het doel. Als de oplossing volledig door de tester bepaald is, is het bijsturen van de oplossing volledig de verantwoordelijkheid van de tester. Anders is de tester slechts verantwoordelijk voor het bijsturen van zijn of haar input in de oplossing.

Waarom zo'n ingewikkelde constructie van verantwoordelijkheid? Ik ben realistisch. Bedrijven moeten doelen stellen. Tegelijkertijd moeten senior testers vertrouwen krijgen. Wat je in deze constructie doet, is de tester medeverantwoordelijk maken voor de doelen. Dat maakt, dat een tester uitgedaagd kan worden nieuwe, onbekende paden te betreden. En daarnaast aangesproken kan worden als doelen niet gehaald worden, zonder dat deze dit gemeld is. Tegelijkertijd geef je met deze afkadering de tester vertrouwen om zijn of haar kennis en ervaring toe te passen.

Maar je kan een tester vaak geen volledige vrijheid geven. Door de "wegbepaler" verantwoordelijkheid te laten houden over zijn of haar eigen beslissingen, blijft er controle. Daarnaast kan een goede "wegbepaler" hierdoor informatie te horen krijgen, die tot de keuze kan leiden de weg aan te passen. Zeker informatie van een senior tester kan je helpen in te zien, dat een bepaalde oplossing toch niet de juiste is.

Senior testers daag je dus uit door doelen te stellen en ze medeverantwoordelijk te maken voor deze doelen. Ze mogen hun eigen input geven om de doelen te bepalen. En zijn altijd verantwoordelijk voor het bewaken van de effectiviteit van de bepaalde oplossing. Maar door ervoor te zorgen, dat ze altijd verantwoordelijkheid moeten blijven afleggen, blijf je controle houden, zowel op je senior testers, als op de weg. Met als doel zowel de testers, als de geplande weg bij te kunnen sturen. Zodat een senior tester een senior tester kan zijn. En de wegbepaler de wegbepaler.

Testen wat niet te testen is

Stel: je hebt in je bedrijf een onderdeel van een applicatie, wat niet getest kan worden. Om wat voor reden dan ook. Zou je er dan tegen zijn als iemand zou zeggen: "Ik ga dit testen"? Nee, niemand zou tegen zijn. Toch is mijn ervaring dat een traject om het niet testbare testbaar te krijgen bijna altijd verloopt van obstakel naar obstakel. Hoe komt dat?

Standaarden

In de IT en in het testvak zijn er veel standaarden, die gebruikt worden om product en proces te verbeteren. Agile, Scrum, Devops, TMap, ISTQB en vul zelf maar verder aan. De ene standaard besteed meer aandacht aan testen dan de anderen. Maar geen enkele besteed aandacht aan het uitbreiden van testdekking. En dat is geen commentaar op de standaarden. Een standaard kan niet alle problemen opvatten en oplossen. Maar het heeft wel een groot nadeel. Het maakt het zo ongeveer officieel dat het testbaar maken van het ontestbare geen onderdeel is van een verbetertraject. En dat maakt het moeilijker een ingang te vinden om dit toch te bereiken.

Normalisering

In veel gevallen is het feit dat iets niet getest wordt al jaren aan de gang. En het is daarmee binnen een bedrijf normaal geworden. Het is een onderdeel geworden van het bedrijfsproces en daarmee van het bedrijf. Een al jarenlang geaccepteerd risico. De nadelen is men al aan gewent en zijn daarmee al van hoog tot laag in het bedrijf geaccepteerd. Daarmee vervalt vaak het belang om het probleem op te lossen. Er is niemand die er nog over klaagt. Zelfs managers niet. Niet testen is in dit geval de norm geworden, de meetlat waarlangs wordt gemeten. Waarmee de reden om te veranderen eigenlijk afwezig is.

Ervaring

Een onderdeel is niet zomaar "ontestbaar" verklaart. Vaak zijn er pogingen gedaan, die mislukt zijn. Mensen hebben er ooit veel tijd in gestoken. Of hebben eens in de zoveel tijd een poging gedaan. Zeggen dat het toch kan veranderen, kan daarmee tegenwerking oproepen. In het beste geval heeft een persoon het gevoel, dat zijn of haar kennis of ervaring in twijfel wordt getrokken. In het slechtste geval wordt het gezien als een directe aanval op iemands  jarenlange werk.

Onbekendheid

Als iets niet getest wordt, maar het is wel mogelijk, is de oplossing vaak onbekend gebied. Het kan een samenwerking zijn tussen personen, die nog nooit hebben samengewerkt. Een tool op een hele andere manier inzetten of zelf een heel nieuw tool invoeren. Of een andere manier van omgaan met testdata. En er zijn nog veel meer mogelijkheden. Maar in mijn ervaring is er altijd een "dat kennen we niet" element. Dit heeft twee nadelen: 

1. Niet iedereen is altijd bereid om iets nieuws te leren
2. Iets nieuws leren of toepassen kost tijd, die je oplossing in eerste instantie vaak duurder maken qua tijd en geld

Gevolg

Officieel zal je bijna nooit te horen krijgen dat je geen poging mag doen om dat wat niet te testen is, toch te testen. Maar er zijn twee zaken, die je in mijn ogen goed moet beseffen

1. Het initiatief op dit traject zal bijna altijd van jou afkomen. Zelfs als mensen niet tegenwerken, zullen ze je vaak niet kunnen geloven (als het kon, was het toch al eerder gelukt?). Of hebben ze gewoon andere prioriteiten (zaken die wel met zekerheid haalbaar zijn).
2. Pas ontzettend op dat je mensen niet tegen je in het harnas jaagt. Je zal je omgeving zeker niet altijd blij maken, omdat je tegen de norm in gaat. Maar probeer te voorkomen dat mensen werkelijk het gevoel hebben dat je hun kennis en ervaring in twijfel trekt.

Waarom toch doen?

Ik heb een hele eenvoudige mening: alles kan getest worden. De vraag is niet: kan je het testen, maar: wegen de testkosten op tegen de baten. Als men werkelijk geloofd dat iets niet getest kan worden, heeft men iets over het hoofd gezien.

Daarnaast, en waarschijnlijk belangrijker voor het overtuigen: hoewel vaak geaccepteerd, zijn de gevolgen vaak wel degelijk ernstig. Ontevreden klanten, terugdraaien van opleveringen in productie, teams die steeds opnieuw onderbroken worden door blocking bugs, slechte relatie tussen development en een of meer afdelingen. Regelmatig ontstaat er zelfs een neerwaartse spiraal: het oplossen van een bug in het niet testbare ondereel veroorzaakt al vrij snel 1 of meer nieuwe.

Als een probleem een van deze gevolgen heeft (en vaak is dat wel degelijk bekend), is het vaak de investering waard om op te lossen. Het is geen makkelijk traject, geen snel traject. En je moet maar net de juiste persoon zijn of vinden om dit onderdeel testbaar te maken. Maar als het lukt, zijn de voordelen ook vrij snel zichtbaar. Juist omdat de negatieve gevolgen dat ook waren. Als men al jarenlang iets slechts gewent is, valt het echt wel op als dat opeens verdwijnt. En dat kan een volgend traject "Testen wat niet te testen is" een stuk eenvoudiger maken.

Simuleren tijdens testen: het kan teweinig en het kan teveel zijn

Simulaties, emulaties, stubs en drivers. Binnen de testwereld krijgen ze een steeds grotere rol. Ze vormen een groep krachtige tools binnen het testen, met een zeer waardevolle toevoeging. En tegelijkertijd vormen ze een heel, heel groot gevaar.

Voor deze blog gebruik ik het woord 'simuleren' of 'simulatie' voor alles waarbij je een applicatie, proces, apparaat, interface, e.d., zoals gebruikt in productie, vervangt door een hulpmiddel. Dit kan een stuk code zijn, maar ook een softwareprogramma, dat als simulatie is ingericht.

Ik hecht een groot belang aan goede simulaties. Simulaties kunnen op verschillende manieren het testen verbeteren. Je kan het mogelijk maken om het onmogelijke te testen. Meestal situaties, die in de praktijk vrijwel onhaalbaar zijn. Zo kan je in het netwerk zaken simuleren, die in het echt moeilijk te vinden zijn. Trage netwerken, haperende netwerken, onderdelen, die uitvallen. Maar denk ook bijvoorbeeld aan GPS testen. Om goed te testen, is een gps coördinaat met een '-' waardevol. Ik denk niet dat veel werkgevers een reis naar het westen of zuiden, om dit te testen, zullen goedkeuren.

Daarnaast is het een krachtig tool om afhankelijkheid van externe leveranciers of beperkte databases op te lossen. Als je zelf kan bepalen welke gegevens je binnenkrijgt, kan je eenvoudig veel meer varianten testen. En testen op meerdere varianten in gegevens geeft vaak een betrouwbaardere test.

Als laatste kan het tijdwinst opleveren. Ik heb zelf testen geschreven, waarbij je langer met de voorbereiding bezig was, dan met de test. Vaak zijn dit tijdgebonden testen, waarbij de gegevens binnen een bepaalde periode moeten vallen. Denk aan een route, die door een monteur gereden moet worden. Hiervoor moeten misschien wel 20 afspraken ingevoerd zijn, om dit goed te kunnen testen. Als je deze invoer snel kan simuleren, in plaats van werkelijk invoeren, heeft dat grote voordelen.

Dus waarom zou je het laten? Nou, volledig laten hoeft wat mij betreft nooit. Dit kan er zelfs toe leiden, vooral als het gaat om testen van situaties of varianten, dat je test niet genoeg dekking heeft om betrouwbaar te zijn.  Het kan echter ook teveel zijn. Als je volledig gaat vertrouwen op simulaties, test je de werkelijkheid niet meer. Want hoe goed een simulatie ook is, er is altijd een kans dat de simulatie verschilt van de werkelijkheid.

Simulaties moet je gebruiken om je test aan te vullen of om een deel van je test te vervangen. Maar als je iets in de werkelijkheid kan testen, doe dat altijd minimaal 1 keer. Ik zie geen enkel bezwaar om, als je 10 testen hebt voor een interface, er 9 te simuleren en 1 echt uit te voeren. Ook kan je ervoor kiezen om een speciale "niet-simulatie" test uit te voeren. Denk hierbij bijvoorbeeld aan een ketentest, waarbij over het algemeen simulatie bewust niet wordt gebruikt.

Aan de andere kant: als je situaties alleen via simulatie kan testen, ontwijk de simulatie niet. Kan je iets niet in de werkelijkheid testen, heb de moed om te kijken of het via simulatie wel kan. Er kan vaak veel meer dan je denkt. Zeker als je zelf kan programmeren of de mogelijkheid hebt een ontwikkellaar in te zetten. Zoek eens op het internet, als je denkt dat iets onmogelijk is. Regelmatig zal je verrast worden, omdat er vaak andere mensen zijn met hetzelfde probleem. En de oplossing daarom allang aangeboden wordt.

Waarom consistentie vaak zo moeilijk is

Consistentie. Officieel zal iedereen het natuurlijk belangrijk vinden. Binnen een product moet functionaliteit altijd gelijk werken, ongeacht waar het aangeboden wordt. Binnen een team moeten mensen op een soortgelijke manier werken. Waarom is consistentie dan zo moeilijk? Consistentie vraagt om "verder kijken dan je neus lang is". Consistentie vraagt om kijken naar de hele applicatie, als je bezig bent met 1 functie. Kijken naar het hele team, als je bezig bent met testen. Kijken naar het gehele proces, als je bezig bent met jouw applicatie. Kijken naar de hele organisatie, als je werk doet voor jouw team.

Waarom? Laten we beginnen binnen het team. Stel je hebt al een bestelproces gebouwd. In dit bestelproces was het mogelijk een adres in te voeren. Dit adres is opgeslagen in het klantaccount. Nu wil je de klanten de mogelijkheid bieden om hun adres te wijzigen. Qua consistentie houdt dit het volgende in: in beide schermen moeten dezelfde gegevens staan. Als je bij het bestelproces kon invoeren, dat je op kamer 784 3e etage woont, moet je dit op het te bouwen scherm ook kunnen wijzigen. Als je in het bestelproces een bezorgadres kon invoeren, moet je deze op het te bouwen scherm ook kunnen wijzigen.

Consistentie binnen een ontwikkelproces zal niemand onbelangrijk vinden. Om binnen testen te blijven: als een tester de regressietest belangrijk vindt, moet een ontwikkelaar het fixen van regressietestbugs ook belangrijk vinden. Er moeten afspraken zijn over de invoer ervan bugs, zodat een ontwikkelaar de informatie heeft, die nodig is om het probleem op te lossen. Enz., enz.

Samenwerken als een team en werken aan een product in plaats van een functie is voor te veel teams al moeilijk genoeg. En dan is het voor veel bedrijven niet eens voldoende als je consistentie op orde hebt in een team. De consistentie moet op orde zijn tussen teams onderling. Tenminste: als deze teams werken aan producten, die met elkaar verbonden zijn.

De argumenten zijn niet anders. Stel je hebt binnen je website het invoeren en wijzigen van een adres precies gelijk. In beide kan je aangeven dat je op kamer 784 3e etage woont. Maar vervolgens belt een klant naar de helpdesk om het adres te laten wijzigen. Een ander systeem, dus een ander team. De helpdesk vraagt het adres op om het te controleren. Dan zegt de klant "Dat adres is niet compleet. Ik woon op kamer 784 3e etage". Bij het bouwen van het helpdesk systeem was niet gekeken welke adresgegevens er bij het bestellen werden ingevoerd.

En vergeet consistentie in het proces niet. Neem nogmaals een bestelproces in de webshop. De artikelen worden beheerd in de backend. Dus in team A. Dit team heeft "Artikelen" als hoogste prioriteit en bouwt het, zodat team B deze straks kan tonen op de webshop. Team A is klaar en levert het werk op. Vervolgens krijgen ze een andere eerste prioriteit, tenslotte is het werk af. Team B gaat vervolgens de artikelen in de webshop tonen. En hierbij ontdekken ze een bug in het onderdeel "Artikelen". Maar bij het melden aan team A is het antwoord: "Artikelen heeft voor ons nu geen prioriteit. Dus je zal moeten wachten".

Consistentie heeft als grote probleem, dat niemand het belang ervan ontkent. Maar als je aan "Klantgegevens wijzigen" werkt, sta je er vaak niet bij stil dat "Product bestellen" hier een belangrijk raakvlak mee heeft. Het zijn tenslotte twee hele verschillende processen, die los van elkaar staan. En als je geconcentreerd aan het testen bent, kan je wel eens vergeten dat ontwikkelaars de informatie in gevonden bugs later ook moeten gebruiken. Het lijkt op dat moment niet belangrijk. Testen is nu tenslotte prioriteit 1. En datzelfde geldt breder. Als deel van het "helpdesk" team lijkt het "webshop" team nu niet echt belangrijk, niet hun product en niet hun proces. En dat maakt consistentie nu zo ontzettend moeilijk. Je moet stil staan bij belangrijke zaken, die voor jou op dat moment eigenlijk niet belangrijk zijn. Veel succes!

Alleen in een team

Als tester ben je met enige regelmaat de enige tester in een team. Dit geeft soms communicatieproblemen, vooral als het gaat om problemen, waar je als tester tegenaan loopt. Je bent de enige met het probleem. Daarnaast begrijpen anderen in het team niet altijd hoe belangrijk of groot een probleem is, als ze het probleem al begrijpen.

Scrum of Agile werkt op dat gebied ook niet altijd mee. Het team staat centraal, dus problemen van een individu kunnen daardoor minder belangrijk worden. Zowel de retrospective als een backlog refinement zijn voornamelijk bedoeld voor communicatie, die voor het hele team van belang is. Niet alleen voor jou als tester.

Deze situatie mag en moet niet inhouden, dat er voor jouw problemen geen plaats is. Tegelijkertijd is het ook niet de bedoeling dat jij "de uitzondering in de groep" wordt. Oftewel de persoon, die gewoon geloofd moet worden als het om problemen gaat. Terwijl de rest van de groep enige overtuigende argumenten moet hebben. Hoe pak je dit aan?

Gebruik teamargumenten

Als het mogelijk is, gebruik dan geen argumenten, die alleen van toepassing zijn op testen. Zeg niet "Dit maakt het voor mij moeilijker om te testen". Zeg "Door dit probleem kan ik minder stories in de sprint testen". Argumenten rond "meer testen in de sprint", "sneller testen in de sprint", "betere kwaliteit van het op te leveren product" of rond andere teamdoelen werken beter dan argumenten, die alleen jou als tester treffen.

Gebruik concrete cijfers

Omdat niet-testers vaak moeite hebben om zich in testproblemen te verplaatsen, kan het zeker handig zijn om te spreken in concrete cijfers. Denk hierbij aan voorbeelden als 

• Als we dit probleem oplossen, kan de test van 4 uur terug gebracht worden naar 2 uur
• Wanneer we dit anders aanpakken, kan ik zeker 25% meer stories in de sprint testen
• Dit probleem kost mij elke dag zeker een uur

Gebruik testargumenten in 1-op-1 gesprekken

Soms is er gewoon geen teamargument. En zijn er geen overtuigende concrete cijfers te maken. Dit kunnen bijvoorbeeld veelvoorkomende, kleine problemen zijn, die je steeds opnieuw 10 minuten kosten. 10 minuten, die je niet kan missen, als je net geconcentreerd met iets belangrijks bezig bent. Maar een tijdsbesteding, die nou niet direct een team kan overtuigen. Of een communicatie, die niet lekker loopt, waardoor je iets 3 x moet vragen, in plaats van 1 x. Niet dat het veel tijd kost, maar het is wel iets wat je steeds in de gaten moet houden. Wat een probleem kan zijn, als je het drukker krijgt.

In elk team zijn mensen, waarmee je over testen kan praten. Vaak de Scrummaster of een teamleider. Maar er zijn in elk team ook mensen, die geïnteresseerd zijn in een goede samenwerking, tevreden collega's, kwaliteit van een product of zelfs in testen. Afhankelijk van het onderwerp kan je je probleem met zo'n persoon bespreken. Dit kan zijn om te kijken hoe je het team kan overtuigen. Maar een concrete oplossing kan ook het resultaat zijn.

Besef ook dat het overtuigen van het team niet altijd nodig is. Veel weerstand tegen het bespreken van "niet belangrijke" problemen, komt doordat het bespreken tijd kost. En niet iedereen kan of wil tijd steken in problemen, die voor hem of haar niet van belang zijn. Als je echter met een concreet voorstel komt, dat je team niet of nauwelijks tijd kost, zal je vaak geen tegenwerking tegenkomen.

Benoem je problemen, ook als je ze niet bespreekt

De neiging kan zijn om je problemen voor je team te verzwijgen. Ze hebben er toch geen aandacht voor. Hoe begrijpelijk ook, dit is niet verstandig. Zorg ervoor dat je team op de hoogte is van de belangrijkste problemen, waar jij als tester tegenaan loopt. Maar geef tegelijkertijd aan, dat dit wat jou betreft niet meteen opgelost hoeft te worden. Bespreken van een oplossing kan op een ander moment.

Het benoemen van onbegrepen problemen kan een afstand tussen jou en het team creëren. Maar het verzwijgen van problemen doet dat met 100% zekerheid. Je zal 100% zeker nooit een oplossing vinden en dat feit kan zeker bij jou spanning gaan veroorzaken. Maken dat je niet lekker werkt in het team. En dat zal alsnog een afstand creëren tussen jou en je team. 

Blijf onderdeel van het team, zonder jezelf te vergeten

Zorg ervoor dat je in een team voor jou problemen de argumenten vindt, die je teamgenoten kunnen begrijpen en accepteren. Zoek argumenten, die aansluiten bij algemene team doelen en beschrijf ze bij voorkeur in concrete getallen. Als dit niet mogelijk is, zoek iemand, die je kan helpen. Bespreek het probleem alleen met deze persoon. Een eventuele oplossing kan dan aan het hele team voorgesteld worden. Maar het allerbelangrijkste: verzwijg je problemen niet. Ook al zijn het problemen van jou alleen... elk probleem van jou is uiteindelijk ook het probleem van het team.

Reactief en proactief testen: wat is het en waarom is het beide nodig?

Reactief en proactief testen: het zijn geen officiële testtermen. Toch merk ik dat ze voor mij steeds meer een belangrijk onderwerp worden. Wanneer test je op basis van incidenten, wanneer op basis van strategie? En waarom is beide nodig?

Bij reactief testen test je op basis van "wat moet er nu getest worden". Hierbij moet je denken aan gebouwde story's, gemelde bugs. Maar ook op basis van klachten en zorgen van klanten, managers, helpdesk, collega's. Je reageert met je testen op wat er in je omgeving gebeurt.

Bij proactief testen test je op basis van een strategie. Dit kan een testtechniek zijn, een risicoanalyse, een analyse van de fouten gevonden in de afgelopen maand. Het grote verschil: hoewel de opgeleverde story's en bugs en ook de klachten en zorgen meetellen, zijn ze niet doorslaggevend. Je kan besluiten om een bug niet te testen of een klacht te negeren.

Ik weet: de scheiding is niet zo strikt. Je kan reactief een story testen, maar deze story vervolgens proactief testen met behulp van een gekozen testtechniek. Of je kan op basis van een proactieve risicoanalyse besluiten om alle bugs reactief te testen. Het belangrijkste is: je hebt als tester een andere rol. Bij reactief doe je wat er van je gevraagd wordt: testen wat getest moet worden. Bij proactief doe je wat er van je verwacht wordt: de kwaliteit bewaken.

Je kan niet altijd de hele omgeving negeren als tester. Opgeleverd werk moet getest worden. Bugs moeten gecontroleerd worden. En klanten of managers hebben eisen en verwachtingen. Als de prioriteit hoog genoeg is, kan je niet als tester zeggen: kan best, maar ik test het niet, want het komt niet overeen met mijn strategie.

Maar je kan ook niet altijd zeggen: ik test gewoon alleen wat er van me gevraagd wordt. Waarom? Dat heeft te maken met een vaak vergeten balans. Iedereen kent de balans van tijd v.s. kwaliteit. Als je minder tijd krijgt, gaat over het algemeen de kwaliteit achteruit. Maar zo is er ook een balans tussen kwaliteit v.s. kwaliteit. Je hebt als tester maar x uur in de week. Als je deze aan programma A besteed, kan deze niet naar programma B. Als je deze aan performance testen besteed, kan deze niet naar functioneel testen. En als je minder tijd kan besteden aan programma B of functioneel testen, is de kans groot dat de kwaliteit van deze applicatie of dit onderdeel gaat afnemen.

Om dit te voorkomen heb je een soort basisdekking nodig. Een soort gegarandeerde minimale tijd of dekking, die een test of een programma of een ander los te testen onderdeel nodig heeft. Dit kan letterlijk tijd zijn. Maar ook een groep eisen, die minimaal getest moeten zijn. Een automatische test, die minimaal uitgevoerd moet zijn. Wat er nodig is, zal je als tester moeten bepalen. En, en dit is het moeilijkste, dit zal onder alle omstandigheden moeten plaatsvinden. Ook als het druk is, ook als het je niet uitkomt, ook als hierdoor een deadline in gevaar komt. Je kan altijd proactief besluiten om meer te testen, maar deze minimale dekking moet plaatsvinden. Zo zorg je ervoor dat de balans nooit teveel doorslaat van A naar B.

Waarom is dit nodig? Vooral in drukke tijden ontstaat de neiging om "per dag" te leven. En als een team onder druk wordt gezet, ontstaat de neiging om "per managerswens" te leven. Je test wat wordt aangeleverd en wat je omgeving van je vraagt. En wat niet wordt gevraagd of wordt aangeleverd, test je niet. Totdat wordt opgemerkt dat in deze opleveringen wel erg veel fouten zitten. Dan opeens wordt het werk geconcentreerd op dit probleem. En ontstaat er precies zo'n zelfde situatie op andere plaatsen. Plaatsen waar jij nu niet test. Zo spring je, als je niet oppast, van de ene critical situation naar de andere critical situation. En zou het dan niet veel beter zijn om een volgende critical situation te voorkomen?

Ja, reactief testen is nodig. Wat opgeleverd is, moet getest worden. En in elke organisaties zijn er nu eenmaal prioriteiten, waar je als tester rekening mee moet houden. Maar je moet wel je testersvaardigheden blijven inzetten. Zorg ervoor dat je alles zo blijft testen, dat je een zekere kwaliteit kan blijven garanderen. Dat de kwaliteit van een oplevering niet alleen afhankelijk is van de externe omstandigheden, maar ook van jou kennis en ervaring als tester. Blijf altijd proactief testen. Het zal niet altijd makkelijk zijn, maar uiteindelijk zal het zowel jou als je organisatie meer rust geven.