ORDINA BLOGT

Context Driven Testing

Onlangs heb ik James Bach, bedenker van Context Driven Testing, gehoord over software testing (testnet meeting 18 januari j.l).

  • Otto Luik
  • 24 januari 2012

context-driven-testing

Context Driven Testing

Hij heeft mij op een bijzonder wijze geïnspireerd. Op dit moment ben ik bezig om zijn youtube filmpjes te verslaan. En ik moet zeggen ik word hier erg enthousiast van.
 
James Bach is een mislukte scholier, zegt hij zelf ook in een van zijn filmpjes maar via Apple heeft hij zich toegelegd op het testen van software en hij doet dat op een enthousiaste wijze. Als James Bach in een testteam zit stelt hij zelfs de requirements aan de kaak. Hij gaat niet zo maar testen. Hij heeft bij elk requirement minimaal één maar waarschijnlijk meerdere vragen. Zo is hij tot het Context Driven Testing gekomen. En dat is eigenlijk een natuurlijk gedrag van het software testen. Dat betekent dat een tester niet moet vastzitten in structuren, maar op zoek moet gaan naar de beste manier om iets te testen. Daarbij kan TMap of ISTQB helpen, maar dit is zeker niet heilig. Iedere situatie is anders.

 In één van zijn filmpjes heeft hij het over het vinden van bugs die het nieuws kunnen halen maar nooit en never in een testcase zijn te vangen. Hij noemt dat het onzichtbare deel van testen en daar word je dan een goeroe van voor 300 dollar per uur. James heeft veel van zulke bugs gevonden en doet dat op intuïtieve/natuurlijke manier. Heel veel testers zitten vast in structuren omdat dat van hun verwacht wordt. Als je een testklus hebt dan wordt er van je verwacht dat je een plannetje maakt om te testen en dat je testcases maakt op basis van requirements en dat je aan de hand van deze testcases bugs gaat vinden. Bach noemt dat ‘non expert testing’. De meeste testcases worden niet geschreven en dat is maar goed ook want dan ben je meer bezig met schrijven dan met testen. Hij vindt ook dat veel testers zich niet bewust zijn van hun omgeving. Je bent als tester de laatste deur voordat software naar productie gaat, dus is het een verantwoordelijke bezigheid.

Je kunt immers veel testcases schrijven (let op dit is een middel, geen doel) en toch een paar bugs vinden waarvan anderen zeggen: “Goh, hoe heb je dit gevonden?”. Deze bugs zijn dan niet via de reguliere testcases gevonden en daar word ik dan heel vrolijk van. Wanneer ik een website test dan moet natuurlijk elke button/link doen wat hij moet doen, maar ik ga vooral met exploratory testing te werk op dit gebied. Zo heb ik al vele bugs gevonden die niet in een testcase stonden beschreven.
 
James Bach heeft een drive waarbij hij altijd zoveel informatie aan de ontwikkelaar wil geven zodat de software zo goed mogelijk wordt. En dat zou ook de houding moeten zijn bij ieder andere tester. Ga niet alleen af op requirements/testplannen/testcases enzovoort, het geijkte dus, maar voel je vrij om gevraagd en ongevraagd van alles te testen waarbij jij denkt dat het het team helpt om het software product zo goed mogelijk te laten zijn.
 
Laat je ook inspireren door James Bach

Open Lecture by James Bach on software testing

Becoming a Software Testing Expert

What are some of the Challenges facing Software Quality Testers?