Manage Learn to apply best practices and optimize your operations.

Goal #1 for the QA tester: Take ownership

QA testers can earn respect and gain influence with peers by taking ownership of the software they work on and looking up to good product managers.

 Jennifer Lent Jennifer Lent

The role of the QA tester has come a long way in the last couple of years. In most organizations, the QA tester is no longer seen as just a bug fixer. After years of being relegated to the back room, QA testers have earned a bit of respect. They are more than just the last set of eyes on the software before it goes live.

But what, exactly, does this more visible new role for the QA tester entail? From a career perspective, what is the best way for ambitious QA pros to define their role, thus earning the respect of their peers (and managers) and gaining influence over the software product under development?

It takes a lot more than avoiding being called "the bug fixer."

QA testers seeking career advancement would do well to model their role on that of the product manager. Product managers take ownership of the products they oversee. They have a keen interest-- and a say -- in what goes on in research and development and in manufacturing. They keep close watch on the sales and customer service processes, observing what works and what doesn't. They incorporate insights gained from those observations in future product releases. In other words, they own the products they manage, taking responsibility for every aspect of the product lifecycle, from cradle to grave.

Take ownership, QA testers

The idea of the QA tester as product manager occurred to me when I recalled a conversation with Jon Bach, director of live site quality at eBay, at a recent software testing conference. Bach is responsible for making sure the giant online auction site's customers can successfully bid on, buy and sell the offerings in millions of listings posted on the site on any given day.

Every day, before heading home to his family, Bach logs on to eBay's home page and clicks through the application with an eye to answering this question: "What is the quality of the site right now?" The site has already undergone rigorous testing, but he often finds minor glitches his team missed. For example, checking the site on April 25, 2013, he spotted an ad for Ray Ban and Armani sunglasses that included the following small print: "Special promotion expires on February 25, 2013."

The error wasn't what Bach's team considers calls "severity one" -- it wasn't going to bring business to a halt. "But it was priority one, because it was embarrassing," Bach said. Instead getting home in time for dinner, he worked with operations to find the source of the error and fix it. (Initially, they were unable to reproduce the error, which turned out to be a browser compatibility issue.)

Bach refers to this activity of checking the site before he goes home as "testing after you've finished testing" – essentially doing random checks on things that are indicators of quality. But I think the nightly checks are more significant than that. Like a product manager, he is taking ownership of the product he is responsible for testing, constantly asking, "What is its state of quality? How can it be improved?"

Bach defines his job in terms of the quality of eBay's Live Site. He isn't the guy who heads the team that fixes bugs on eBay. He is the guy who manages the Web application that thousands of eBay buyers and sellers depend on to make money.

Managing without authority

Ten or so years ago, I wrote a series of articles for that explored what product managers do, and examined the wide range of skills and experience the profession requires. One product manager I interviewed described his role this way: "You are responsible for everything and have authority over no one."

Does that sound familiar? It accurately describes the situation in which QA managers often find themselves. They are accountable for software errors, but getting developers, operations managers, even business owners to agree to the changes a QA pro deems essential is often a big challenge.

An effective way to increase the influence of QA, Bach suggests, is to build strong relationships with peers you depend on before you have to ask for a favor. "Otherwise, when you call your Ops guy at 5 p.m., he is just going to tell you 'Sorry, I can't reproduce the error,'" Bach said. "But when the relationship is already there, he says: 'I can't reproduce this. Can you tell me more? Can we work on this?'"

Taking ownership and managing without authority are not QA-specific skills, but they are an essential part of every professional's career path -- especially in today's fast-moving, ever-changing technology environment. Look at it this way: When it comes to QA, do you want to be known as "can do" or "cannot"? Understanding the larger role QA testing can play in project and business success by thinking about the role as a product manager might be a key factor in your career success, as well.

What are your thoughts on the changing role of the QA tester? What challenges do you face and what tricks have you found to make things easier? Let us know and follow us on Twitter @SoftwareTestTT.

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I agree completely. I guess that I never though of it in these exact terms, but what I do is to take ownership. There are just so many ways in which a product can fail that have little or nothing to do with its functionality. 

It might not meet the needs of the user. It might not make/save money. It might create a lot of support issues that are not necessarily bugs, such as questions from confused users. The performance might be terrible. 5 years down the road, it might be used for a different purpose than it was intended. These are all things that I try to think of when we're creating or changing a product. It feels like a large weight on my shoulders, but it gives me a healthy amount of anxiety that keeps me thinking. 

It's no fun when a product isn't as successful as hoped for, even if it's not directly your fault. Taking ownership means that you try to prevent those cases, and mitigate issues when they do occur.
I'm not sure I agree with the idea of QA "taking ownership of the product". Testing's responsibility is to discover and subsequently reveal as much information about the product and its behavior as possible, but decisions will always be made by the product owner, not the tester. I think taking ownership of our responsibilities makes more sense. It's important to develop the relationships that will help you do your job effectively, but viewing this as 'management' will likely not help with those relationships. While the examples here are great examples of good things to do, the descriptions feel a little...overzealous.
It's a swell thought, but I'm not sure how many places I've worked that have actually given the QA staff that level of power. They're usually right up there -- or down there -- with the technical writers on the staff totem pole.