I had five amazing, insightful volunteers for my demo exploratory testing mob at Testbash Philadelphia. Their open reactions made the experience for me even more worthwhile. In particular I remember when one exclaimed: "Interesting! Oo, I don't like that.", when another said that "I wouldn't write anything down before I know more about the application" and a third confessed that the experience was both fun and exhausting but the chosen style of exploring wouldn't be their chosen style of exploring. Fourth mentioned being unsure of rules and how strictly should those be followed, and the fifth was missing a specification to begin with. The volunteers individual approaches got many participants to approach me later, wondering about the options. What would be the right way to go about exploring the application?
I find that one of the powers of testing in a mob is how it reveals our personal differences and preferences. My volunteers were all from different organizations and locations, with different built-in personal styles. Being different is a strength, helping bring in different perspectives. But to work, on a longer term in particular, in a mob, they would need to build common mechanisms.
They could experiment with different approaches. Let's agree not to write *anything* down for an hour. Let's agree to write only bugs down. Let's agree to only focus on listing functionalities. Let's not touch the application but go look for online documentation of what to expect. All valid approaches.
Working together would create a mix of recipes the group uses to bring in things each feels is relevant, giving chances for the ways of others. They could agree to spend an hour in being mainly navigated within the intent of one, perhaps starting from the one least strongly formed. Instead of choosing one, try all styles. Let the unlikely show its power first.
Within the half an hour of demo, we did not go too deep into letting intent emerge from the group, but I gave the box to play in. We saw it was hard to stay in the box, that problems all around the application made it even harder.
So what would be the right way to start? My one rule is variance. Do it different every time if that is possible to maximize your chances of serendipity. What goes first determines what can come second, and the varied order of things helps you think in different dimensions. It's not just one way, but whatever you do first already changes the state of your knowledge.
Your choice, explorer. Just realize the choice exists.
I find that one of the powers of testing in a mob is how it reveals our personal differences and preferences. My volunteers were all from different organizations and locations, with different built-in personal styles. Being different is a strength, helping bring in different perspectives. But to work, on a longer term in particular, in a mob, they would need to build common mechanisms.
They could experiment with different approaches. Let's agree not to write *anything* down for an hour. Let's agree to write only bugs down. Let's agree to only focus on listing functionalities. Let's not touch the application but go look for online documentation of what to expect. All valid approaches.
Working together would create a mix of recipes the group uses to bring in things each feels is relevant, giving chances for the ways of others. They could agree to spend an hour in being mainly navigated within the intent of one, perhaps starting from the one least strongly formed. Instead of choosing one, try all styles. Let the unlikely show its power first.
Within the half an hour of demo, we did not go too deep into letting intent emerge from the group, but I gave the box to play in. We saw it was hard to stay in the box, that problems all around the application made it even harder.
So what would be the right way to start? My one rule is variance. Do it different every time if that is possible to maximize your chances of serendipity. What goes first determines what can come second, and the varied order of things helps you think in different dimensions. It's not just one way, but whatever you do first already changes the state of your knowledge.
Your choice, explorer. Just realize the choice exists.
