Wat maakt een goede tester?
Dit is het tweede deel in een serie van 3 columns. Het centrale thema’s van de columns is “hoe word ik een software test expert?”. Deel 1 kun je hier lezen.
Dat de vraag “wat maakt een goede tester?” de gemoederen bezig houdt, blijkt wel uit de aandacht die dit onderwerp krijgt op verschillende conferenties. Op EuroSTAR gaf Susan Windsor hierover een zeer goed bezochte presentatie. Tijdens de Agile Testing Days kwam een groep gepassioneerde en gerenommeerde agilisten en testers bij elkaar om te praten over diverse test onderwerpen onder het genot van bier en pizza. Na een inventarisatie en een “dot-vote” bleek het onderwerp “Great Testers” de meeste belangstelling te hebben. Dat leverde geweldige input voor deze column, thanks guys!
In dit artikel over talentontwikkeling, persoonlijke kwaliteiten, vaardigheden en competenties zegt Patrick Schriel: “Een vaardigheid is het vermogen om een handeling bekwaam uit te voeren of een probleem juist op te lossen. Competenties zijn kennis en vaardigheden, ze zijn niet aangeboren maar ontstaan door intensief en doelbewust oefenen”. Bij vaardigheden denk ik aan het kunnen toepassen van een bepaalde test techniek, het kunnen werken met bepaalde systemen, etc. Maar voor een tester zijn ook kernkwaliteiten en karaktereigenschappen van belang en deze zijn veel lastiger te trainen. Denk hierbij aan pro-activiteit of creativiteit. Daarnaast is houding (en/of mindset) belangrijk. Hoe sta je tegen over verandering, wat zijn je overtuigingen, hoe open minded ben je?
Houding
Wat maakt een goede tester? Dat hangt af van de context. Ieder project is anders, ieder team heeft zijn eigen dynamiek en iedere test stelt andere eisen. Lisa Crispin zei tijdens de bijeenkomst in Potsdam: “Most important is attitude, we will teach them the skills”. En daar ben ik het helemaal mee eens. Passie voor het vak is wat mij betreft het allerbelangrijkste. In de houding van een tester vind ik ook nieuwsgierigheid erg belangrijk. Of zoals Richard Feynman het zei: “the pleasure of finding things out“. Een tester is altijd op zoek naar informatie: hoe werkt dit? Hij stelt constant vragen om zaken beter te begrijpen. Ik herinner me de volgende quotes uit de rapid software test training: “A testers responsibility is to remain unsure when everybody is sure” en “Testing is about questioning and learning under conditions of fundamental uncertainty”. Een tester weet dat dingen anders kunnen zijn (Jerry Weinberg). En in Potsdam voegde Michael Bolton daar aan toe: “een goede tester is in staat om de complexiteit te zien in dingen die eenvoudig lijken en de eenvoud in dingen die complex lijken”.
Passie
Passie zorgt voor drive, voor inzet en plezier. Volgens mij versterken passie en vaardigheden elkaar: hoe leuker je iets vindt, hoe meer tijd je erin gaat steken, hoe meer oefening, hoe beter je wordt en hoe meer je oefent, hoe beter je wordt. Hoe beter je wordt, hoe makkelijker dingen gaan, hoe meer je ontdekt, hoe leuker het wordt. De sneeuwbal gaat rollen!
Competenties
Een goede tester is proactief en in staat samen te werken en weet dat software ontwikkeling een team sport is. Iets dat je met een team doet en je als tester dus actief op zoek moet naar de samenwerking met je team. Een goede tester weet dat hij nog effectiever wordt als hij samenwerkt met bijvoorbeeld developers. Dat ze elkaar aanvullen en dat een developer hem kan helpen zijn testen sneller en slimmer uit te voeren. Communicatie is daarbij uiteraard belangrijk. Maar wat is communicatie eigenlijk? Michael Bolton deelde in Potsdam zijn lijstje met 27 (!) items die met communicatie te maken hebben: o.a. conversatie, presentatie, argumenteren, visualiseren en retoriek. Daarnaast is ook sociale en emotionele ontwikkeling belangrijk om effectief te werken.
Kennis
Natuurlijk is kennis belangrijk. Maar het vermogen om snel te leren en nieuwsgierigheid, maken dat een tester zich snel kan inleren en daarmee kennis minder belangrijk wordt. Een goede tester heeft (in volgorde van belangrijkheid) kennis van het test vak, technische kennis en domein kennis. Maar houding, vaardigheden en kwaliteiten zijn voor een tester wat mij betreft veel belangrijker! Daarbij had Lasse Koskela het over de “Least qualified implementer” tijdens zijn key-note op de Agile Testing Days. Het principe dat je in een agile team degene met de juiste skills maar de minste kennis het werk laat oppakken om zodoende het hele team zoveel mogelijk op het zelfde niveau te krijgen. Interessant! Daar wil ik meer over gaan lezen.
Bij het werven van testers kijk ik dan ook veel meer naar de persoon: drijfveren, competenties en houding. Kennis is wat mij betreft ook belangrijk, maar is te leren… als die tester maar gretig genoeg is om zijn werk tot een succes te maken.
Het laatste deel van deze serie gaat in op waar en hoe je kennis en ervaring kunt op doen. Deze zal vlak voor het einde van het jaar hier te vinden zijn.
—————————–
Huib Schoots ziet zichzelf als een context-driven tester. Hij is team manager testen bij Rabobank International en bestuurslid van TestNet. Hij is lid van DEWT (Dutch Exploratory Workshop on Testing), student in de Miagi-Do School of Software Testing en houdt een blog bij op www.magnifiant.com
Hi Huub, je twittert dat je een reactie wil. Hier is ie. Waar wil je dat ik het niet mee eens ben? Wat je zegt is redelijk waar en bevat weinig aanstootgevende zaken. In TestGoal voer ik al 10 attitude principes op. Ja attitude is belangrijk. Wat ik echter mis in je column is de attitude om zijn output te alignen met de behoefte van de stakeholders en zijn werk zodanig te presenteren dat zij ook de waarde van de output herkennen. Een belangrijke attitude is om niet alleen het werk goed te willen doen, maar dit ook zichtbaar te laten zijn.
In de voorbeelden die je aanhaalt beperk je de tester tot een fouten zoeker, een ontwikkelaar en een kritische vragensteller. Heel goed, dit is belangrijk. Maar de testen heeft ook een duidelijke taak op de interface met business. Hier horen rapportage en advies bij en zeker niet in de laatste plaats het geven van comfort.
NB. Hierbij ga ik er voor het gemak er even van uit dat onzekerheid vervelender is dan duidelijkheid. Het helder hebben welke problemen er zijn, levert dus comfort op, ook al is de boodschap negatief.
Derk-Jan, waarom zou een artikel/column aanstootgevend moeten zijn of moeten we het oneens om reacties te ontlokken? Jij vult mijn verhaal nu aan en daar ben ik blij mee. Maar ik zal je advies ter harte nemen en in deel 3 proberen te prikkelen om reacties te ontlokken ;-)
Het is zeker niet mijn bedoeling om de tester te beperken tot een fouten zoeker, ontwikkelaar en kritische vragensteller. Dus als dat de boodschap is die je uit mijn verhaal leest, dan moet ik misschien duidelijker zijn alhoewel dat lastig is in een beperkt aantal woorden. Testen is voor mij een product ondezoeken om het te evalueren. Een tester is dus iemand die informatie verschaft over het product. Dit doet hij door van alles over het product te weten te komen (leren!). Het kan dus ook zijn dat hij geen fouten gevonden heeft (ondanks dat we allemaal weten dat ze er op zeker in zullen zitten). Er terwijl ik dit schrijf bedenk ik me dat ik nog een hele belangrijke skill/attitude vergeten ben in mijn verhaal: NADENKEN! Een goede tester denkt na! Systeem denken en Kritisch denken zijn skills die iedere tester zou moeten hebben en moeten trainen.
Ik ben het overigens helemaal eens met jouw aanvullingen. Je output alignen met stakeholders en dit ook zichtbaar laten zijn is een belangrijke skill, gevat onder communicatie. Rapportage, advies en dat wat jij het geven van comfort noemt vallen daar ook wat mij betreft ook onder. Maar dat is een kwestie van definitie.
Huib,
Definities zijn belangrijk. Zo heb ik de indruk dat je “software test expert” en “goede software tester” door elkaar haalt. Een expert weet ergens veel van af, maar is er niet noodzakelijkerwijs heel goed in. Omgekeerd hoeft iemand die ergens heel goed in is niet te weten hoe hij dat precies doet. De titel van reeks columns is misleidend; het lijkt niet te gaan om de vraag hoe je een software test expert wordt, maar om de vraag hoe je een goede software tester wordt.
Ik ben blij dat je in antwoord op Derk-Jan jouw definitie van testen met ons deelt. Als je hierop door filosofeert, durf ik te wedden dat je in deel drie flink wat stof kunt doen opwaaien.
@Bert:
over definities gesproken. Volgens mij is de definitie van expert, deskundige, en deskundig betekend vervolgens weer: bekwaam.
E.e.a. impliceert dus dat een expert wel degelijk goed moet zijn in testen.
Daarom is mijn conclusie dat een goede tester nog geen expert is, maar een expert zeker wel een goede tester.
Daarnaast ben ik het wel met Huib eens dat attitude een belangrijk aspect is. De wil om te leren, de gretigheid. Dat is volgens mij belangrijk om ergens in te slagen. Los van andere aspecten natuurlijk.
Wederom een goed geschreven stuk. Met ook fijne referenties.
Bert, definities zijn gevaarlijk! Daarom praat ik graag over wat we precies bedoelen met een bepaalde term. Vraag 10 willekeurige testers (of nog leuker: doe er een paar developers en beheerders bij) en vraag wat ze bedoelen met een systeem test.
Wat bedoel jij met “software test expert”? En wat is een “goede software tester” voor jou? Voor mij is een expert de overtreffende trap van een goede software tester. Wat jij een test expert noemt, zou ik misschien test consultant noemen. Maar je hebt gelijk: het gaat inderdaad over hoe je een goede software tester wordt.
Via google kwam ik dit tegen, een interessante kijk op experts en consultants.
Maar je antwoord triggert ook een andere gedachte: de expert zoals jij die definieert: iemand die ergens veel van weet, maar er niet noodzakelijkerwijs heel goed in is. Hoe geloofwaardig is deze expert? Ik zou iemand pas een expert noemen als hij ook daadwerkelijk kan laten zien dat hij, dat waar hij over praat ook zelf beheerst. Een expert tester kan wat mij betreft zo achter een stuk software kruipen en het testen. Hoe je dat kan leren, lees je in deel 3.
@Huib: Het zijn jouw columns, dus je mag begrippen definiëren zoals jij wilt. Alleen, als je helemaal geen definities geeft, is het verhaal voor mij moeilijk te volgen. Waar je, volgens mij, niet onderuit komt, als context-driven tester in een TMap-land, is om het vak van software tester opnieuw te definiëren. In antwoord op Derk-Jan zeg je: “Testen is voor mij een product onderzoeken om het te evalueren”. Ik hoop dat je deze definitie in deel 3 verder uitwerkt. Het linkje over de experts en consultants was overigens heel verhelderend ;-)