De drie manieren om leiding te hebben over je werk en wat de beste manier is

 In mijn ogen zijn er drie manieren om leiding te hebben over je werk: de slijmerd, de betweter en de dictator. En ik vraag je de moed te hebben dit negatief woordgebruik een kans te geven. Ze zijn niet zomaar gekozen, maar het wordt vanzelf positief.

Maar eerst: wat is leiding hebben over je werk? Je hebt de leiding over je werk, als jij, binnen je functie, degene bent met de verantwoordelijkheid over hoe en wat er gedaan wordt en wanneer dit zal plaatsvinden. Hoewel binnen aangegeven kaders, bepaal jij hoe je je werk uitvoert.

Dan de volgende logische stap: wat zijn de drie manieren?

De slijmerd

De slijmerd heeft als voornaamste doel zijn omgeving tevreden te stellen. Deze persoon is daarom een zeer goede luisteraar, die als gevolg hiervan weet wat er speelt. Hij beschikt over goede communicatieve vaardigheden en wordt daarom vaak door bijna iedereen, zo niet iedereen aardig, gevonden.

Als hij niet aardig wordt gevonden, is dat met woorden als "Hij waait met alle winden mee". Hoewel zijn argumenten steeds goed klinken, valt het mensen op dat hij regelmatig van de ene op de andere dag 180 graden van mening gewisseld is. Waardoor mensen het soms moeilijk vinden hem serieus te nemen.

Als slijmerds in de problemen komen, zullen ze meestal praten over gebrek aan waardering. Ze zullen benadrukken wat ze allemaal voor de ander gedaan hebben. En aan het eind stank voor dank krijgen.

De betweter

De betweter heeft als voornaamste doel zijn kennis en ervaring over te brengen op zijn omgeving. Hij heeft hele sterke sociale vaardigheden, waardoor hij meestal veel mensen weet te overtuigen. Voor zijn overtuigingen is hij bereid om tegen de wind in te gaan en ervoor te vechten, al zou iedereen tegen hem zijn.

Als hij niet aardig wordt gevonden, gebruiken mensen woorden als 'Hij luistert niet'. Wat je ook tegen hem zegt, hij geeft het een draai, waardoor het past bij zijn visie. Argumenten, die aansluiten bij wat hij denkt, bevestigen zijn mening. Argumenten tegen zijn niet bewezen, ingebracht door tegenstanders of, de aardige vorm, mensen hebben gewoon het licht nog niet gezien. Betweters worden daarom ook wel gezien als losstaand van de werkelijkheid.

Als betweters in een ongewenste situatie komen, zullen ze zeggen dat mensen niet naar ze luisteren. Als mensen maar zouden luisteren, dan zouden ze beseffen dat hij gelijk heeft.

De dictator

De dictator heeft als voornaamste doel zijn kennis en ervaring zo goed mogelijk toe te passen. De dictator gaat altijd voor de beste oplossing, ook bij tegenstand. Maar gebruikt zijn goede luistervaardigheden om tot de beste oplossing te komen. Alleen als je je omgeving kent, weet je wat goed is.

Als hij niet aardig wordt gevonden, gebruiken mensen woorden als 'Hij is zo moeilijk om mee samen te werken'. Hij duwt en gaat door, ongeacht wat anderen hem vertellen. Zelfs als iedereen hem verteld dat hij ernaast zit, gaat hij gewoon door. In zo'n situatie hoor je vaak over hem, dat hij geen team player is.

Als dictators problemen hebben, hoor je dat ze niet serieus worden genomen. Ze hebben over wat ze doen goed nagedacht. Wat ze willen is goed voor de organisatie en het team. Maar toch wil niemand naar ze luisteren.

De beste keus

En nu verwacht iedereen een verhaal waarom de ene beter is dan de ander. Of een verhaal waarom de ene in een situatie beter is dan de ander. Helaas, dat krijg je niet. De beste keus is een persoon, die werkt aan wat hij niet kan. Een slijmerd moet leren dat mensen niet altijd weten wat goed voor ze is. En dat je daarom soms niet mee moet gaan in wat ze willen. Een betweter moet weten dat zelfs de beste oplossing / de beste methode niet altijd geschikt/waar is. En dat je naar mensen moet luisteren om daar achter te komen. De dictator moet leren, dat mensen geen gedachtelezers zijn. En dat je daarom moet leren mensen te overtuigen met argumenten om je doel te bereiken.

De beste keus is een persoon, die bereid is om te werken aan waar hij niet goed in is. Iemand die op zoek gaat naar collega's, die hem kunnen helpen bij zijn zwakke punt. En ja, dat is het makkelijkste in een omgeving waar alle drie aanwezig zijn.

