The session was aimed at helping us to understand how test charters can be used to drive exploratory testing, instead of long winded test scripts. In this post I refer to test charters as charters to save ink.
Straightaway Markus got us thinking by asking what we thought about the layout of the room - we were in rows, as we had been in other sessions. This set up had made me uncomfortable as I couldn’t see who was talking behind me. As such, I had positioned myself at the end of the first row & turned my chair through 90 degrees so that I could see the presenter & the rest of the group. Lovely job, much more conducive for collaboration!
Anyway, back to this session - we all moved our chairs into a big circle, similar to that of a self-help group, so Markus could talk us through charters.
A few clarifying questions later, we split up into groups - our group being the dream team including Huib Schoots, Simon/Peter, Tony Bruce, myself & 3 others whose I names I’ve unfortunately forgotten - my apologies if you’re reading this (that said, you know who are & if you are reading this, please get in touch & I’ll update the post!)
The challenge was to think of a product & then write some charters to test that product. We went for Facebook as our product & we were the implementation team responsible for ensuring new features & functionality hadn’t regressed Facebook. We were not responsible for testing the functionality.
We spent a while defining our context and then got onto the charters.
What charters we did create isn’t really important, but we had a valuable lesson served to us on a plate - the charter covering one of the highest priority features (invites) wasn’t thought up until the end of the challenge - almost as an afterthought, triggered from another charter.
This is bad & good - bad because we didn’t notice it was missing until Simon/Peter pointed it out, good because it demonstrated one of the beauties of exploratory testing - you don’t stop thinking of new charters when you already have a raft of them. The stuff you learn from the exploratory session creates new charters. Well, it impressed me anyway.
In the real world, we would continually prioritise the charters - so in this example, the testing of the invites feature would have jumped to the top of the pile of charters to be executed next (do you execute charters?)
After the challenge, we went around the room going through each groups charters. It was great to see the different visualisations on the whiteboards & flip charts - mind maps, flow diagrams & (unfortunately because I was the scribe for our group) plain old lists. I believe Huib took some photos - I’ll link to his post or get the images off him or something like that.
The session moved into a conversation about exploratory testing in general with topics including pros & cons of pair testing & the difference between test charters & test ideas. Markus was helped out by Paul Holland in this section - that man likes to talk! (fortunately he knows what he’s talking about, so we’ll let him off :-))
Overall, a great, interactive session which really helped us to get a grasp on test charters.
A couple of questions / points I didn’t get a chance to ask which I need to follow up on:
- is a difference between a test charter & a test idea that charters need to be SMART & ideas don’t?
- how do you use charters when only testing delivery of small chunks of features? For some of the stuff I’m testing, it would take longer to write the charter than to test the code. Or is it that the charters are written against the feature backlog / stuff yet to be done prior to the feature being delivered?