So, in a totally unexpected turn of events, I’ve been crowned the interim test manager for the next five weeks!
To make a long story short, our organization doesn’t have a structured testing group. From before the time I’ve been here until now, developers were expected to both write code and do testing (in this case, “write code” == write code + unit tests + other styles of automated tests, and “do testing” == do whatever’s needed to find new bugs). Because we’ve got a very important release looming five weeks from now, and because we put out a few large fires after the last release, management decided to enlist a testing group until at least five weeks from now. And — to make this great news even better — they’ve decided to let me take on the effort.
They’re pretty much letting me do whatever I think is best. There’s a few limits to what I’m able to do in this position, but the most exciting questions were “Tim, do you want to lead the testing effort?” and “Tim, how many people do you need?”
I’m still doing research to figure out what would be best in our context, but my inclination is to do some form of session-based test management. My guess is that it’ll turn into the Bach brother’s SBTM with a little bit less paperwork. Although we may not be using James’ test management software, the idea though, is the same: create charters, do sessions, debrief… rinse, and repeat.
If this position turns out to be something longer than five weeks, however, there may be a chance we can keep more records a la the Bach brothers’ SBTM. I’ve talked to one of the stakeholders already, and — if that becomes a reality — we would (could) release all or most of our session sheets into the public domain. What this means is, since NDA’s don’t exist in our organization, we could amass the first publicly available database of session-based testing records. From a research/bleeding edge point of view, this could get very cool very quickly.
Since I’ve needed to do some research in order to assess risk and prioritize the testing effort, I’ve been holding meetings with stakeholders in order to get their point of view. When talking with them, I’ve found these questions to be very helpful:
- What fires have we put out after previous releases?
- What do you envision to be new problems in our next release?
- If you had to subjectively choose areas you were interested in — areas in the software you want to be the *most* solid — what would you choose?
- If, hypothetically, parts of our system were to actually fail after our next release, what failures do you expect to be the most damaging?
I’ve asked these questions to five important stakeholders so far — two devs, two managers, and the guy who answers the phones — and I’ve gotten great responses, and some great ideas for initial charters.
All in all, I’m very excited, and I can’t wait to see what comes of these next five weeks.
UPDATE, 3/1/08: When I described who I talked to to get information, I mentioned “the guy who answers the phones.” To his credit, this guy does much, much more than simply answering phones, and he is a real asset around the office. I decided to describe him that way in order to emphasize his user-facing role: he is the sole person responsible for talking with users. Because of this, he is privy to a wealth of information that others generally don’t have, and is therefore extremely valuable to this project.
Experiences, New York, Work
Recent Comments