Veel media tegenwoordig benadrukken een speciale eigenschap als het beste streven. En ook ik heb blogs geschreven waarin bepaalde goede eigenschappen worden opgehemeld. Daar is ook niets mis mee, mits ze voornamelijk gebruikt worden door mensen, die aan deze eigenschap moeten werken. Het geeft ze de kracht op de ingeslagen weg door te gaan. Gevaarlijk wordt het als mensen deze informatie gaan gebruiken om niet te veranderen. Ze hebben al de beste eigenschappen, die ze nodig hebben, waarom zou je meer willen? Nou, omdat, als je echt je werk goed wil doen, je uiteindelijk alle drie de rollen moet kunnen. Hoewel er waarschijnlijk 1 is, die je makkelijk afgaat, moet je kunnen kiezen voor de andere twee. Omdat iedereen in zijn werk situaties tegenkomt, waarin je je moet aanpassen, je boodschap moet verspreiden of gewoon je werk zo goed mogelijk moet doen.

Sta regelmatig stil bij wat je niet kan en verstop dat niet achter wat je wel kan. En help elkaar leren en groeien bij de zwakke plekken.

'Dit is geen bug' of 'Hoe je problemen kan ontkennen'

Je zou denken, dat als iedereen vindt, dat een applicatie iets doet, wat niet zou moeten gebeuren, er weinig reden is tot discussie. Er is sprake van een bug. Gelukkig werkt dat vaak ook zo. Maar soms niet. Soms grijpt men terug naar een oud gebruik: de schuld is niet de applicatie. Nee, de schuld ligt bij de gebruiker of bij de klant.

Wat er hier gebeurt? Een gebruiker kan iets doen in de applicatie, wat niet mogelijk zou moeten zijn. En als gevolg hiervan, doet de applicatie iets ongewenst. Dit kan iets kleins zijn, als een verkeerde tekst tonen. Maar de applicatie kan ook een belangrijk proces blokkeren. Hoe dan ook, je kan hier op twee manieren mee omgaan. Je kan vinden, dat de applicatie dit moet voorkomen. Of je kan vinden, dat de gebruiker gewoon de applicatie goed moet gebruiken.

Even wat nuance en context. Ja, het is vast duidelijk dat ik in basis vind dat de applicatie moet voorkomen dat een gebruiker fouten maakt. Maar hier zijn grenzen aan te stellen. Niet elk invoerveld hoeft bijvoorbeeld een spellingscontrole te hebben. En je hoeft wat mij betreft ook niet hele strikte controles uit te voeren, om te voorkomen dat een adres fout wordt ingevoerd. Er zijn grenzen. En wat die grenzen zijn, moet per applicatie bepaald worden. Maar in beide gevallen ga ik er niet vanuit dat de applicatie plotseling vreemd gedrag gaat vertonen. Spellingsfouten zijn onprofessioneel, maar zullen niet snel problemen veroorzaken in het proces zelf. En een fout adres maakt het niet opeens onmogelijk een bestelling te doen. Voor dit soort zaken zijn ook vaak extra controle stappen voor de gebruiker ingebouwd, plus eenvoudige mogelijkheden dit te wijzigen. Waar het mij om gaat is die invoer, werkelijk zorgt voor een echt ongewenst resultaat. Dus ja, als door een verkeerd adres de bestelling niet opgeslagen kan worden in de database, dat soort zaken zijn bugs. Als de gebruiker zijn eigen verkeerd ingevoerde adres op een bon ziet, dat niet.

Wat ik vreemd vind aan dit onderwerp? Als ik een datumveld test en ik zou ontdekken, dat ik hier 30 februari in kan voeren, zal niemand ontkennen dat dit een bug is. Maar als ik een veld check, waar een bestaande code ingevoerd moet worden en je kan een niet bestaande code invoeren, dan zijn er twee varianten. De gebruiker had beter moeten weten. Of de gebruiker weet beter en doet het daarom niet. Een ander voorbeeld: als ik bij 'geslacht' de keuze ''Man, vrouw, hond of kat' zou zien, is dit een bug. Maar zie ik in een lijst met te verkopen artikelen een product, dat niet verkocht mag worden? Dezelfde twee varianten. Wat ik nog vreemder vind? De kans dat een gebruiker een verkeerd product kiest of een verkeerde code invoert, zie ik als een stuk groter dan dat de gebruiker een ongeldige datum of geslacht invoert.

Wat speelt hier vaak echt? In mijn ervaring is hier meestal sprake van een van de volgende problemen: tijdgebrek of kennisgebrek. Of zelfs allebei. De eerste: men neemt of krijgt de tijd niet om het werk goed af te ronden, zodat dit soort fouten niet ontdekt en opgelost kunnen worden. Snelheid is belangrijk, dus voor dit soort extra checks, zeker omdat deze vaak ingewikkelder zijn dan een datum check, is geen tijd. De andere is: men heeft geen idee hoe het moet werken. De kennis om te bepalen wat goed is en wat fout is niet aanwezig. En daarom wordt die verantwoordelijkheid gelegd bij de persoon met de kennis: de gebruiker of de klant.

