This evening I attended an AMA (hosted by Ministry of Testing) by Lisa Crispin, one of my testing heroes and probably the first “named tester” I was ever aware of. It covered a topic close to my heart as an advocacy-focused “Team Glue” tester: Whole-Team Testing. It was a real honour to have a question answered by someone who has been so formative in my own practice as a tester!
Below are my notes on a few of the questions, almost entirely paraphrased (anything in “speech marks” is directly quoted however). Also included are some excellent points from Vernon Richards, who presented with his characteristic wit and verve.
“When I try to get developers to do testing, they say it’s not their job. What can I do about that?”
Lisa Crispin (paraphrased): Remind devs of the cost of testing and retesting, and ask them if they’d rather write code or fixes. And show management why it’s important to invest in quality. Ask them why they think testing isn’t their job, and just listen to their answers. Work on the holes in their reasoning.
“How can product management support ‘whole team testing’ with their actions and influence? Specifically 1) in team as a representative of PdM as the product owner e.g. I have a PO that likes to say “I’ve tested it and I’m happy with it to go to prod” 2) as the product management function that may not sit within a team or even department but that care about the whole product experience.”
LC: Product should care about quality, not only “getting features”. Code quality/correctness should be owned by the dev team and that should drive features being considered complete. Product Owners need to understand the significance of quality, and taking the time to “do it right” – because this is what actually saves time overall. Technical debt should be considered. Budgeting points for investing in quality is a great solution to this. Marketing, Sales etc should be shown the significance of investing in quality.
“If the whole team tests, what’s the future for testers?” (woo yeah my question!)
LC: There’s a lot for testers to do. People being jacks of all trades doesn’t rid the need for experts – advocates in the team will always have a role. Even when Machine Learning comes along to test… it will need to be tested, by testers. Developers are unlikely to be domain experts, subject matter experts – that’s a core role of a tester, consultants who help lead acquisition of testing skills, and domain expertise. A lot of teams have a lot fewer testers – so it’s up to those in testing to show their value.
Vernon Richards (paraphrased): You might be able to deliver without testers, but you can’t deliver without testing. Maybe the future for testers is adaptation – testing may not look the same, but it’s still testing.
“What is a challenge with getting non-testers to understand that testing is more than automation?”
LC: Testing is a vast field of knowledge. Make people aware of that and show them that it’s really valuable to them! There’s well over 100 forms of testing. Automation can’t cover all that, and experimentation is key to good testing – as is listening.
VR: “‘Automation is not a silver bullet!’ But we should listen and understand where that attitude is coming from.”
“How have teams incorporated performance testing in whole team testing? We’ve had some success making the transition with functional testing, but the complexity of performance test design and results analysis has made performance testing more of a challenge for us.”
LC: Performance, security and other non-functional tests do not happen by magic. This investment isn’t obviously essential… until the site goes down. This era of the cloud is different, it’s intimidating to look into these specialisms but it’s not that crazy. Pick a tool, get a baseline… break it down into baby steps and don’t let it overwhelm you (“I know that’s simplistic and I live in unicorn land…”)
Unicorn land seems like as good a place as any to leave this. Great, informative session. Thanks to all involved!