Archive for June, 2010

The “Mythical” QA schedule

I just finished reading The Mythical Man Month by Frederick Brooks. This classic was still amazingly relevant, even thirty some years later.

Some of the tactics he suggests have just been made obsolete by the advances in technology – however, his use of a surgical team as a model for software teams seemed surprisingly agile and modern (not that agile and modern are synonymous). What was most interesting to me was the importance he placed on software testing. In his planning for software schedules, he allots half the project time to testing and bug fixes.

What could you do with that kind of time? Could better fixes be implemented for bugs? Would more bugs be fixed pre-launch? I find that as development schedules get pushed out, it is testing that get shortened.

Squished between milestones that can’t move or running up against a launch date that has already been announced, testing is often a race against time. Sometimes – new projects are hard to estimate for. Sure, you know how long it will take you to run through your test cases, but what about the debugging time? That varies greatly depending on the bugs found. Having half the schedule devoted to testing (or even just a greater percentage) would certainly be a change.

Would such a schedule just stretch things out or get shortened itself? Would it hinder the creativity of the engineers by shortening their time? Or would it work to allow a team with greater importance and visibility placed on testing? A place where quality was not just a “QA” thing, but a collaborative time of testing and bug fixing that could bring the importance of quality at every step of the development process to the forefront.


QA Jobs: Hiring the right person

Who you bring on to your team makes a huge impact on your testing department. My team has been growing this year, and  I am currently in the process of hiring another software QA. The process has been more drawn out than it was last time, with a lot of dead end resumes and interviews that didn’t go as expected. It is hard to be a on a job search, but it is not easy to be on the other side of the table either. You are looking for the right mix of skills, enthusiasm, and personality to both bring something new to your department and to fit in with the group you already have. Last time I went through this process, I wrote about QA cover lettersresumes and interviews – but this time, I am  thinking more about how to find that perfect person.

In my most recent round of interviews, I encountered a wide range of applicants – from out of work developers looking for something to tide them over until they could find a “real position” to recent grads looking for experience and career changes. How do you find the right one? And what will it mean for your team if you chose wrong.?

A guy in my company was talking yesterday about the “two beer rule.” Don’t hire someone you wouldn’t want to hang out with after having two beers with them. This may be a great rule of thumb. Because, interviews aren’t just about finding the right skills, they are about finding the right match. You need someone who can do the job, but also someone who loves doing it. Someone who wants to learn more and try new things and push themselves. Someone who fits in with your team and hopefully someone who you enjoy working with every day. Are there interview questions for that? Or is it just a gut check?