At a recent Misfits of QA meetup, I heard about an interesting pain point in the QA process. The gist was that companies rarely invest enough in the diplomatic or managerial skills of their QA workers. It's not an idea I hear often, so I'd like to give it some thought. Here goes:
Communcation is more than Bug Reports
If you read a QA job listing, one of the recommended skills is inevitably Communication. Typically, I'm told that I need to be able to communicate their test results - file bug reports. In my experience, bug reports are a small and relatively easy part of the job. I spend much more time getting timelines from developers, getting requirements from our product team, receiving bugs from our Support team and customers, adding my own little insights and relaying that information between each party.
Much of this communcation seems outside of my role in QA. Why is Product asking me about Development's timeline? Why is Development asking me what feature X is supposed to do? My best guess is "because I have answers".
I need to know everything (about the product)
To test effectively, I need to know my product quite well. I need to be aware of the breadth of product that I'm responsible for, its high-level requirements as an oracle for the issues I find, and its low-level workings to help predict new issues. The more I know about the product, the better I can test. Given that knowledge, it's fairly easy for me to answer questions about the product.
To QA effectively, I need to be aware of what parts of the product are ready to test, what issues have been found, and what has finished testing (usually meaning its ready where release). And where developers tend to be split across individual features, as a QA I am usually responsible for the entire product. In short I need a timeline and development statuses for the entire product, which is useful information for the managers above me.
These two points taken together - knowing what the product should be and knowing what it currently is, start to sound a bi like a Product Manager. But while I know plenty about the product, I'm not deciding it right?
I need to own it, too
As a QA, I find myself having some real control over the design of my product - maybe more than I should.
When a developer asks me how a feature should work, my answer determines how that feature will be built. I'll try to stick to the requirements, but they're filtered through my understanding and my biases. And if I'm being asked how to resolve an issue, the requirements might give no answer at all.
In theory these questions should be directed to a real product manager. But in practice, I sit beside my developers every day, where the product manager does not. If we can't get a formal answer, then my answer often wins by default. So it better be a good one.
Takeaway
To be an effective QA, I need to act like a Product Manager to some degree. I need to know my product inside and out, and from 30,000 feet above. I need to know how development is going, what is done and when the rest will be. And sometimes I need to step up and decide the fate of some feature or issue.
If I'm going to act like a Product Manager, maybe I should practice like one too. But that's an article for another day.