Moet je deze bugs oplossen? Wat mij betreft is die discussie op te lossen met de ouderwetse prioriteiten: Blocking,  Critical, Major, Minor. Of wat bij jou de prioriteiten ook zijn. Wat is dan wel belangrijk? Benoem de werkelijke problemen. Als je niet de tijd hebt om een scherm goed af te ronden, los dit niet op door het toestaan van foute invoer geen bug te noemen. Benoem het tijdsprobleem en geef de risico's aan. En als je de kennis niet hebt, erken dit. Geef aan dat dit een risico vormt, omdat hierdoor onbekende bugs aanwezig kunnen zijn.

Waarom is dit zo belangrijk? Op het moment dat je praat over 'slechts 1 situatie' lijkt het belang niet zo groot. Maar omdat tijd en kennis problemen vaak lopen over langere tijd, nemen deze situaties steeds meer toe in je applicatie. Omdat het geen bugs zijn, worden ze niet vastgelegd. Omdat de kennis als bekend wordt beschouwd, wordt er niets vastgelegd. En zo creëer je stap voor stap een mijnenveld. En in het begin weet misschien iedereen waar de mijnen liggen. Maar op een bepaald moment niet meer. Vanaf dat moment is het wachten tot iemand op een mijn stapt.

Tijd- en kennisproblemen komen regelmatig voor. Ik ben er als tester in ieder geval niet meer van onder de indruk. Gevaarlijk wordt het pas, als je ze niet meer benoemt. En de gevolgen gaat verstoppen. Bijvoorbeeld door bugs geen bugs te noemen, Een extra probleem:  juist door dit soort gevolgen te verstoppen vererger je tijd- en kennisproblemen. Door ingebouwd, vreemd, niet vastgelegd gedrag neemt de kennis verder af. En het oplossen van 'echte' bugs of toevoegen van functionaliteit kost meer tijd, doordat niemand nog weet hoe de applicatie eigenlijk moet werken. Blijf daarom een bug een bug noemen. En een tijd- of kennisprobleem een tijd- of kennisprobleem.

Ketentesten met Appium

Ik probeer vaak het uiterste te halen uit de tools, die ik gebruik. Ik accepteer niet snel "Nee" van een tool. En ik vind ketentesten erg belangrijk, omdat dat de enige manier is, om zeker te weten dat twee of meer losse componenten/apps/enz. goed op elkaar aansluiten. Dus, deze twee gecombineerd, wilde ik ketentesten met Appium. In mijn geval een combinatie van een mobiele browser en een app.

Appium heeft als belangrijkste doelgroep om 1 mobiele app te testen. Je bent niet helemaal beperkt tot 1, je kan elke app, die je maar wil, opstarten. Maar bij het starten van de testsessie in Appium wordt 1, laten we het noemen, hoofdapp gevraagd. Wat wel van belang is om te weten: voor het uitvoeren van een actie (vinden of gebruiken van een element), gaat Appium niet automatisch naar de hoofdapp. De actie wordt uitgevoerd op de op dat moment actieve app op de mobiel.

Start app:
Activate App - Appium

Daarnaast kan je gebruik maken van de functionaliteit, die eigenlijk bedoeld is om hybride apps te testen. Bij deze moet je soms wisselen tussen HTML (webview) en niet-HTML (native). Deze functionaliteit kan je ook gebruiken om te wisselen tussen een browser en een app (mits je met activate ervoor zorgt, dat je de juiste app ziet). Al heb ik gemerkt, dat dit vaak niet nodig is. Met de zogenaamde 'native' optie kan je op Android met Chrome en op iOS met Safari al heel veel elementen in een website vinden en bedienen.

Wisselen tussen webview en native
Set Context - Appium

Maar wat werkt er niet? Om Appium te starten moet je een sessie starten. En deze sessie kan slechts gekoppeld zijn aan 1 app. En met de gekoppelde app kan je net iets meer. Voor mij is het belangrijkste: een goede herstart. De eerste genoemde 'activate' start een app alleen op. Als je bijvoorbeeld ingelogd was, blijf je ingelogd. En meestal wil je je test niet ingelogd starten. Tenzij je allerlei code gaat schrijven om na te gaan of uitloggen nodig is, is dit een probleem. Maar de app van de sessie start automatisch 'vers' op, wat inhoudt, dat je meestal niet ingelogd bent. Dit geeft vooral problemen als je meerdere testen achter elkaar draait. Je kan heel netjes aangeven dat een test eerst inlogt en dan uitlogt. Maar als de test faalt..... ben je nog steeds ingelogd. Wat een probleem kan zijn voor de volgende test.

Appium kan het beste met 1 sessie tegelijkertijd draaien, anders kan je performance of stabiliteitsproblemen krijgen. Daarom heb ik nu code geschreven, die zorgt voor de 'verse' start, die alleen even de sessie opstart, met de gewenste app, en daarna weer sluit. Vervolgens start ik met de test.

