'Investeer in technieken die je helpen lastige situaties het hoofd te bieden'. Het is een van de dingen die Rik Teuben van detacheerder VX Company testers aanraadt. Computable zet zijn tips op een rijtje.
Testers moeten niet alleen letten op de techniek, maar ook op hun eigen communicatievaardigheden, vindt Rik Teuben van detacheringsbureau VX Company. Volgens de technisch manager testing houdt een goede tester de volgende punten in de gaten:
-
Laat je als tester door niets of niemand wijsmaken dat jij de enige bent in het project die zich inzet voor kwaliteit. Een ontwikkelaar is oké en een tester is oké.
-
Kies altijd voor de effectieve en haalbare manier van testen. De rest is onbelangrijk.
-
Door als tester op crisismomenten te participeren aan het projectresultaat, beïnvloed je de kwaliteit van het eindresultaat veel meer dan door op de rem te trappen.
-
Investeer als tester in technieken die je helpen om lastige situaties het hoofd te bieden. Investeren in communicatieve vaardigheden, sociale vaardigheden en politieke vaardigheden loont!
-
Kennis alleen is niet voldoende. Leer als tester de juiste keuzes te maken. Ontwikkel een fijne neus voor wat belangrijk is en wat niet.
-
Besef: Wie geeft om zelfbehoud, vindt de project-hectiek in honderdvoud…
-
Zorg er als tester voor dat je niet gehinderd wordt door je eigen vermeende genialiteit.
-
Niemand is te motiveren als de tester meent dat er geen hoop meer is. Leer te geloven tegen beter weten in, het is een zegen voor het eindresultaat.
-
Weet wat je doet, kies bewust en handel vanuit een vast, onveranderlijk verlangen naar kwaliteit.
-
Zet wantrouwen en achterdocht aan de kant, maar verlies ze niet uit het oog.
Ik heb 1 tip voor testers in verband met dit artikel:
1. Dit artikel toont de kwalitatieve achterstand aan van VX Company.
Lekker ongefundeerde reactie, maar dit artikel is puur vanuit management oogpunt. Een tester wordt afgerekend op gevonden fouten, niet op kwaliteit. Als dat verandert, kan een tester ook eindelijk eens een keer politiek gaan bedrijven, tot die tijd: Zolang je maar niet bot bent, gewoon als het nodig is een negatief advies blijven geven op basis van je ervaring en vooral, alle bevindingen doen, ook de pietluttige.
Interessant artikel, interessante reactie.
Ik kan me vinden in de tips. Alhoewel op de rem trappen soms participeren in het projectresultaat is. Veel projectmanagers (en geldschieters) laten projecten doorlopen omdat er voor hen iets van af hangt en stoppen (of iets terug) met de billen bloot is en dus geen optie. Jammer, leuk of niet, maar dan zul je als tester soms gewoon kei hard aan de noodrem moeten gaan hangen.
Beetje kort door de bocht van MjK om hier te roepen dat VX een kwalitatieve achterstand heeft. Dat is misschien wel zo, maar dat haal ik zeker niet uit dit artikel. Dit artikel schetst een mening. Ik neem aan dat er genuanceerder naar testen gekeken wordt als deze 10 tips lang zijn….
Ik ben het overigens niet eens met MjK dat een tester afgerekend wordt op gevonden fouten. Hij wordt ook afgerekend op voorkomen fouten. En daar kunnen de tips je bij helpen!
Gelukkig zijn we het allemaal eens dat je niet te bot moet moet zijn en een advies moet geven waar je achter staat! Happy testing!
Graag nodig ik iedereen uit om kennis te maken met het kennisniveau van de testers van VX Company. Onze opdrachtgevers denken over ons kwaliteitsniveau gelukkig anders dan MjK :-).
Voor een genuanceerd (maar vooral ook gefundeerd) beeld verwijs ik graag naar onze website (www.vxcompany.com)
We zoeken overigens nog meer goede testers die op een waardevolle, attractieve, toepasbare, energieke en relevante wijze de kwaliteit van systeem development, acceptance of delivery willen begeleiden en zich als professioneel tester bij ons aan willen sluiten 🙂
en als laatste een wijze les van ome Rik: “Wonend op een aardbol is achterstand en vooroplopen niet voor iedereen altijd duidelijk van elkaar te onderscheiden…”
Met hartelijke groet,
Rik Teuben 😉
Het belangrijkste wat je als tester kunt doen is naar mijn mening zo vroeg mogelijk signaleren, of het nu een risico, afhankelijkheid, bevinding, of wat dan ook is.
Als dan geluisterd wordt is er geen crisis moment nodig.
En simpel gezegd kloppen dan een aantal dingen gewoon niet die toch telkens terug komen:
1. Als netjes met de hierboven genoemde signalen wordt om gegaan is crisis niet nodig.
2. Door punt 1 is politiek bij testers niet nodig.
3. Doordat politiek niet nodig is, kunnen tester ongeremd blijven in het signaleren.
4. Punt 3 zorgt voor een verhoogde kwaliteit.
5. Doel bereikt.
Wat ik dus heel heel erg mis, is het management aspect. En dat bevestigd het algemene gevoel van een flink aantal tester in grote organisaties: “het maakt niet uit wat ik roep of doe, het systeem wordt toch wel doorgevoerd”.
En dit soort artikelen legt de zere vinger weer bij testers, zodat managers weer nieuw voer hebben.
Ik ben het overigens roerend met Rik eens dat er genoeg testers zijn die eens wat tactiser moeten communiceren als ze een bevinding doen, dus het: “Jij hebt het fout gedaan” gehalte mag best wel wat minder.
“…dus het: “Jij hebt het fout gedaan” gehalte mag best wel wat minder.” Dat ligt er maar precies aan op welke manier je als projectleden met elkaar omgaat. Ik heb in projecten gezeten waarin dit gewoon kon. Ik kreeg ook net zo hard het antwoord terug “Er zit een fout in je testdata”. Dat is een vertrouwen dat je in elkaar opbouwt. In het begin zal dat aftasten zijn en voorzichtig iets brengen. Later kan het wat ongenuanceerder en directer. Dan weten beide partijen al wat ze aan elkaar hebben. Komop, we zijn geen porceleinen poppetjes die met handschoentjes aangepakt hoeven te worden…
Qua management ben ik het met MjK eens. Een testmanager zou in mijn visie ook niet “onder” een projectmanager moeten vallen, maar “naast” een projectmanager moeten staan, en dus net zo direct issues in moeten kunnen dienen bij een stuurgroep. Een projectmanager beheerst een project op basis van tijd en geld. Een testmanager op basis van kwaliteit. Die zaken zijn heel vaak strijdig. En in de huidige vorm wint de projectmanager inderdaad vaker… Ik laat dat besluit liever aan de business opdrachtgever over. Goed opdrachtgeverschap heet dat.
Een testmanager die rechtstreeks aan de stuurgroep rapporteert? Dat lijkt me geen goed plan. Het is waar dat een projectmanager vaak op basis van tijd en geld stuurt, maar hij is eindverantwoordelijk. Dus ook voor de kwaliteit!
Mag een developmentmanager zijn issues dan ook zelf in de stuurgroep gooien? En de ontwerper? Waar hebben we die projectmanager dan nog voor? En zit een stuurgroep te wachten op input van allerlei kanten uit het project? De business die in de stuurgroep zit, zou aan haar achterban moeten vragen wat ze vinden. In een Prince2-project zit er niet voor niets een senior user in de stuurgroep.
Door een testmanager “naast” de projectmanager te zetten, doe je aan syntoom bestrijding. Waar het fout gaat, is in de stuurgroep. Vaak te veel ICT en te weinig business. En weet de stuurgroep wat ze precies moeten doen? Of varen ze blind op de projectmanager? Ik zou als stuurgroep de testmanager vragen in het begin van het project zijn strategie te komen toelichten. En aan het einde van het testen (of iets eerder) rechtstreeks om zijn advies vragen.
Interessante discussie! In mijn huidige opdracht is mijn collega Albert het overigens eens met Michiel. Ik niet. 🙂
Discussie voortgezet op: http://www.testforum.nl/viewtopic.php?t=9465