Beschouw je jezelf als een goede tester, of nog iets meer dan dat? Iemand die zichzelf op testvakgebied constant probeert te verbeteren, elke dag weer te leren? Deel je het geleerde met anderen via artikelen, blogs, geef je presentaties of workshops? Ben jij dé testspecialist van Nederland?
Uit wat voor soort testers bestaat ons vakgebied nu eigenlijk? Ik noem er een paar.
De tijdelijke tester
Nog heel vaak wordt het beroep van tester als een springplank gezien naar een andere functie. Wil je leren programmeren of hoe je goede functionele en technische ontwerpen kan maken? Begin eerst een jaartje als tester, dan kan je alvast oefenen. Uiteindelijk kan je doorgroeien naar je eigen specialisme.
Vreemd eigenlijk, want de gedachte wereld en het perspectief van een tester op het gebied van IT ligt in principe op een heel ander gebied. Risico’s identificeren, onderzoekend bezig zijn en als ontdekkingsreiziger aan de slag om de juiste bugs te vinden. Dit is voor elk beroep binnen de IT wel van belang, maar is onderdeel van de ‘primaire levensbehoefte’ van een tester.
Als je testen als een tijdelijke baan ziet, verlies je de focus op zaken waar het echt om gaat bij het testen, je bent immers bezig met je eigen einddoel.
De domeinspecialist
Als je een domeinspecialist bent, ben je dan ook tester? Schrijf je testplannen, voer je testen uit, maak je testrapportages en voer je verbeteringen uit op je testprocessen na evaluaties? Kortom: ken je de testwereld, testmethodieken en doe je hier wat mee, of ben je in het testen gerold en voer je de benodigde testen uit via ‘logisch denken’?
Is het wel nodig om als tester veel domeinkennis te hebben als je ergens komt te werken? Misschien is de eigenschap om ‘snel de stof eigen te maken’ wel belangrijker?
De tester die voor 100% test coverage gaat
100% testcoverage? Wat betekent dat eigenlijk? Vaak wordt aangenomen dat dit de dekking van de testen is over de code. Het kan betekenen: “Alle beslispunten zijn verwerkt in testgevallen die uitgevoerd worden tijdens testuitvoer”. Maar het kan ook betekenen:”Alle risico’s die benoemd zijn voor dit product zijn minimaal afgedekt met een goed en een foutpad.”
100% testcoverage is een loze kreet als het zonder uitleg wordt genoemd. Stel je voor dat je 100% van de code zou willen raken met je testen. In de dagelijkse realiteit krijg je geen tijd om alles af te kunnen dekken, maar gaat het er meer om het afdekken van de juiste risico’s. Dit kan net zo goed 90%, 50% of 10% testcoverage zijn van de code.
De testautomatiseerder
Als je bezig bent met het automatiseren van tests met behulp van testtools en hier al ver mee komt is dat een behoorlijk stap in de richting van wat we al een tijdje proberen in de testwereld. Het uitvoeren van testen blijft echter een creatief proces waar je constant mee bezig bent om afwijkende situaties te herkennen. Dit is niet af te vangen met een automatische testscript. Zo lang je dat realiseert en automatisch testen combineert met handmatige tests dan zit je in de goede richting. Te vaak wordt er vertrouwd op geautomatiseerde tests die gemaakt zijn in het verleden en vervolgens die nieuwe bugs niet ontdekken.
Heb je overigens ook bedacht dat applicaties zoals Kladblok, Excel, Calculator, e-mail en nog veel meer ‘gewone’ kantoor automatisering producten ook als testtool gebruikt kunnen worden? Deze kunnen gebruikt worden om delen van je testuitvoer te automatiseren, in plaats van te streven naar een zo hoog mogelijke dekking via alleen automatische testscripts.
De gecertificeerde tester
Als je gecertificeerd bent in TMap, ISTQB of anders, ben je dan vervolgens een goede tester? Je zou eerder kunnen zeggen dat je dan goed lijstjes uit je hoofd kan leren. Dit geldt zeker voor de foundation (basis) certificaten. Voor de advanced certificaten moet je wat meer moeite doen. Maar ben je dan een goede tester? Ik weet het eerlijk gezegd niet. Het toont wat mij betreft wel je motivatie om meer te willen leren over testen.
Alleen met het behalen van certificatien kom je er niet in het testvakgebied, lees blogs, artikelen, andere boeken over testen, discussieer op testevenementen en via fora op het internet.
Testen is complexer dan veel mensen denken.
Niet veel mensen realiseren zich dat de leercurve eigenlijk wel hoog is voor het testvakgebied. Op school wordt het vak “testen” niet of heel beperkt gegeven en het lezen van TMap garandeert ook niet dat je een top tester wordt. Om de juiste skills te leren komt er meer bij kijken. Hier een blog van Peter Schrijver met interessante links om je een idee te geven.
Gelukkig wordt de professionaliteit en ook de complexiteit van testen en het testvak steeds meer onderkend in de IT.
Echter, kreten zoals 100% testdekking, volledig automatiseren van de tests en vertrouwen op officiële certificaten die gehaald zijn door testers willen nog wel eens verkeerd uitpakken en de reputatie en vertrouwen in testen omlaag brengen. Er zijn nog steeds testers die testen beschouwen als “gewoon logisch nadenken” en dit ook ventileren. Als wij als testers dit zo communiceren zal de rest van de IT wereld ons ook niet serieus nemen. We moeten onze professionaliteit uitdragen naar andere IT’ers.
Een klein voorbeeld hiervan
Heb je een antwoord op de simpele vraag: “Hoe heb je deze bevindingen gevonden?” Kan je dit uitleggen of is je antwoord vaak: “Gewoon tegen aan gelopen?”. Dit antwoord geeft niet veel vertrouwen voor degene die de vraag stelde. Er is altijd een oorzaak hoe je een bevinding hebt gevonden. Een paar voorbeelden:
- “Ik heb de functionaliteit vergeleken met de technische ontwerpen en het wijkt af van de specificaties.”
- “In het gebruik van de software kreeg ik een onlogische reactie van de software die ik niet verwachtte”
- “De software vertoont ander gedrag dan… (gisteren, vorige week, uurtje geleden)”
- “Als je deze functionaliteit software vergelijkt met een vergelijkbaar product van onze concurrent, dan werkt het compleet anders. Is dat de bedoeling?”
- “Het product gedraagt zich anders dan de organisatie wil uitstralen.” (Bijvoorbeeld green IT als image, maar het product zorgt ervoor dat de monitor en PC niet uitgaan na x minuten, zoals de bedoeling is.)
Weet wat je doet en zorg voor een goede onderbouwing
Als je er niet zeker van bent hoe je bepaalde bevindingen hebt gevonden. Of je bent er niet zeker van wat je wel en niet moet testen in je testproject (alles testen lukt niet), hoe vertel je dit dan aan je organisatie.
Misschien heb je tot nu toe veel bevindingen gevonden door “logisch na te denken” en omdat je veel kennis hebt van het domein waar je nu in zit helpt dit goed. Wat als je een andere opdracht krijgt waar je niet zoveel kennis van het domein hebt? Dan zal je toch anders om moeten gaan met je aanpak.
Hoe zeker ben je van je zaak dat je bij een volgende opdracht of organisatie ook nog `de testspecialist´ bent?
——————————————
Rob van Steenbergen is een onafhankelijke softwaretester en een actief blogger
Chickenwings Test Consultancy
In mijn ogen voldoet een goede testspecialist aan een aantal criteria. Ten eerste is analytisch vermogen een vereiste. Daarnaast spelen ook creativiteit en communicatieve vaardigheden /charisma een grote rol. Alle overige zaken zijn aan te leren door een combinatie van praktijkervaring en certificeringen/trainingen. Goede begeleiding is hierbij essentieel. Ikzelf reserveer altijd tijd voor het gedegen opleiden van juniors in mijn teams. Dat kost enige tijd, maar op die manier bind je hen aan het team, het bedrijf en kunnen zij na een relatief korte periode van 3 maanden zelfsttandig aan de slag in een medior testfunctie. Op dat moment plukt het bedrijf er de vruchten van.
Een goede tester:
- heeft kennis van/ervaring met programmeren
- weet zonder uitgebreide analyse a.d.h.v. zijn fingerspitzengefühl aan te geven waar de risico’s liggen
- weet ook met error guessing en exploratory testing de zwakke plekken van een systeem te vinden
- hanteert op de juiste plek, de juiste testtechniek
- doet niet mee aan vingerwijzen, maar is oplossingsgericht
Interessant artikel Rob! Vrijwel helemaal in lijn met mijn ideeën over ons vak. Beschouw je jezelf als een goede tester, of nog iets meer dan dat? Ik heb er recent een blog overgeschreven en een presentatie over gegeven met de titel: “So you think you can test?”. In mijn blog schrijf ik dat je een betere tester kunt worden door 3 dingen te doen: 1) pas je aan de context aan 2) werk samen 3) oefen & leer. Ik denk dat dé testspecialist van Nederland niet bestaat.
De tijdelijke tester vind ik een leuk onderwerp en ik draai het liever om. Ik vind testen zeker geen opstap naar andere rollen, het is eerder andersom! Om een goede tester te kunnen zijn, zou je eerst ervaring op moeten doen als programmeur en ontwerper. In mijn blog roep ik dat we meer moeten samenwerken. En om samen te werken, moeten we beter snappen wat onze teamgenoten doen. Dus kennis (of in ieder geval grote interesse) van het werk dat zij doen, lijkt me dan wenselijk. Wederzijds begrip zou ideaal zijn!
De discussie over testkennis vs. domein kennis vat je goed samen in de conclusie: de eigenschap om je snel de stof eigen te maken, is belangrijk! Maar ook hier: het hangt af van de context. Ik denk dat vaak een combi in je team, dus iemand met testkennis en iemand met domeinkennis, goed werkt. Een goede tester is nieuwsgierig, wil dingen snappen, wil dingen ontdekken. Of zoals James Bach & Michael Bolton dat zei in de Rapid Software Test training: “take pleasure in finding this out!”.
Ik denk niet dat je een goede tester bent als je een (advanced) certificaat hebt. Het zegt wat mij betreft ook niets over je motivatie. Zeker niet als je het certificaat kan (of erger nog: moet) halen in de baas zijn tijd… Ik denk dat certificaten niet per definitie slecht zijn, maar zeker geen zegen zijn voor ons vak. Het geeft een hoop schijnzekerheid die helaas door de hele markt in stand gehouden wordt. De grote bedrijven (laten we die even voor het gemak de vraagkant noemen) hebben moeite met selecteren van de juiste externe inhuur en dus kijkt men naar certificaten, dat selecteert gemakkelijker. De aanbod kant doet maar al te graag mee met de certificerings hype. Omdat ze daar zelf aan verdienen door het geven van trainingen, maar ook vanuit een commercieel belang omdat de vraagkant het vaak eist.
Certificering zegt maar heel weinig over een tester. Ik ken genoeg testers met certificaten die ik nooit zou inhuren en/of zou aannemen. Waarom niet? Omdat het geen goede testers zijn, maar ook omdat zij niet de tester zijn die ik (op dat moment) zoek. Ook het geschikt zijn van een tester hangt af van de context. Bij mijn vorige werkgever (een detacheerder van testers) zocht ik andere mensen dan bij mijn huidge werkgever (een bank). Zelfs per project kan dat heel anders zijn!
Dus een lijstje met eigenschappen die een tester zou moeten hebben, is lastig te maken omdat het per situatie verschilt. Het hangt af van de context. Mijn lijstje van 3 hanteer ik zelf graag als uitgangspunt. En om effectief samen te werken moet je natuurlijk beschikken over communicatieve vaardigheden en charisma. Analytisch vermogen is handig als je wil leren en snel dingen wil snappen en doorgronden. Creativiteit past in het aanpassen aan de context.
Het allerbelangrijkste van een tester, maar dat geldt voor iedere professional: van toiletjuffrouw tot directeur, is de drive om een goede tester te willen zijn. Dus blijf voortdurend leren! Vraag regelmatig feedback en evalueer alles wat je doet. Vraag je constant af: wat kan ik de volgende keer beter doen?