In het algemeen kan je dus zeggen, dat ketentesten in Appium kan. Om dit voor elkaar te krijgen, maak je gebruik van functionaliteit, die hier waarschijnlijk niet voor bedoeld is. Maar wel geschikt. Appium kan al heel veel, waarschijnlijk altijd bedoeld met een bepaald doel voor ogen. Kijk daarom niet naar het doel, maar naar wat er werkelijk gebeurd. En ontdek hoe je Appium in jouw bedrijf het beste toe kan passen.

Zondebokken zonder zondebokken

Stel, je hebt een machine. Op deze machine zit een knop. Hier staat met grote letters bij "Niet op deze knop drukken". Als je namelijk op deze knop drukt, leg je de hele machine stil. Toch zijn er steeds opnieuw weer mensen, die op de knop drukken. Wat doe je?

De reden dat ik hieraan denk, is door zaken waar ik de laatste tijd zelf veel tegenaan loop. Ik vind het belangrijk om problemen te benoemen. En ja, dat komt regelmatig neer op: collage x deed y en daardoor is probleem z ontstaan. Regelmatig kom ik mensen tegen, die daardoor automatisch ervan uitgaan, dat ik de schuld bij collega x neerleg. En ja, soms doe ik dat ook. Meestal echter niet. Ik wil de situatie beschrijven, het probleem beschrijven. In mijn ogen zijn we nog lang niet toe aan het aanwijzen van een schuldige. Als we dat al ooit zijn.

Stel dat ik als tester een ernstige bug gemist heb. Een die nooit in productie had mogen komen. Hoe ga ik hiermee dan mee om? Voor mij is dan de eerste vraag: "Had ik dit kunnen voorkomen?" Dit is een vraag naar kennis, ervaring en tools. Beschikte ik over de kennis om de bug te voorkomen? Dit kan gebeurt zijn in een scherm, waar nooit iemand me over verteld zijn. Via een programma, waarvan ik het bestaan niet wist. Ook kan het zijn, dat ik het wel wist, maar niet kon testen. Voor dit scherm heb ik namelijk de rechten niet gekregen. Of ik beschik niet over voldoende testdata om die betreffende situatie na te gaan. Bij zulke problemen is het antwoord: "Nee, dit had ik niet kunnen voorkomen". De oplossing gaat dan ook in de richting van meer kennis, betere tools. En soms is het gewoon: "Nu ik dit weet, gaat dit niet nog een keer gebeuren". 

De volgende vraag is een stuk moeilijk: "Had ik het moeten voorkomen?". Ik werk 40 uur per week en deze tijd moet ik verdelen over al mijn werk. Daarom moet ik keuzes maken in wat ik wanneer test en hoe. Waar ik mijn tijd aan besteed. Stel ik heb scherm A minder heb getest, omdat ik scherm B beter wilde testen. Vervolgens heb ik door het testen van scherm B 5 ernstige bugs voorkomen, was dit dan een verkeerde keus? Zelfs als later blijkt dat in scherm A alsnog een grote fout zit? En wat als ik inschat dat de kans op een fout in scherm A zeer klein is, maar in scherm B groot. Vervolgens test ik scherm B beter en vind niets. Was dat een foute keuze, als scherm A later een ernstige bug blijkt te hebben? Want wat als ik zeg "Ja" en ik kies dan scherm A beter te testen, maar later blijkt mijn inschatting juist en hierdoor gaat scherm B naar productie met 5 ernstige fouten?

Deze vraag heeft te maken met risico inschatting. En hier is een goed besef nodig van het volgende: ook als het verkeerd uitpakt, kan de risico inschatting goed zijn geweest. Daarom is van belang niet naar het resultaat te kijken, maar naar het proces. Hoe is het risico bepaalt? Want ja, regelmatig blijkt dat het risico niet goed is ingeschat. Omdat een aanpassing toch meer code raakte dan ik dacht. Of omdat een proces belangrijker was dan gedacht. Maar het antwoord kan ook zijn: de risico inschatting was goed, ongeacht het ongewenste resultaat. De kans was 1 op 1000 en dat was bekend. Helaas was dit de 1 op 1000.

Wat het verschil is met de eerste vraag? Ja, ik heb nu misschien ook kennis gebrek, maar met de kennis, ervaring en tools die ik had, had ik de bug wel kunnen voorkomen. Ik besloot echter tot handelingen, waardoor de bug gemist is.

Als beide vragen "Ja" zijn, komt de laatste vraag: "Waarom heb ik de bug niet voorkomen?" Waren er teveel testen, waardoor ik op de automatische piloot ging werken? Waren er te weinig testen, waardoor ik zaken vergeten ben? Was ik te druk, waardoor ik niet geconcentreerd genoeg was? Lette ik op teveel zaken tegelijkertijd, waardoor ik niet meer 100% kon geven? Als ik de oorzaak weet, dan kan ik op zoek naar een oplossing.

