It’s an all-too-familiar scene. You’re approaching the end of the current sprint. You’ve had some difficulties and delays along the way, but aside from completing the testing of the final few stories, your team is just about done. The boss comes over. “Good news,” she says, “I’ve managed to find a couple of people to help you finish your testing a bit quicker!”. This is a post on testing with non-testers.
These people are often sourced from other teams, and often aren’t testers at all – I’ve had first-hand experience of trying to share my work with developers, UX designers, business analysts, finance directors and receptionists! The challenge is often exacerbated when you’re close to a release or delivery date: your project enters a phase which Rob Lambert, at EuroSTAR 2014, described as the “anyone who can click a mouse” period of testing.
An all-hands approach to testing can be beneficial in certain circumstances; for instance, if you’re running a bug bash or introducing a company-wide dogfooding policy. However, arbitrarily moving non-testers into a test team can have a variety of negative impacts. One of the worst is that it reinforces the notion that “anyone can be a tester”, or that there’s no need to have dedicated testers, which can be demotivating to professional testers.
From a pure resourcing perspective, project managers might think that adding non-testers to a test team makes sense. If you have one tester saying there’s an estimated three days remaining before the team can be confident of release quality, surely you can just throw two more people into the mix and you’ll be finished in one day…? Even though this was effectively debunked by Frederick Brooks in his 1975 book The Mythical Man-Month, it’s a notion that just won’t die.
Here’s one simple example from my recent past. I outlined my current situation to Colin, a non-tester colleague: “We’re just about to release some updates to our API, and although we’ve got good test coverage on our existing code, the latest additions could benefit from some extra testing – I’ll be glad to talk through the changes with you.”
“Great,” came Colin’s reply, “just one question: What’s an API?”
Getting by: What I did in the short term
At first, I was disheartened by this situation. We had plenty of testing-related tasks on our scrum board, but given that Colin had no context of the project, its functionality, its architecture or its current test coverage, I didn’t feel comfortable in assigning tasks to him. After all, if Colin failed to find any problems on a given task, how would I know whether that meant the functionality was stable, or he just hadn’t tested it very well? I’d end up re-testing all of his tasks, for my own peace of mind.
I decided to do pair-testing with Colin. There were a number of benefits to this. Firstly, it helped to keep me honest: when Colin asked why I was taking a particular approach to a testing challenge, my answers would often reveal gaps in my own thinking which I might otherwise have glossed over. Secondly, the abstraction of pairing meant that Colin was able to immediately work on the same level as me: his role of questioner/analyser was equally as important as mine, meaning that we both felt that he was bringing value to the task.
As a result, although testing took more time than our project manager might have originally hoped, it also delivered more value than it might otherwise have done. If your team truly values quality, it’s surely worth taking this extra time to get it done right.
If pairing isn’t appropriate, for example if you’re not located in the same office, you might be able to find some test activities which play well to your colleague’s strengths. In Colin’s case, he was a user interface designer, and our product had a web front-end which was prone to having browser-specific problems. When I found myself needing to work solo on a task, I’d set Colin a list of browsers and some user-centric scenarios to walk through. Our focus here was on display problems rather than functionality, so his lack of test experience was countered by his own inate eye for layout precision.
Colin and I worked together on several other occasions in the project after that, often discovering issues that I might have missed on my own. Our project manager came to embrace everything that came with this relationship – most importantly, that it didn’t mean that they would get results more quickly!
Achieving the dream: What I did in the longer term
One of the benefits of a lean approach to development (and testing) is that it encourages the team to build quality into their product from the start. As such, I’ve found success when I spend time both coaching and pairing with non-testers, infusing them with the key techniques of testing.
This was a challenge for me; I had to accept that I wouldn’t be doing all of the hands-on testing myself any more. It was simply a case of acknowledge that our project wouldn’t scale if I insisted on testing everything myself, so investing time in teaching testing principles to the rest of the team would allow me to optimise the time I had available.
You could attempt to coach colleagues on a one-on-one basis, as the need arises, but if you’re feeling bolder then consider running a series of testing workshops. This is your chance to shine, and show exactly what value a professional tester can bring to the team! I’ve seen a couple of really good examples of this recently.
Firstly, Katrina Clokie’s presentation at Nordic Testing Days 2015, showed how she crowdsourced a test strategy with her team, and empowered her team to find where their gaps were. One particularly revealing comment from one of her colleagues was “All of our testing is automated – we just haven’t had time to do any yet!”
Another invaluable guide is Helena Jeret-Mäe’s A Workshop on Testing for Programmers. Not only has Helena kindly provided all of the resources that she used for her workshop, but she also shared her own experiences of creating and delivering this material, delivering a wealth of useful tips for those who want to run similar sessions for their own teams.
Right now, I’m fortunate enough to find myself working within what I’d call my dream environment. Although I have “test” within my job title, there’s barely any dev-test divide within my team. We regularly partake in multi-disciplined mob programming sessions, allowing testers to give feedback and insight as the code is being written, and techniques such as TDD are rife, helping to increase focus and minimise waste.
Testing With Non-Testers
I no longer find myself thinking that I’m testing with non-testers. My role is now something closer to that of a “test specialist”: we’re all responsible for quality, and although I still play my fair part in hands-on testing of products, it’s equally important that I help the rest of my team to reach their own testing potential. It’s gone from being a dream to a reality, and if you’ve faced the same challenges that I mentioned, I encourage you to seek out this dream for yourself.
