Estimating Part II: QA

posted Mon Apr 23 17:15:37 +0000 2007 - permalink

Estimating the quality assurance time on a software project is a tricky business. Despite hallway meetings, iterative demos, and meetings to try and nail down exactly what a project is supposed to be, a little padding can go a long way. So let's get two key points down in estimating how long quality assurance is going to take in a small team environment without dedicated quality assurance engineers.

First, we have the developer working on the project setup the initial testing document. (Someone else will actually be doing the testing -- sales, customer service, etc). Yes, this can eat up up to several days of developer time. But the person working on a project is most likely to identify corner cases that an outside case writer might not see. (It's another thing entirely if you have qualified QA engineers on staff; for small teams, this usually isn't an option.) Also note that you may need to proof these documents before assigning them to another staff member (or sending to your project manager).

Second, in an effort to provide some flexibility (aka Agility), QA has to be scoped based on a variety of factors: how large the project is in terms of moving parts, how many of those moving parts have various inputs (for example, a recent project needed approval from three department heads, meaning that we will probably get the changes after coding is complete), and whether or not refactoring has been attempted in other subsystems (which means they have to be QA'd again as well).

This brings up a difficult proposition. QA estimation time can be used for insulation to remain agile on a project that requires high flexibility, but then again it shouldn't because then you're breaking your time trials and not collecting accurate data on how your team is really performing (see my previous post), which in the long run will hurt your team (especially when marketing is already ramping up their engines on your hot new product line).

Team harmonics play into this at critical points. First, your team has to believe that the original estimate can be completed. Your judgement, whether via multiplier or some other quantification of the dynamics of the project, will be critical in determining the QA estimation period in a small team, and as changes come in on a dynamic project, you'll need to judiciously carefully allocate time that bleeds into QA. Your relationship with your project manager will be clutch when this occurs.

And don't forget -- a 4 hour per day work schedule estimation on projects will allow you additional flexibility to protect people working on a critical project from some maintenance tasks to allow them to hit schedule. It is extremely difficult, but separating out the hours worked on non-estimated items can give you great insight into your next project.