Waarom dit hele verhaal? Omdat een veelgebruikte of veelgenoemde oplossing hier niet tussen staat: tegen mij zeggen dat ik de volgende keer beter moet testen. Zelfs niet: tegen mij zeggen dat ik de volgende keer scherm A moet testen, omdat deze een ernstige bug bevat. Waarom niet? Om twee redenen:

• Ik ben ervaren genoeg om te weten dat dit niet nog een keer mag gebeuren. Over het algemeen hoef je me dat niet te vertellen.

Maar wat voor mij nog veel belangrijker is:

• Door zulke opmerkingen suggereer je dat ik iets fout heb gedaan, iets beter had kunnen doen. Puur alleen om het feit dat er iets fout is gegaan. En hoewel je gelijk kan hebben, kan je net zo goed ongelijk hebben. Puur het feit dat door mij een fout in productie is gekomen, zegt nog niet dat ik de bug had kunnen of moeten vinden.

Ik hecht veel belang aan het goed evalueren van een probleem of bug. En ik weet dat de enige die me daarbij kan helpen collega x is. Daarom, als ik zeg dat collega x door y probleem z heeft veroorzaakt, bedoel ik: we hebben collega x nodig om dit probleem in de toekomst te voorkomen.

Dus die machine met die rode knop? Ik zou gaan praten met alle mensen, die erop gedrukt hebben. Hoe en waarom dat gebeurt. Hoogstwaarschijnlijk zou ik niet de tekst "Niet op deze knop drukken" groter maken. Of elke maand mensen eraan herinneren dat ze goed moeten lezen voor ze iets doen. Waarschijnlijk zou ik kijken of we de knop kunnen verplaatsen naar een minder zichtbare plek. Of de knop afdekken, zodat je er niet zomaar op kan drukken. Want het werkelijke probleem zal waarschijnlijk zijn: het is veel te makkelijk om op de knop te drukken voor een knop, die bijna nooit nodig is.

Iedereen mag fouten maken en daarom.... mag iedereen fouten vinden

Iedereen maakt fouten. En daarom zijn er testers. Om fouten van anderen te vinden. Maar er is meer. Dit houdt ook in dat de tester fouten maakt. Ja, er is tegenwoordig steeds vaker de houding van "Iedereen mag fouten maken", de tester is daar geen uitzondering op. Maar ik mis de vervolgstap. Voor mij, als iedereen fouten mag maken, mag iedereen ook fouten vinden.

Als je kijkt naar redenen voor fouten, zijn de gebieden waar ik aan denk: informatiegebrek, kokervisie, verkeerde prioritering, miscommunicatie, zaken vergeten, zaken gemist, enz. Sommige van deze problemen kunnen opgelost worden met een tweede paar ogen. Al of niet een tester. Sommige niet. Kokervisie is daar het meest duidelijke voorbeeld van. Dit doet zich vaak voor bij een groep personen. Bijvoorbeeld de testers in een bedrijf of de team werkend aan een product. Neem de groep testers. Deze kan bijvoorbeeld heel erg gefocust raken op regressietesten. En alle tijd en aandacht zo ongeveer daaraan besteden. Maar door deze extra besteedde tijd kan het gebeuren, dat de validatie van gegevens opeens veel meer fout gaat. De tijd voor de regressietestverbetering moet tenslotte ergens vandaan komen. Dit wordt echter niet gezien, want de focus ligt nu op de regressietestbugs. En de validatiebugs vallen daar niet onder. Dan heb je een niet-tester nodig, die bijvoorbeeld zegt: "Hoe kan het dat we opeens heel veel problemen hebben met ongeldige gegevens in onze database?"

Waarom is dit van belang voor een tester? Als tester ben je vaak het tweede paar ogen, waardoor anderen fouten mogen maken. Een belangrijk paar ogen. Daarom moet je beseffen dat ook dit paar ogen af en toe een fout maakt. En dat je er als tester naar moet streven om dit te voorkomen. Wat betekent dat je open moet staan voor fouten, die gevonden worden door anderen. Niet alleen andere testers, maar ook andere collega's, misschien wel van andere teams of afdelingen. En misschien zelfs wel van andere bedrijven. Om dit te promoten is het belangrijk dat je als tester een omgeving creëert, waarin mensen zich vrij voelen bugs te melden. Hoe doe je dit?

Beoordeel bugs zo objectief mogelijk

Wat ik vaak zie en hoor is dat de bron van de bug zwaar wordt meegenomen in de beoordeling. Of een bug in productie is, of hij van de manager afkomt, of hij van een tester afkomt, of de bug geëscaleerde is. Nee, ik ga niet schrijven dat dit totaal niet uitmaakt. Als je twee major bugs heft en 1 is in productie, los je diegene in productie op. En ja, als je twee critical bugs hebt, kan het verstandig zijn die van de manager eerder op te lossen.

