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.