How many of you out there have experienced one of these situations? 1) You have more features ready for testing than you do Quality Assurance people. 2) QA goes on vacation, or is otherwise occupied, and testing or releases grind to a halt. 3) A bug is released and the first thing you want to do is grab the nearest tester and shout, “Why didn’t you catch this”.
If none of these apply to you, way to go! You have my permission to stop reading and go check the score from last night’s game. If not, I urge you to continue. Here it comes, the philosophical crux of this post…QA is EVERYONE’S JOB!!
It doesn’t matter if you have people on staff with ‘QA’ or ‘Quality’ in their title. We’re all in this game together; every single individual, top to bottom, intern to executive, has a collective responsibility to deliver quality to their customers. As people of the software development world we must get out of the throw-it-over-the-wall, its-not-my-job, i’m-roadblocked-by-QA mentality. When we spend so much time trying to remove roadblocks and prevent the siloing of information, why should it be ok to neglect our quality process?
Over on the New Relic .NET team we’ve taken this mentality to heart. Quality is a shared responsibility, and as a QA engineer I’m able to maintain a manageable testing load and focus more time on improving the team’s quality processes. More importantly, I never feel like I have to hurry quality. To find out how we got there, read on.
Avoiding the job title trap
Just because you may have someone on staff who has those magical two letters in their title doesn’t mean that they should be responsible for anything and everything related to testing. It’s quite common that your QA-to-dev ratio has already set you up for failure. I may only have ~10 years under my belt, but if I had a dime for every time I have heard “we have too much to test”… well, I’d have a lot of dimes. Everyone on the team needs to understand the quality process; understand it and, to a varying degree, take part in it.
Failing to take action will likely lead to a few not-so-great situations. First, your testing people may experience some degree of burnout as they will feel the majority of the heat when bottlenecks occur. Second, and perhaps even worse, when the testing queue backs up, testing will inevitably be rushed. More times than not, this leads to mistakes and things falling through the cracks. When that happens, it affects customers, and when customers are impacted, well…let’s just not go there.
Making the shift
Your quality people need to be valued equally amongst their industry counterparts; if that isn’t the case, make that your first priority. Once you do that, change your language. Stop saying “you” when talking about testing with QA, start saying “we”. How are we going to test this? What did “we” miss (in the event of a regression/bug)?
The QA professional(s) on your team should be the leaders of quality for the team, but not necessarily always the doer. They need to be educators and promoters of quality, responsible for ensuring that the process is being followed. They need to make sure that everyone feels some of the pain — just enough, but not too much.
So, where to start? It all begins with a goal. That goal should be to educate and train the other members of your team such that in your absence as QA, adequate test plans can be created and executed. Start with some basic knowledge sharing, fill any holes or gaps in the teams understanding of the current testing processes and/or systems.
Next you should progress to a ride-along of sorts for an upcoming feature. Specifically, pair with another person on the team and discuss the testing requirements together. Ask them how they would approach testing this feature, then work with them to fill in any holes in the plan, explaining why it is important to consider this or that.
When it comes time to execute the plan, pair up again. Don’t just explain how you would test the feature, show them. This is the opportunity to share all of that knowledge you’ve acquired and any tips or tricks you may have up your sleeve. Repeat this process until you build confidence and trust such that during times when you are occupied elsewhere, or will be out of the office, a brief consultation with QA about a testing plan will suffice.
Reaping the rewards
What’s in it for you? How about less frequent bottlenecks, more accurate project planning, and less burnout among your QA people. I can say firsthand from my experiences both at New Relic and at previous positions that this approach made the level of team involvement in the quality process is much, much higher:
- There’s now a discussion during project planning as to how much time it will take to test feature xyz.
- No longer do people blindly throw out estimates like “that should only take 2 days to test” with no knowledge to back it up.
- Developers are even accounting the time for them to write not only unit tests, but functional tests as well.
One perfect example of this at work comes to mind. Recently, one of our developers took the initiative to prototype a new framework for measuring CPU, Memory and Response Time performance of our Agent. He did this by simply identifying a deficiency in our existing process and worked with QA to implement a new layer of testing and get this rolled into our process.
To me this was absolutely amazing and proof that getting the team at large to share in the quality effort pays big dividends. Most importantly, I don’t worry nearly as much as I used to when taking a day or two off.
Stay tuned for more tantalizing topics from the quality space coming soon to a blog near you. In the meantime, let us know what you think about QA culture in our Community Forum!