Knowing the details
I've seen a lot of test managers (and/or testing project managers) who don't know the details of what's happening in their projects. They attend the meetings, keep plans up to date, give out assignments to the team, and make sure all the charts are up to date. But they never really develop a working knowledge of the project or a feel for the testing. I don't like to work that way. When I'm managing a testing project, I want to know the details.
There are a couple of key ways I do this:
I think developing my understanding of the defects is the most important aspect for me. It helps me develop an intuition about the software and it's state. It also keeps me in tune with what work is actually taking place. They other stuff is important, but if I really want to know what's going on, I look at what's getting executed and what's coming out of that work.
There are a couple of key ways I do this:
- I try to contribute to writing, editing, or (at a minimum) reviewing all the test strategies, plans, and schedules (many of the larger projects I've worked on have several).
- I review test cases, scripts, charters, or results (depending on the team's approach). I also review the test data being used.
- I read the defects - all of them. I want to know where the issues are, what they are, and what they look like.
I think developing my understanding of the defects is the most important aspect for me. It helps me develop an intuition about the software and it's state. It also keeps me in tune with what work is actually taking place. They other stuff is important, but if I really want to know what's going on, I look at what's getting executed and what's coming out of that work.