Ben jij dé testspecialist?

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