Waar het om gaat is dat je de beoordeling van blocking, critical, major, minor, trivial niet laat afhangen van de bron. Dus als een manager een major bug heeft gevonden, maar aan de lunchtafel hoor je een collega van een heel ander team over een critical bug, dan gaat de critical bug voor. Wat voor criteria je ook gebruikt voor deze indeling, wie de bug gemeld heeft is hiervoor niet van belang.

Waarom is dit belangrijk? Ooit wel eens een probleem verteld en te horen hebben gekregen "Je kan best gelijk hebben, maar dit heeft voor de manager/het bedrijf geen prioriteit". En heeft dit je ooit gemotiveerd om problemen te blijven melden? Voor het melden van bugs werkt het niet anders.; Een argument als "Van deze bug hebben niet al teveel klanten. Daarom geef ik voorrang aan bugs, die meer klanten raken." kan iemand misschien tegenhouden elke bug te melden. Maar als er iets ernstigs is, blijft de kans groot dat je het te horen krijgt. "Ik heb al een lijst met 50 bugs van mijn manager en die moeten eerst" kan elke bugmelding blokkeren.

Leg uit waarom

Als tester prioriteer je misschien naar testverbeteringen. Als expert zal je dan snel de neiging hebben mensen gewoon te vertellen wat je wil. Jij bent de expert, dus jij beslist. En in veel gevallen zal dit geen duidelijke problemen geven. Je zal meestal gevolgd worden. Tot je prioritering of verbetering een fout besluit is. En niemand dat kan zien, want het enige wat ze kunnen zien is dat je doet wat je hebt gezegd.

Als je aan iemand verteld wat je gaat testen of hoe je gaat testen, vertel dan ook waarom. Vertel wat je wil bereiken. Minder bugs in productie, een sneller testproces, meer kennis van de applicatie, het maakt niet uit. Of in het geval van testen: een goed werkende validatie, goede integratie met andere apps, enz. Maar vertel altijd je doel. Naast draagvlak, wat altijd handig is, zorgt dit voor iets anders. Als jij met je ideeën je doel niet bereikt, kan dat ook door anderen opgemerkt worden. Als jij de testtijd verdubbelt om de bugs flink terug te brengen, kan iemand opmerken dat voor een verdubbeling van de tijd 10% minder bugs niet veel is. En dat het aantal grote bugs zelfs bijna gelijk is gebleven. Zodat de vraag gesteld kan worden: is dit wel de juiste weg voor het doel dat je wil bereiken.

Neem iedereen serieus

Ook als tester kan je verstrikt raken in problemen als kokervisie en informatiegebrek, waardoor je ernstige fouten mist. En als je team of directe collega's dezelfde kokervisie hebben of dezelfde informatie missen, kunnen zij je hier niet bij helpen. Daarvoor heb je een buitenstaander nodig. Die persoon dus, die vaak als lastig wordt gezien, omdat die zich met zaken bemoeit, waar hij/zij geen verstand van heeft.

Als iemand denkt een bug te hebben gevonden en dat wil laten weten, neem daar altijd de tijd voor. Geef altijd een reactie. Als iemand een onbelangrijke of onterechte bug meldt, leg uit waarom. Maar probeer te voorkomen dat je reactie overkomt als "Val me hier niet mee lastig". Hoewel dit misschien de meest logische is, is dit tegelijkertijd de moeilijkste. Als iemand zegt "Waarom heb je die bug niet gevonden?", terwijl je weet dat geen klant die bug ooit zal vinden, krijg je de neiging om te denken "Hoepel even op". En als iemand steeds opnieuw kleine, onbelangrijke bugs meld, of nog erger, onterechte, krijg je de neiging die persoon te negeren. En toch moet je blijven proberen deze personen serieus te nemen. Allemaal. Altijd

Dus iedereen mag fouten vinden, tester of niet

Het belangrijkste is te beseffen dat je als tester anderen nodig hebt om goed te blijven testen. Niet alleen je manager, andere testers of teamgenoten, maar soms ook buitenstaanders. Dit geldt zeker als het aankomt op het melden van bugs, die je misschien gemist hebt. Maar geldt ook voor je testaanpak of je testverbeteringen. Geef iedereen daarom het gevoel dat ze fouten bij je kunnen melden, wat het onderwerp ook is. Geef ze het gevoel serieus genomen te worden. En help je omgeving om je op fouten te betrappen, door ze te informeren over je doelen als tester. Hoewel dit allemaal niet zo eenvoudig is, zal je er uiteindelijk als tester door groeien.

Hoe streven naar tevreden collega's/managers/medewerkers kan leiden tot wantrouwen

We zijn graag aardig tegen elkaar en veel van ons willen daarom graag de ander een plezier doen. Daar lijkt niets mis mee. Maar als je hier te ver in gaat, kan er wantrouwen ontstaan. Omdat, wat een goede daad lijkt, uiteindelijk de persoon/het team zelf en/of zijn of haar omgeving schaadt.

