Tegenwoordig is er heel veel te lezen omtrent 'Software-testen'. Als tester wordt je overspoeld met informatie hierover. Zo zijn er verschillende boeken, tijdschriften, trainingen, cursussen en nog veel meer zaken die je kunt aanschaffen om je als professionele tester te profileren. Helaas staat niet overal hetzelfde, maar goed de informatie is er. Ben je nou een goede tester als je hierin meegaat?
Kun je zeggen dat je een ervaren tester bent als je veel van deze boeken en tijdschriften leest? Ik vind van wel. Het is belangrijk om te weten wat er speelt op het gebied van testen en wanneer je een certificaat hebt gehaald omtrent testen mag je jezelf een gecertificeerde tester noemen.
Wat moet ik nu geloven? Welke teststrategie moet ik kiezen? Zo zijn er verschillende definities terug te vinden over het testen, welke testtechnieken en testvormen er zijn, en uit welke verschillende testtools je kunt kiezen. Door alle informatie die er tegenwoordig is, kan het erg complex voor een tester zijn om een bepaalde teststrategie aan te houden en daarin mee te gaan. Een tester kan gaan twijfelen of zijn werk wel goed wordt uitgevoerd. Natuurlijk is het belangrijk om vooraf testcases te hebben en dan te gaan testen. En natuurlijk is het belangrijk om rekening te houden met de planning, maar moeten we nu echt gaan testen aan de hand van een willekeurige testaanpak? En zijn de bevindingen die een tester nu constateert, daadwerkelijk terechte bevindingen? Heeft de tester niet toevallig een stap uit zijn testcase overgeslagen of verkeerd uitgevoerd? En heeft een tester altijd gelijk?
Dit is een onderwerp waar men moeilijk antwoord op kan geven. We zijn immers allemaal mensen en iedereen kan wel iets over het hoofd zien en daardoor fouten maken. Hoe vaak komt het niet voor dat wanneer men begint met het uitvoeren van de eerste testcase het al fout gaat en de eerste bevindingen worden geconstateerd. Dit is erg frusterend voor een tester, waarbij hij negatief gaat denken over de kwaliteit.
Er is altijd een strijd gaande tussen de tester en de ontwikkelaar. Hoe ga je hier nou mee om? Wie heeft er gelijk? Ik kan uit ervaring spreken dat een tester, een ontwikkelaar altijd moet respecteren en te vriend moet houden. Iedereen kan tenslotte fouten maken.
Een ontwikkelaar programmeert aan de hand van de gegeven informatie. Dit kan een functioneel ontwerp, use cases, of zelfs mondeling toegezegd zijn. Het is goed om in het testproces elkaar beter te leren kennen en mocht een tester tegen een bevinding aanlopen, dan dient dit op een nette manier te worden teruggekoppeld aan de ontwikkelaar. Heeft de ontwikkelaar iets over het hoofd gezien, heeft hij een andere versie van het functioneel ontwerp. Zo zijn er tal van verschillende redenaties die er toe kunnen leiden dat een ontwikkelaar een bevinding over het hoofd heeft gezien.
Het kan ook zijn dat datgene wat de tester heeft geconstateerd geen terechte bevinding is. Ben je dan een slechte tester? Nee, want een tester test aan de hand van de beschikbare informatie. Dit kunnen testcases zijn die afgeleid zijn van bijvoorbeeld het functioneel ontwerp of van user cases. Is het geen fout in de programmatuur dan kan het een wens of verbetering zijn. Dit is de ontwikkelaar dan natuurlijk niet aan te rekenen. Het is de taak van de tester om alle onderdelen grondig te testen om zo wat te kunnen zeggen over de kwaliteit.
Naar mijn mening heeft een goede tester in de meeste gevallen gelijk. Het is aan de tester om dit goed en netjes terug te koppelen aan de ontwikkelaar om hier de volgende keer op te letten. Is het geen fout dan kan het een wens zijn van de tester. Met een goede onderbouwing aan de testmanager zal een wens van de tester ook opgelost worden.
Beste Brahim,
Op sommige punten ben ik het wel met je eens. Maar een goede tester vindt alleen terechte bevindingen. Daar kan geen discussie over mogelijk zijn.
Ervaring krijg je niet door boeken te lezen en cursussen te volgen.
Een ervaren tester wordt je alleen door praktijkervaring op te doen.
En hoe kom je erbij dat er altijd een strijd is tussen testers en ontwikkelaars?
Ik kom gelukkig vaak ontwikkelaars tegen die testers zien als iemand die ze helpt een zo goed mogelijk product op te leveren aan de klant.
ik onderschrijf de punten van itk_13702.
Het is vaak zo dat de ontwikkelaars en testers een andere kijk hebben op de zaken, maar dat is -zoals de schrijver zelf ook onderkent- vaak het gevolg van verschillende basisdocumenten (dat zegt eerder iets over het configuratiemanagement in kwestie). Maar zelfs ook als dezelfde documentatie wordt gebruikt kunnen er verschillen ontstaan (interpretatie door verschillen in kijk op de zaken of (on)machtigheid van de taal waarin het document geschreven is). Maar is niet ALTIJD een strijd.
Waar je vaak mee te maken hebt is een situatie waarbij beide partijen worden geconfronteerd met een ‘fait accompli’: de tester wordt er pas bij betrokken als de ontwikkelaar bijna klaar is. Dat geeft de tester een achterstand voor wat betreft de historie, de keuzes die gemaakt zijn en de alternatieven die al zijn afgewogen (en afgewezen en de redenen waarom, etc.). Wederom een kwestie van juist proces-management: betrek de partijen zo vroeg mogelijk bij het project (de tester hoeft in het begin niet zoveel te doen, maar kan in elk geval zien en horen wat er speelt).
Kortom… het mocht wel iets genuanceerder worden gebracht.
Ook mijn ervaring m.b.t. de strijd is (gelukkig) anders. Zowel tester als ontwikkelaar werken uiteindelijk vanuit dezelfde specificaties. Het kan dan wel eens handig zijn als je samen een vuist kunt maken tegen degene die de specs gemaakt heeft.
Een strijd die ik zo af en toe wel eens zie is die tussen tester en projectmanager. De tester heeft meestal meer tijd nodig dan de projectmanager beschikbaar wil stellen (moet je dat nu echt allemaal testen) of zelfs het verzoek om geen problem reports meer in te dienen, omdat het project anders nooit afkomt….
Overigens ben ik het niet helemaal eens met de stelling dat de tester na zijn werk iets kan zeggen over de kwaliteit. Dit heeft overigens niets te maken met de tester. De tester test bepaalde functionaliteit af, gebaseerd op wat gespecificeerd is.
Maar als de spec voorschrijven dat je iets met slechte kwaliteit moet maken, dan heeft de tester zijn werk goed gedaan, terwijl er toch slechte kwaliteit uitkomt.
Simpel voorbeeld:
Zowel de Tata nano (de $2000 auto uit India) als de nieuwste mercedes 500 SEC zijn allebei getest en goed bevonden. Maar er zit aardig wat verschil in kwaliteit tussen die twee……..
Kwaliteit is de mate waarin een product of dienst voldoet aan de verwachtingen en is afhankelijk van het gebruik. Zo zal de Tata Nano voor gebruik in smalle drukke straatjes kwalitatief beter zijn.
“Met een goede onderbouwing aan de testmanager zal een wens van de tester ook opgelost worden.”
Sinds wanneer bepaalt de tester wat er wel of niet gebouwd moet worden. Dat bepaald de Business!!
Ik heb wel eens ooit voor een project acceptatie testen moeten doorlichten. verbazing wekkend wat je dan soms tegen komt.
Hoe kun je een vliegtuig met een van de motoren uitgeschakeld op 300000 Ft (Fl300) laten vliegen als dat ding dat met beide motoren niet eens kan.
En als op die hoogte een temp van 30’C heerst hoe heet moet het dan op de grond zijn ? Iemand die zulke test specs opsteld heeft het niet helemaal begrepen.
Dan mag je als tester en techneut best eens samen aan de bel trekken.
@PaVaKa hoezo ?… is de Tata Nano dan beter ?
Wat ik nog mis in dit verhaal is de kennis van de tester m.b.t. de gebruikte ontwikkel omgeving en het inzicht in programmeren. Daarnaast is het meestal zo dat de tester meer kennis heeft van de klant omgevingen, en dus terecht opmerkingen kan maken over de functionaliteit. Maar het kan niet zo zijn dat een tester zijn mening niet zou mogen geven over functionaliteit. Het is van groot belang dat een tester goed kan communiceren met een programmeur cq ontwerper.
Brahim,
Gezien de reacties,
ik denk dat je nog wel even te gaan hebt voordat je dit soort onderwerpen aan kunt kaarten.
Leuk stukje opinie en relevant genoeg gezien de reacties.
@Brahim, je moet nog wel even je camera testen, je foto blijft vaag! 🙂
On Topic: Niemand houdt van testers! De klant niet, want testen is duur. De projectmanager niet, want het kost teveel tijd. De programmeur niet, want het programmeren was leuk, dat moeras om het af te maken niet.
Betekent dit dat we testers maar moeten afschaffen? Absoluut niet. Zoals een editor een boek beter maakt, voegt een tester kwaliteit toe. De tester behoedt velen voor blunders, hacks en imagoschade.
Ik ben dus heel blij dat er testers zijn en groot respect voor hun inzet en scherpte. Wat ik me altijd afvraag: waarom kiezen mensen ervoor om tester te worden? Uit soort masochistische overwegingen? Het lijkt me vrij ondankbaar werk gezien bovenstaande. Daarnaast bouw je ook niets, en grote eer valt er zelden te behalen.
Testers hebben in mijn ogen dus altijd iets mysterieus 🙂