I got this question in email this morning from a reader:
“I am a test supervisor at — and was promoted to a QA management position yesterday. I’m excited and terrified, so I have been thinking about how to organize the thought in my mind. After attending StarWest and following your blog for a while now, I am very interested in your opinion.
If you were a brand new QA Manager, and you knew what you know now, what are the top 5-10 things you would focus on?”
I am flattered by the confidence but in the event it is misplaced I wanted to answer this question publicly and invite readers to chime in with their own experiences. Besides, I am curious as to other opinions because I live with this same excitement and terror every day and could use a little advice myself. Here’s my first couple and I’ll add some more in future posts (unless of course you guys beat me to it).
tart living with your product, get passionate about it
Drink your product’s kool-aid, memorize the sales pitch, understand it’s competitive advantages but retain your skepticism. Test/QA managers should be as passionate about the product as dev managers but we need to temper our passion with proof. Make sure the test team never stops testing the functionality represented by the sales pitch.
Furthermore, part of living with your product is being a user yourself. I now live without a laptop and exclusively use my Chrome OS Netbook for my day to day work. As people see me with it in the hallways, I get to recite its sales pitch many times every day. Great practice. I also get to live with its inadequacies and take note of the things it has yet to master. This is great discussion fodder with devs and other stakeholders and also forces me to consider competitive products. When I can’t do something important on my Chrome OS Netbook, I have to use a competing product and this spawns healthy discussions about how users will perceive our product’s downside and how we can truthfully communicate the pros and cons of our product to customers. Every day becomes a deep dive into my product as an actual user.
This is a great way to start off on a new product.
Really focus on the test plan, make it an early priority
If you are taking over an existing role as test manager for an existing product chances are that a test plan already exists and chances are that test plan is inadequate. I’m not being unkind to your predecessor here, I am just being truthful. Most test plans are transitory docs.
Now let me explain what I mean by that. Testers are quick to complain about inadequate design docs: that devs throw together a quick design doc or diagram but once they start coding, that design stagnates as the code takes on a life of its own. Soon the code does not match the design and the documentation is unreliable. If this is not your experience, congratulations but I find it far more the norm than design docs that are continually updated.
Testers love to complain about this. “How can I test a product without a full description of what the product does?” But don’t we often do the same thing with respect to our test plans? We throw together a quick test plan but as we start writing test cases (automated or manual) they take on a life of their own. Soon the test cases diverge from the test plan as we chase new development and our experience develops new testing insight. The test plan has just become like the design docs: a has-been document.
You’re a new test manager now, make fixing these documents one of your first priorities. You’ll get to know your product’s functionality and you’ll see holes in the current test infrastructure that will need plugging. Plus, you’ll have a basis to communicate with dev managers and show them you are taking quality seriously. Dev managers at Google love a good test plan, it gives them confidence you know what you are doing.