Er bestaat niet zoiets als de perfecte software tester!

De perfecte software tester bestaat niet. 

Verschillende mensen zijn goed in verschillende dingen.
Stel men neme 2 personen. 
​
Deze personen geven we gedurende 1 jaar lang de opdracht op zich ergens in te verdiepen. Persoon A geven we de taak om zo veel mogelijk kennis op te doen gedurende 12 maanden over schaken.
De andere persoon geven we de opdracht om gedurende een jaar lang zo goed mogelijk zich bezig te houden met hardlopen.

---

Iedereen begrijpt dan dat Persoon A beter zal worden in schaken. Persoon B zal beter worden in hardlopen.

Zo is het ook met software testen. Als je je bezig houdt met testen middels tooling. Zul je een andere mindset krijgen dan als je de testen uitvoert zonder tooling. Dit is logisch, want in de tijd dat je de tooling werkende probeert te krijgen, kun je ook bezig zijn om extensiever en uitputtelijker de website door te testen. Door de ervaringen die je opdoet krijg je aan beide kanten een andere soort mindset en kennis.

Het verschil wordt ook wel eens aangegeven als een technische tester en een functionele tester. De functionele tester houdt zich wat meer bezig met de juistheid, compleetheid, ondubbelzinnigheid van de requirements. Ook praat hij wat meer met de business over de wensen van de klant. Hij past testtechnieken toe op de requirements van User Stories om ervoor te zorgen dat alle mogelijke scenario's netjes in beeld worden gebracht in bijvoorbeeld een Excelsheet of in het manuele deel van een tool (zoals Tosca dat netjes heeft).

Wil je als bedrijf je testproces goed op orde hebben?
Laat dan de functionele testers en de technische testers goed samenwerken. Met deze twee inzichten vormen ze gezamenlijk namelijk de sleutel tot succes.

Wil je het nog beter geregeld hebben? 
Dat kan... laat dan de functionele tester op de items van het Jira board het voorwerk doen. Zodra requirements beter gespecificeerd zijn (daar helpt hij dan bij) en de eerste testen op de front-end gedaan. Dan kunnen de functionele testers de input aan de automatiseerders geven... De automatiseerder wordt dan niet belast met vage specificaties, maar kan lekker doorwerken omdat zaken al helder zijn gemaakt.

Bijvoorbeeld : De waarde 9999 voor het numerieke invoerveld geeft betere zekerheid/informatie dan de waarde 9.

of
eerst scenario 3 testen en dan scenario 1 is een logischere volgorde van testen.
of
Er treden vaak fouten op als.... en het is goed om daar een automatische test voor te schrijven...
of
...

Stopt de functionele tester dan met testen? Nee, hij werkt wel samen met de technische tester. Manueel en automatisch kunnen altijd naast elkaar blijven doorgaan. Maar belangrijk is dat de functionele tester niet te diep in de code/techniek gaat, omdat anders zijn objectiviteit beïnvloed kan worden en dat is juist niet de bedoeling! 

Bij een goed lopend testproces gaat het ongeveer zo:
F: Ik kan deze bug op basis van de testen op de front-end niet verklaren, kun jij even met mij meekijken? Is het een goed idee om hiervoor een automatische test te schrijven?

T: Ik ben met repareren van de automatische testen bezig, kun jij kijken of de specificaties van het volgende item helder zijn en alvast wat testscenario's (paden, beslistabel, etc) uitwerken en testen op de nieuwste build?