During my time at TestBash Brighton possibly the most common subject to pop up was related to group testing activities. Be that mobbing, bug bashes or whole team test days built into the process. Maaike Brinkhof in her talk, ‘Exploratory Testing with the Team, a Journey Worth Taking’ explained how they undertook ‘Team Test Sessions’ before they released. Below is an excerpt from her talk description and I particularly like the comment about testers being expected to be more technical but developers are not expected to become better at testing.
For a while now, the motto for agile testers has been: ‘acquire more technical skills so you can support the team better’. However, you almost never hear the motto for developers: ‘improve your testing skills so you can support the team better’. Even in an agile context, you still see testers doing the bulk, if not all, of the non-automated testing.
But wouldn’t it be more effective if the testers teach the whole team how to explore? Can you imagine the power of a whole team being able to test an application effectively?
Exploratory Testing is great to teach others because it uses everybody’s unique point of view, experience, and biases when interacting with the application under test. As a tester, you can take the lead in switching your teams' mindset with regards to quality and test responsibility, even if you are a junior tester. You can do more than you think!
This was fascinating to me as I’ve been looking into how we can gauge the quality of our releases. So I proposed our first officially planned group testing session focused on the release. We have done similar activities in the past when there was a backlog and also for load testing so the idea was familiar.
For context we work in two week sprints and part of the system can be deployed frequently and part is on a strict monthly release cycle. To ensure we were confident in our release candidate, testing as a team seemed a suitable activity to help with that.
We needed to come up with some ground rules and I had a few thoughts on what we might need to begin;
Run the session on the release candidate at least 3 days before we have to commit it, to allow time for any remedial actions from our findings
Agree the release candidate versions in system test to run the session on so everyone is clear on what is being tested
Agree the process for checking anything that is found (this could be to mob, discuss or record and discuss later or even something else)
Agree our next steps (confirm the release candidate or decide if we have time to address anything found)
We can then discuss whether we found this valuable at a dedicated retrospective or review
Plans were put in place, time booked in the calendar and some links shared to broaden our understanding. We were ready.
Starting small with a planned two-hour session it was interesting to see developers interacting with the UI ahead of time and asking questions like, what is supposed to happen next? Other questions triggered conversations about intention, value and risk. What I’d hoped would happen during the team testing activity already had! Even before we had ‘officially’ begun.
My fellow tester in our pod Scott took the lead and sketched out the scope of our session.
On an A board we showed;
All versions we were testing
Environment details we were testing (We also sent an email with relevant links to sites being tested and test data details)
Outline of what wanted covering (essentially a mini test plan to guide rather than enforce)
It has to be said although Scott sent mails out with instructions some developers did their own things! No matter what you think users will do, they will always surprise you . We also considered using test charters but as it was our first time, decided to let everyone essentially ‘do their own thing’ with a caveat of knowing everyone would need to register on the site as a new customer. We also asked that at least one payment was made during the session.
The whole team were great and really bought into the session! We are definitely doing this again for the next release. For the record some small things were found and one slightly higher which was fixed in five minutes. A very valuable use of the team’s time.
Retrospective findings;
Having a specific retrospective on our team testing, not too long after the group testing session (next morning), really helped our shared understanding of what people thought about it and we also discussed how to improve. We were honest about what went well and not so well taking our personal ownership of things without being too hard on ourselves. After all, it was our first time! Below is a slightly abridged version of the findings shared at work.
Notes:
We were a little uncoordinated through not all reading or following the instructions provided
Communications were good in places but could be improved
Having lots of different perspectives helped identify things that may not of otherwise been highlighted / found
We didn’t resist the urge to fix what we found straight away (I’m looking at developers here) or look at the code to work out why it behaved the way it did
Time boxing was helpful in managing the session
We didn’t resist the urge (I’m looking at testers here) to delve deeply into something found. It’s ok to make a note and move on, then come back later to maximise value from the session
Look to involve people outside of the team by providing guidance to enhance diversity and range of users
Improvement Activities:
Communications;
Kick off stand up to ensure everyone is on the same page
Visualising key information such as environments rather than just in an email
Recording findings rather than everyone breaking off to discuss what’s been found
Process;
Provide information for registering on paper to stop copy and pasting; customers will likely type the details in
Reduce distractions by not doing other things as well no matter how well intentioned
Keep focused on the task at hand saving deep investigations to later
So that’s our first (mostly) successful foray into group testing. We have ideas to make next time better and we are looking into a succinct guide to share with our other teams as we learn more. Give it a go, you will find it fun, sort of, useful, definitely and a positive addition to your testing strategy, absolutely.
Here are a few links to useful information on mobbing, bug bashes and the full description of Maaike’s talk.
https://www.ministryoftesting.com/events/testbash-essentials-brighton-2019
http://visible-quality.blogspot.com/2018/07/mob-testing-is-different-to-bug-bash.html
https://dojo.ministryoftesting.com/dojo/lessons/mob-testing-an-introduction-experience-report
https://ministryoftesting.com/dojo/lessons/next-level-teamwork-pairing-and-mobbing-maaret-pyhajarvi