"If you were a brand new QA manager ..." (cont)
Friday, December 04, 2009
By James A. Whittaker
More thoughts:
Understand your orgs release process and priorities
Late cycle pre-release testing is the most nerve racking part of the entire development cycle. Test managers have to strike a balance between doing the right testing and ensuring a harmonious release. I suggest attending all the dev meetings, but certainly as release approaches you shouldn't miss a single one. Pay close attention to their worries and concerns. Nightmare scenarios have a tendency to surface late in the process. Add test cases to your verification suite to ensure these scenarios won't happen.
The key here is to get late cycle pre-release testing right without any surprises. Developers can get skittish so make sure they understand your test plan going into the final push. The trick isn't to defer to development as to how to perform release testing but to make sure they are on-board with your plan. I find that at Google increasing the team's focus on manual testing is wholeheartedly welcomed by the dev team. Find your dev team's comfort zone and strike a balance between doing the right testing and making the final hours/days as wrinkle-free as possible.
Question your testing process
Start by reading every test case and reviewing all automation. Can you map these test cases back to the test plan? How many tests do you have per component? Per feature? If a bug is found outside the testing process did you create a test case for it? Do you have a process to fix or deprecate broken or outdated test cases?
As a test manager the completeness and thoroughness of the set of tests is your job. You may not be writing or running a lot of tests, but you should have them all in your head and be the first to spot gaps. It should be something a new manager tackles early and stays on top of at all times.
Look for ways to innovate
The easiest way to look good in the eyes of developers is to maintain the status quo. Many development managers appreciate a docile and subservient test team. Many of them like a predictable and easily understood testing practice. It's one less thing to worry about (even in the face of obvious inefficiencies the familiar path is often the most well worn).
As a new manager it is your job not to let them off so easy! You should make a list of the parts of the process that concern you and the parts that seem overly hard or inefficient. These are the places to apply innovation. Prepare for nervousness from the developer ranks, but do yourself and the industry a favor and place some bets for the long term.
There is no advice I have found universally applicable concerning how to best foster innovation. What works for me is to find the stars on your team and make sure they are working on something they can be passionate about. As a manager this is the single most important thing you can do to increase productivity and foster innovation.
In our test practice, we are facing the problem to save test case doc in one place and test code another place. In a long run, how to keep them synchronized is a problem. Any idea to do so?
ReplyDeleteDo you have any thoughts regarding software quality assurance and certifications? Are there industry standards for software QA or any certs that will help a person advance in the field?
ReplyDeleteMinglei, one thought is to keep the test docs with the test code under source control. Let's say in the form of javadoc where functions = test cases and classes = test suites. That way, docs can be auto-generated on commits.
ReplyDeleteJames,
ReplyDeleteThanks for 2 great posts.
What about that part of you which is test team specific - the administration, motivational stuff, the mentoring bit etc.
And the other bit which keeps your bosses content and silent or at bay... via reports with pretty graphs..
And what about retrospectives and so on.
The first year I worked after University at Ericsson the number of offices seats was short so I got a place right beside the QA for the project.
ReplyDeleteThat tend to give you a view on system development that gives a rather big priority on defence programming.
It affects you coming straight from the university sitting beside some old - well not bitter - but experianced tester who goes through code he often feels lack any quality at all.