In January this year I made a commitment to myself to get more involved in the testing community and to start helping others within my organisation understand what qualities testers can bring to a team other than “checking stuff works”.
It’s a noble cause and one I felt I could tackle, so much so I included this as one of my personal objectives for the year. In order for me to better communicate my value to teams, I’ve been studying testing as a craft.
I’ve been keen to understand how to frame conversations so that people see more to me than a quality gate (of which I am nothing of the sort). My hope was that through coaching and education, my team would be able to adopt my methods and the “T Shaped Team” pipe dream would become a reality.
This has been a frustrating experience though, I’ve been left out of conversations as they were “too technical”, asked to “sign off” a product numerous times or at the opposite end of the spectrum been assured unit testing (which I played no part in) covers the testing of a feature therefore I did not need to look at this one.
I’ve been reading “Lessons Learned In Software Testing” by James Bach, Cem Caner and Bret Pettichord. There is a lesson in there that struck a chord with me.
Lesson 15: “Don’t expect anyone to understand testing, or what you need to do it well”
For a long period of my career, testing was something I saw a job many people in the team could do. I had my place of course, but other people could help because there were more developers than testers (usually).
I’ve been a strong advocate for pair testing in my team (something that has worked wonderfully recently) and even floated the idea of mob programming which I thought would aid in my quest to providing insight into the value of testing whilst simultaneously building the product (faster feedback is never a bad thing).
I’ve come to the realisation though that non-testers don’t get it (and that’s perfectly fine). We’ve generated test ideas as a team and even improved unit and integration test coverage but when I leave them to their own devices, the mindset dissipates.
To put things into context I could pair with a developer on a story and they could coach me through writing high quality code. I could in some cases, even go away and write code based off of what I have been taught and deliver a feature. The problem though lies in the tacit knowledge a developer carries when we pair. Explanations about development that go way beyond the boundaries of my knowledge (even for someone who considers themselves a fairly competent programmer).
The same applies to testing. Under a testers guidance, a developer (or a product owner or any other non-testing professional) may feel empowered to help test a product but leave them alone and they could feel vulnerable as their guide is no longer on hand.
In order to truly help people understand testing, the tacit knowledge we hold in regards to our approach should be brought out in the open and explained in a systematic manner.
I try to frame most of my conversations around risk these days. What are the risks with the product and do any of them threaten the value of the product to the customer?
I am of the belief that if the conversation centres on the context of why testing is a thing, people will start to understand it’s true value.
Generating test ideas, while a skill in it’s own right is only half the battle. Relating them back to potential risks in order to convince people of their importance when it comes to mitigating them is the just as (if not more) important.
I have started to undertake the task of correcting anyone who suggests I sign a product off to be released. I do no such thing. I inform, advise and update all interested parties on the current state of the product.
When deadlines are tight, decisions may need to be made in regards to how work is prioritised. As testers, it is our job to present the information in such a manner that allows product owners and managers to make informed decisions in regards to priority and customer suitability.
In closing, I still feel like I am not quite fully there but my team is getting better at discussing testing day by day.
I hope one day, I’m not relied upon. I’ll always have my place on the team as the testing specialist but if I am unavailable our work shouldn’t suffer or worse, come to a grinding holt as a result of it.