The Twitterverse and other social media continue to host many discussions on topics such as “Do testers need to code?” As Pete Walen points out in his recent post, the “whole team” approach to delivering software, popularized with agile development, is often misunderstood as “everyone must write production code”.
The “Whole Team Approach” in practice
Janet Gregory and I, along with our many collaborators, explain a healthy whole team approach to testing and quality in our books, Agile Testing and More Agile Testing. You can find many stories of teams working together to build in quality in our books. Here’s a recent example from my own team.
Improving our exploratory testing
My team works together to build quality into our product. I recently wrote about how we use example mapping to build shared understanding even before we start coding. Exploratory testing is another practice that our team (and indeed our whole company) values highly and which everyone, regardless of role, does at least occasionally. But most people are not experienced in ET techniques.
We have very few testers on our team compared to the numbers in other roles, but everyone does testing. We’ve been trying experiments to help designers, PMs and programmers improve their exploratory testing skills.
Last December, I did a short exploratory testing workshop to help team members learn to write and use charters and apply their imagination and critical thinking powers as they test. We have occasional “group hugs” where team members in all roles pair up, assign themselves charters and test while sharing what they learn.
To help new team members learn about ET and give everyone more practice, we did a new hour-long ET workshop (split into two sessions, because we had to accommodate up to 40 people). One session had a Zoom session so remote team members could participate.
How the workshop worked
We started with a 10 minute overview of why we do exploratory testing, how to create and use personas, charters (based on Elisabeth Hendrickson’s template from Explore It!), various ET techniques and pointers to more resources. (Contact me if you’d like a copy of the slides). We gave the group a recently delivered feature to explore. Then everyone paired up or formed a group of three, wrote a charter and dove in.
As a tester it was funny to hear team members in other roles say things
like “There’s no information in this epic, I don’t know how the feature should work!” Welcome to my world! They jumped right in, though. Some wrote charters in Tracker stories (yes, we use our own product), some mind mapped them or wrote them on paper. They had fun exploring, getting ideas from each other and calling us over to show us bugs or ask questions.
Each workshop session tested a different feature set, and each found several issues, including a serious one. The feedback they gave resulted in some design changes as well. Both features are now much improved.
More importantly, team members have some new testing tools in their toolbox. One of the designers commented that working through more examples would have helped him know what to do in his own testing. I’m working on planning testing dojo sessions so people have an opportunity to practice their exploratory testing skills.
I’d love to hear how your team is growing their whole team testing skills!