Ervaren testers: leer van basisschoolkinderen!

Auteur: Rik Marselis ● Rik@Marselis.eu ● @rikmarselis

Als je iets vaak doet, word je er steeds beter in. Je leert handigheidjes en vuistregels. Maar ook krijg je wel eens de neiging om slordig of minder effectief te worden. Omdat je misschien het zicht op de exacte doelen bent verloren.

Exploratory testen
Ik mag al jaren regelmatig workshops Exploratory Testing geven, zowel aan ervaren testers als aan nieuwelingen. Het is een workshop, dus de nadruk ligt op praktijkoefeningen, ga maar eens daadwerkelijk testen. Daarbij is mij een patroon opgevallen in het gedrag van ervaren testers.

Patronen
Om dit patroon toe te lichten eerst even een beschrijving van het doel van testen. Dertig jaar geleden was het doel van testen simpel ‘zoek de fouten zodat de ontwikkelaars die op kunnen lossen’. Sinds een jaar of vijftien weet iedereen wel dat het gaat om ‘inzicht geven in kwaliteit en risico’s’. En sinds een jaar of vijf ligt de nadruk vooral op het onderbouwen van ‘Vertrouwen’. Want soms heeft de product owner het vertrouwen dat ondanks enorme risico’s de business case gehaald zal worden en dan besluit zij dus live te gaan hoewel er nog bevindingen zijn waar testers buikpijn van krijgen.

Workshops
Tijdens de workshops zie ik dat ervaren testers bijna zonder uitzondering als eerste de meest extreme gevallen gaan testen. Ik leg bijvoorbeeld uit dat het systeem verschillend moet reageren op blauw of rood. En dan gaan zij als eerste paars proberen.
Vanuit het oorspronkelijke idee van ‘zoek de fouten’ snap ik dat nog wel, de kans dat het in extreme gevallen fout gaat, is groter dan dat standaard functies falen. Maar vanuit het schenken van vertrouwen is dit niet de juiste aanpak. Dan zul je toch eerst gewoon even moeten checken of rood en blauw correct werken.

Leren van kinderen
In dit opzicht kunnen ervaren testers leren van basisschoolkinderen. Want toen ik dezelfde workshop een keer met kinderen tussen tien en twaalf jaar mocht doen (leuke doelgroep hoor!!), bleek dat die kinderen gewoon beginnen met proberen of de basisfunctionaliteit werkt. En pas daarna gaan ze onderzoeken wat er in rare gevallen gebeurt. Tot slot bleken ze uitstekend in staat om samen te vatten hoe het zat met kwaliteit en risico’s. Zodat de product owner kon beredeneren of zij voldoende vertrouwen in de applicatie had.

Ga onderzoeken
Kortom, ervaren testers, neem het gedrag van basisschoolkinderen over, begin met het onderzoeken van de kernfunctionaliteit en verdiep je daarna pas in bijzondere gevallen, uitzonderingen en de ‘leuke situaties’.

Veel plezier en succes met het mooie testvak!

Rik Marselis

rik@marselis.eu

3 comments on “Ervaren testers: leer van basisschoolkinderen!
  1. Rob van Steenbergen schreef:

    Het eerste risico dat opkomt zou altijd moeten zijn: “Wat gebouwd is werkt niet zoals we verwachten”. In de meeste gevallen verwacht ik dat dit acceptatiecriteria is beschreven. En in veel gevallen zie ik zelf gebeuren dat dat het enige is wat getest wordt. Dat is dan weer het andere extreme.

    Maar gelijk duiken op uitzonderingen en randgevallen is inderdaad een bias op zich. Bij Exploratory Testing beginnen met de “sanity test”, werkt het beste. Werkt wat gebouwd is en reageert de software verder nog steeds zoals verwacht.

    Die eerste check hoeft geen uren te duren, en het helpt bij het ‘bekend worden’ met de functionaliteit. Simpel beginnen en dan diepte in, inderdaad.

    Volgens mij is dat een natuurwet om ‘complexere’ zaken te begrijpen en betere analyses te kunnen maken.

  2. Robin schreef:

    Een interessante observatie, dat zeker…maar ik denk toch ook “Als ik (als er iets opgeleverd wordt) nog moet gaan testen of de basis happy flow wel goed werkt, moeten we dan als team niet stoppen met ontwikkelen?”. Randvoorwaarde voor oplevering moet wat mij betreft zijn “de developers steken hun handen ervoor in het vuur”…als we daar vanuit gaan, levert kijken of rood en blauw werken als verwacht dan wel de meeste toegevoegde waarde?

    • Krispijn schreef:

      Je beschrijft een aanname: de developers vertrouwen erop dat het werkt. Volgens mij is het werk van de tester juist om deze aanname te toetsen. Daar hoort dus ook de Happy Flow bij. Mijn tests starten vanuit de basis zo simpel zoals de beschreven tests: Werkt rood? Werkt blauw? En inderdaad, 9 van de 10 gaan goed, maar er blijft altijd nog dat 10e geval over…

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *