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.
Building 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.
Outcomes
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!
12 comments on “When the whole team owns testing: Building testing skills”
Hi Lisa,
thanks for sharing this with us. This sounds really great. While reading your post, one question came to my mind. What do you do to engage and encourage software testers and developers to get out of there comfort zone and to perform some additional nice testing activities in a group?
Would love to hear your ideas and thoughts!
Have a great day.
Best,
Daniel
Hi Daniel,
Thanks for your kind words! We are fortunate in that our company has an ingrained culture devoted to building in quality, but at the same time generally does not employ professional testers. The practice of “group hugs” came about in our team because they realized that without testers, they were probably missing a lot of important bugs. They found more bugs in group hugs, but they were doing ad hoc testing, not exploring, and still missed important issues.
Support from the managers is key. The development director has good testing skills and values exploratory testing. He sometimes assigns one or more developer pairs to do exploratory testing together with a tester for one or two hours, and encourages the programmers to do exploratory testing on each story they work on. After we scheduled the ET workshops, he mandated that all programmers participate, and in the workshop, he reiterated to them why it is important for each person to grow these skills.
If you don’t have that support already, I think you can build it by showing the value of testing. Because we testers uncover important issues and show them to the programmers and talk about them, they value what we discover and they want to be able to find some of those issues themselves rather than have a bug come back to them days after they thought they finished a feature. As testers, we need to build our credibility. Focus on high impact issues, don’t make a fuss about minor bugs that won’t really bother the customers. Show that you aren’t wasting anyone’s time, but helping the team to make customers happy and make the business successful.
How about you, what ideas do you have?
— Lisa
Hi Lisa,
thanks for your answer. The funny thing is, that we as tester have a really great standing in the company. We are highly appreciated and respected on all levels from developers to upper management, which is really cool.
What we are doing to spread the testing mindset in the team and across the company, is to do test sessions whenever we need them and to pair with developers when they work on a new feature or bug fixes. This works pretty good for us, but sometimes I have the feeling that we could do more :). (Maybe it’s just my feeling). More from the testers perspective and more from the developers perspective. But I don’t know how I can engage the colleagues to do more testing activities and to pair more.
Maybe we should start to do pairing even more like Katrina Clokie did in her company, even if she stopped the pairing experiment in her company but I think the outcome for her was successful.
Have a great day and weekend.
Best,
Daniel
Hi Lisa. I read your post and liked it a lot. My question is, how could you convince the people to be part of this activity? Let me tell you that currently I work in a QA team that is still neither agile nor waterfall. We are trying to be agile, but the development team has been working in a disorganized way since it existed and they are reluctant to change. The QA team as a whole is new, and we are experiencing difficulties every time we try to make the developers understand that we either need better explained stories, or their time, so that they can explain us, to understand about the business in order to test better. I think that this kind of activyt would be excelent for this
Hi Juan, glad you like the post! I know it is difficult to get developers and other team members to start taking ownership of quality and engaging in testing activities. I’ve found the best way to start making “baby steps” is to bring up pain points in team retrospectives. (If you aren’t already having retrospectives with the whole delivery team, then that’s your first problem to solve). I am sure everyone on your delivery team, including the developers, wants to prevent defects from getting released to production. This is really a team problem – your QA team cannot prevent defects by itself. In the retrospective, talk about how many defects you find in post-development testing, and how many get into production. Then decide on a goal – let’s say you want to reduce the number of critical defects by 20% in the next month. Now think of small experiments to work towards that goal.
I’ll give you one example. I’ve worked on three delivery teams that started out with no automated regression tests, or perhaps only automated regression tests at the unit level. I got together with the business stakeholders to find out what functionality in the production system has to always work. Then I wrote manual regression test scripts for those critical areas. The last day or two of each two-week iteration, everyone on the team – developers, business analysts, DBAs, ScrumMaster, PO – everyone took a portion of the regression test scripts and did the manual regression testing. Not only did we prevent bad defects from getting into production, it was great motivation to automate regression tests, leaving us more time to do the essential exploratory testing.
Hi Lisa,
I love your article and your pragmatic responses to all the relevant questions. I am working in a large organization where we are changing to new ways of work (Janet has actually trained us some time ago- no more hints). We have formed feature teams “in principle”, but we’re still getting our heads around how to become “T” shaped resources and do all the new stuff were meant to do. With regards ET I doubt that even our traditional test teams were doing this properly if at all.
I am currently assisting teams with their transition an I will be sharing this article in the hope that it will take us forward in a practical manner in the quest to get everyone to own quality.
Many thanks.
Hi Rob, thanks for the feedback! Your teams are facing a big mindset shift and transition, I hope the article helps. I highly recommend Elisabeth’s book, also. Remember, baby steps, it will take lots of time! My own team is grappling with also having “vertical” pods where each pod that does a feature has to do the full stack of coding and testing. So many challenges!
— Lisa
Hi Lisa,
Thanks for you advice and the book recommendation.
I have shared your article with some of our broader management team for which I have received a brief positive response. I hope to share and initiate discussion in one of our guilds. I will definitely provide you with some feedback if the planted seed germinates.
regards, Rob
[…] When the whole team owns testing: Building testing skills (Lisa Crispin, @lisacrispin) […]
[…] Source: lisacrispin.com/2016/09/07/whole-team-owns-testing-building-testing-skills/ […]
[…] When the whole team owns testing: Building testing skills (Lisa Crispin, @lisacrispin) […]
[…] At the same time, I still encounter many companies who are doing testing the way most people approached it 20 or more years ago. They have siloed testing/QA teams who don’t collaborate with development teams, operation teams, or even product and design teams. They have no automated regression tests or are struggling mightily to get traction on that automation. They’re doing only manual regression testing, working from written scripts, and no exploratory testing. […]