Testconferentie Eurostar 2008 (dag 1)
Deze week ben ik mijn kennis op het gebied van testen aan het uitbreiden. Er is namelijk een Europese testconferentie in Nederland. Elk jaar wordt deze conferentie, met de naam Eurostar, ergens in Europa georganiseerd. Dit jaar is de conferentie in Den Haag.
De eerste dag werden er verschillende workshops aangeboden. De keuze was voor mij snel gemaakt. Ik heb een workshop bijgewoond over Exploritory testing. De reden was eenvoudig. Bij Finalist probeer ik zoveel mogelijk de test tot in detail voor te bereiden. Ik bepaal van tevoren wat ik wil testen en ik schrijf in een testscript zo gedetailleerd mogelijk op hoe er getest moet worden. Dit bespaart tijd in de uitvoering en maakt het overdragen van het testen een stuk eenvoudiger. Maar op deze wijze werken is niet altijd mogelijk. Door veranderingen tijdens het ontwikkelproces en bijvoorbeeld de Agile methoden moet de voorbereiding vaak overnieuw gedaan worden bij de testuitvoering.
Exploritory testing is een manier van testen waarbij er niet of nauwelijks sprake is van voorbereiding. Maar het is zeker niet de bedoeling dat er lukraak getest wordt. Een eis bij Exploritory Testing is, dat je het testen gestructureerd blijft aanpakken. Om dit te doen maak je gebruik van je eigen ervaring en de testkennis die je tot je beschikking hebt. Eigenlijk kan je zeggen dat je de voorbereiding en de uitvoering tegelijkertijd doet.
De workshop werd gegeven door James Whittaker, werkzaam bij Microsoft. Hij probeerde ons te leren hoe je Exploritory testing goed aan kunt pakken. In het kort komt het hierop neer: om te bepalen wat je gaat testen, maak je gebruik van alle kennis en informatie die beschikbaar is over de applicatie. Ten eerste gebruik je alle teksten die de applicatie of een deel daarvan beschrijven. Hierbij kan je denken aan handleidingen, blogs over de applicatie geschreven door gebruikers, maar ook b.v. handleidingen van concurrerende producten. Ten tweede maak je gebruik van manieren van “testrondleidingen” die in het verleden hebben bewezen dat ze bugs in de applicatie kunnen vinden. Deze laatste groep breid je steeds verder uit door naar bugs uit het verleden te kijken en te bedenken hoe je deze via een “testrondleiding” had kunnen vinden.
Maar wat is een “testrondleiding”? Dit is de focus die je hebt als je, met behulp van de beschikbare informatie, de applicatie test. Op basis van de beschikbare informatie bepaal je waar je gaat testen en welke handelingen je in grote lijnen gaat uitvoeren, zodat dit een testscenario wordt. Een voorbeeld hiervan is “Kies een boek en betaal deze met je creditcard”. Maar tijdens het doorlopen van dit scenario let je maar op één ding. Denk hierbij aan “Herhaal elke actie die je uitvoert twee keer” of “Probeer zo weinig mogelijk handelingen uit te voeren om het scenario te doorlopen”. Dit samen wordt een testrondleiding die elke tester kan uitvoeren. Het doel is om hiermee Exploritory testing wat meer structuur te geven, zodat in de toekomst deze manier van testen ook te leren is en testers meer dezelfde bugs gaan vinden. Of dit gaat lukken, moet de toekomst nog uitwijzen, want de methode was nog in experimentele fase.
Meer informatie over Eurostar: http://www.qualtechconferences.com/content.asp?id=91
I was also in the tutorial. Aside: I used google’s translate function to read your post - apologies that I can only reply in English.
Exploratory testing is a broad discipline - most testers explore their systems in some way, but (in my experience) many limit their exploration because they don’t share their skills. I expect that for lots of testers, James’ ‘tours’ will be a great way to help testers explore - they provide a good metaphor, clear but minimal guidance, and allow a range of approaches to be considered (before and during exploration). I hope that they will also allow testers to discuss their approaches and discover viable techniques that they might have otherwise ignored.
There are lots of other exploratory approaches. This was James’ first public class in explicitly exploratory techniques (although his “How to Break…” tutorials certainly covered similar ground). You’ll also find classes from Michael Bolton/James Bach, Elisabeth Hendrickson, and me - each is different (although we’ve all shared a handful of materials and exercises), each valuable, each covers techniques that are experimental by their nature, but also mature in the way that they are done. One common difference from James’ class is that participants learn by doing some testing, rather than by watching movies of people testing.
[Blatant advert: I’ve got a public class in Exploratory Testing (hands-on, no frills) in London Dec 8-9. http://www.workroom-productions.com/ET_20081208.html ]
Although exploratory testing is experimental by nature, its use on projects is both mature and documented. If you give a group of testers the same thing to test, and similar instructions about how to test it (and if you give them plenty of time) then typically you will find that many of the same bugs are reported. There is, after all, only a finite number of bugs to find (although the total possible set of tests may be infinite).
In commercial environments, one does not have the luxury of time, and will also want to give feedback as swiftly as possible. Furthermore, with exploration one is less concerned with demonstrating that different testers find the same bugs than one is interested in finding plenty of bugs - and that those bugs should be diverse. An approach that allowed the same bugs to be found over and over again would be an inefficient approach. Unfortunately, in some teams, scripts are used not to show that a system works (at which scripts excel), but to find bugs. In these circumstances, exploratory testing is often resisted - but it is in these environments (as James described) where it pays the greatest dividends.
James Lyndsay - november 27, 2008 13:47