Wat doet dit in een testblog? Ik heb dit als tester met grote regelmaat zien gebeuren. Ik heb het zien gebeuren met testers. Ik heb het zien gebeuren door testers. Het onderwerp is van belang voor testers, omdat hun positie in het bedrijf vaker een minderheidspositie is en daardoor het team tevreden houden een belangrijk onderdeel is. Het onderwerp is belangrijk voor mensen, die met testers werken, omdat testers tevreden houden, zodat ze willen blijven, juist bij testers regelmatig belangrijk wordt gevonden. En omdat hun positie van "aangeven wat er fout is" ervoor kan zorgen, dat je juist hun wil negeren om het team tevreden te houden.

Voor de duidelijk: in deze blog spreek ik van kritiek en niet van het sociaal acceptabeler feedback. Dit is bewust. Feedback is een term, die beter bekend staat, omdat het een combinatie is van wat goed ging en wat fout ging. Kritiek heeft een negatieve naam en kan daarom het idee geven, dat alleen zeggen wat fout ging, altijd verkeerd is. En dat vind ik juist een van de problemen. Om dit beter uit te laten komen, houdt ik daarom dit woord aan.

Streven naar tevredenheid kan, in mijn ervaring, op zeker drie manieren leiden tot wantrouwen

1. Je aanpassen aan de wensen van anderen
2. "Ja, dat doe ik" zeggen
3. Niet geven van kritiek

Je aanpassen aan de wensen van een ander

Het klinkt zo mooi. Een leidinggevende, ondergeschikte of collega, die altijd precies doet wat jij wilt. U zegt, zij draaien. En voor jou is het waarschijnlijk ook zo mooi. Waarom niet? Je krijgt wat je wil. En de andere kant: het klinkt ook zo simpel om mensen blij te maken. Doe gewoon wat ze willen en ze zullen tevreden zijn. Je zal deel uitmaken van het team, gewaardeerd worden. Dat kan toch niet anders?

Bijna altijd is het anders. Mensen, die bekend staan om hun aanpassen aan anderen, staan vaak bekend om het feit, dat ze hun werk niet goed uitvoeren. En mensen, die hun werk niet goed uitvoeren, worden niet gewaardeerd en niet vertrouwd. In veel omgevingen worden dit soort mensen als gevaarlijk gezien, omdat ze producten, projecten en soms zelfs banen in gevaar kunnen brengen. Vooral doordat ze verkeerde beslissingen nemen en fouten of problemen over het hoofd zien of negeren.

Doordat ze zich aanpassen, hebben ze echter vaak mensen, die hun werk wel waarderen. En dat zijn de mensen, die door deze aanpassers geholpen worden hun eigen doelen te bereiken. Als of de aanpasser of de tevreden persoon in een leidinggevende positie zit, kan dit een hele slechte werksfeer opleveren, waarin wantrouwen in het team centraal staat. Want waar kan je nog veilig het functioneren van deze persoon bespreken?

Hoe komt dit? Een aanpasser past zijn of haar werk aan aan de wensen van een ander. Even voor het gemak uitgaan van een tester, zullen deze wensen vaak niet van een andere tester komen. Dat betekent dat een tester test zoals de leidinggevende, ontwikkelaar, enz. wil. En dat betekent dat er geen gebruik wordt gemaakt van de kennis en vaardigheden, die een tester als tester heeft. Wat hem of haar uniek maakt of kan maken binnen een team. De kennis en vaardigheden, die erop gericht is de problemen in een product te vinden. Te testen op een manier, waar niemand aan gedacht heeft. Bijvoorbeeld meer focus op de integratie, in plaats van op de losse onderdelen.

Als een ontwikkelaar, leidinggevende, enz. goed genoeg zou testen, om zijn of haar wensen als leidraad te nemen voor testen, dan zou er geen tester nodig zijn. Dan kan iedereen testen. Maar als je geloofd dat een tester nodig heeft, moet je ook promoten dat een tester zijn of haar eigen pad bewandeld. Wat inhoudt, dat hij of zij niet altijd zal doen wat jij zou doen. Of wat inhoudt dat jij niet altijd doet, wat hij of zij wil.

Het is niet erg om de ideeën en meningen van anderen mee te nemen, als je je werk doet. Maar wat van belang is, is dat je zelf verantwoordelijk blijft voor de besluiten rond je werk. Op lange termijn zullen mensen meer tevreden zijn, als je je werk goed doet, dan als je ze hun zin geeft. Ze zullen leren vertrouwen op je kennis en vaardigheden, omdat ze zien dat je goed werk levert. En iemand die goed werk levert, levert een bijdrage aan een tevreden team en tevreden bedrijf. En dat draagt weer bij aan tevreden collega's, leidinggevenden en ondergeschikten.

"Ja, dat doe ik" zeggen

