CEWT (Cambridge Exploratory Workshop on Testing) is an exploratory peer workshop. We take the view that discussions are more interesting than lectures. We enjoy diverse ideas, and limit some activities in order to work with more ideas.
We were six attendees whom most I met at previous Software Tester Meetups in Cambridge. This includes the organiser, James Thomas, test manager at Linguamatics, who hosted the event. The topic was “Testing ideas”, purposefully ambiguous, and it turned out to be a real inspiring one. We all presented a quick talk around the topic for about 15 minutes, followed by another 15 minutes of discussion. I had been very much looking forward to this workshop, but was still surprised on just how nice a boost a Saturday afternoon, spent in great company, discussing testing, on a really inspirational level, can give – still feeling it, two month later. Many thank for this to all involved, and especially to James for making it happen.
I was up first and talked about something I observe myself doing a lot when testing: role playing. I use it consciously as a heuristic when I feel blocked or find myself out of test ideas, but also unconsciously when being engaged with the software. Just imagine asking yourself “What would the user do?” and you are in the mindset which I call role playing here. I took inspiration from some well known methods to explore the concept from different angles: stepping into the shoes of specific user types of your software (“Persona“) or other members of your team, to applying different mindsets (“Six thinking hats“) and finally into that of the Software itself. Which world does it live in? Who communicates with it? Her? Him? What might cause stress, discomfort, angry reactions, disappointments?
Liz Tattersall introduced us to a complete other angle towards the topic – testing /ideas/ when questioning requirements, user stories, drafts of the software to be. She showed in a few examples what kind of questions a tester could draw up in order to test these product ideas early. Even an exposition of “as a user, I would like to …” might trigger you to start asking who exactly the user is in this context – which might open up a whole new ground for discussion. As I recently had been testing rather towards the end of an release cycle, I greatly enjoyed to get a feel of that specific testing mindset again.
We explored this area further as Michael Ambrose lead us from thinking about testing early in a project to discussing about how to actually do that. What testing activities can you apply when you do not yet have some executable delivered to you? Our thoughts went from /testing/ ideas over triggering discussions around requirements to model based testing, early automation and questioning on how to apply formal testing techniques on early phases of the product development.
How a small idea can grow into a big win was shown by Neil Younger. Fleshed out with examples from own experience he emphasized a few points that I could only nod my head to, repeatedly. Solve a manageable thing, let it grow, be a aware of the end goal, validate your idea regularly, try it out small scale, and so forth. Having a good idea is a very valuable thing, but to be able to implement it in a decent, pragmatic, functioning way is just beautiful and can change the dynamics of a team or company to the better.
James talked about analogies and gave one between joking and testing. Yes, you heard that right. He showed how techniques and skills in use when testing are similarly used in joking. Hence joking as an activity that you can use to train you testing muscles. He’ll be talking in more detail about this in this years EuroSTAR and you can also find thought on this on his blog – I highly recommend it, not only for the fans of bad puns.
Gabrielle Klein continued the theme of drawing inspiration from your real life into testing, claiming that there are no test ideas, only real life. She emphasized this drawing analogies between life and testing with examples from continuous learning and training, challenging yourself, evaluating risks and worse case scenarios to exploring your environment.
Some thoughts and takeaways from the day, that I’ll want to ponder for quite a while longer:
* How your own personality might shape the methods you choose, the way you choose and work them
* To find life, personality and testing constantly intertwining
* How useful it can be to name “things” you do (unconsciously) when testing. It enables you to more consciously apply them (e.g. when blocked), to find others that compliment them, to talk about and share them with team members or fellow testers
* How an analogy can help you understand a topic better, looking at it from a seemingly unrelated angle, finding parallels
* And really, really use Checklists, all the time.