Mensen willen elkaar niet teleurstellen. Als iemand iets aan je vraag, wil je daarom niets anders zeggen dan "Ja, dat doe ik". Want dat geeft aan, dat je iemand serieus neemt. Dat je zijn of haar wensen belangrijk vindt. Dat je zijn of haar werk belangrijk vindt. Te veel mensen maken dan de fout om (bijna) standaard "Ja, dat doe ik" te zeggen.

Vervolgens komen ze bekend te staan als onbetrouwbaar. Want ze kunnen al die "Ja's" met geen mogelijkheid nakomen. Door tegenwerkend management, door tijdgebrek, door geldgebrek, door tegenstrijdige belangen. En soms gewoon omdat deze persoon zo'n lange "To do lijst" heeft, dat dingen vergeten worden.

Ik kan hier kort over zijn: wees gewoon eerlijk in wat je kan en wat je niet kan. Niemand wil "Nee" of "Niet nu" horen. Maar "Ja" horen en "Nee" krijgen wordt nog veel minder gewaardeerd.

Niet geven van kritiek  

Een andere soms gevaarlijke vorm van het streven naar tevredenheid is het niet geven van kritiek. Dit heeft een wat slechtere naam, dan het vervullen van wensen van anderen of "Ja, dat doe ik" zeggen, maar komt in de praktijk zeer regelmatig voor. Je hoort dan argumenten als: hij/zij werkt zo hard, hij/zij doet zo zijn best, hij/zij heeft het zo druk, hij/zij bedoelt het goed. En vul dit lijstje maar aan met de andere argumenten, die je kent. Een ander sterk argument is: ik wil niemand de schuld geven. Iemand aanspreken op zijn of haar fouten, kan overkomen als iemand de schuld geven van bijvoorbeeld een probleem in het team of een fout in een product. En dat wil je niet. Dat zou niet terecht zijn.

In een team of organisatie staan mensen, die geen kritiek krijgen, vaak bekend als mensen die keer op keer dezelfde fout maken. Die niet leren van hun fouten. Mensen, die anderen hun zaken op laten knappen, omdat anderen door hun fouten meer werk hebben. Of mensen, die steeds opnieuw in hun omgeving mensen tegen hun in het harnas jagen, door wat ze zeggen of doen. En dat elke keer weer opnieuw. Deze mensen, die fouten maken en er niet van leren, worden niet vertrouwd. Omdat iedereen gewoon wacht op het moment, dat ze hun fout opnieuw maken.

En als je er wat van zegt? Dan krijg je te horen, waarom je het maar moet accepteren. Oftewel waarom deze persoon een uitzondering moet krijgen. Oftewel dat je niet alle problemen op deze persoon af moet schuiven.

In dit geval is de oorzaak vaak simpel. Mensen hebben hulp nodig om van hun fouten te leren. Ze hebben iemand nodig, die ze verteld wat ze fout doen. En meestal hebben ze iemand nodig, om te leren hoe het anders kan. De groep mensen, die in staat is zijn of haar eigen fouten en oplossingen te vinden, is heel klein. Het is daarom aan de omgeving om zo'n persoon daarbij te helpen.

Wat betreft het schuld geven: het is bijna nooit zo dat een probleem of fout door 1 persoon is veroorzaakt, zeker niet als het probleem of de fout aan de grote kant is. Van belang is daarom, dat het geven van kritiek bijna nooit naar aanleiding van 1 incident mag zijn. Er moet sprake zijn van een patroon. Je bespreekt het niet, omdat die persoon dit probleem of dit incident heeft veroorzaakt. Je bespreekt het, omdat je bij deze persoon meerdere keren hetzelfde probleem zag. Dat staat volledig los van het incident.

Wat ook helpt, is bij een situatie niet 1 oorzaak bespreken, maar meerdere. Stel dat een tester een ernstige bug heeft gemist, dan is die vaak ook gemist door de ontwikkelaar. In veel gevallen is de bug ook gemist, doordat de voorbereiding van de wijziging niet goed is geweest. Er miste informatie of er is een invalshoek (b.v. een validatiecheck) vergeten. Al deze kritiek bespreken, voorkomt het zondebok gevoel.

Dus hoe kan je wel streven naar tevredenheid?

Als je je werkomgeving tevreden wil stellen, doe dat dan door je kennis en ervaring op peil te houden. Streef ernaar genoeg te weten, om je werk goed te kunnen uitvoeren. Zorg dat mensen vertrouwen in je krijgen, door je werk, niet door je inzet om andermans wensen te vervullen.

Streef naar afspraken, die je na kan komen. Niet afspraken, die je na wil komen. Zorg ervoor dat mensen erop kunnen vertrouwen, dat je "Ja" ook echt "Ja" is.

Help mee aan een omgeving, waarin kritiek bespreekbaar is. Luister naar problemen en ideeën van anderen. En spreek ook zelf openlijk over je problemen en ideeën. Zorg voor een omgeving waarin mensen vertrouwen hebben, omdat ze serieus genomen worde.

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!