Market—The targeted constituency of users this software is intended for. For example, “the finance department”, or “medium sized accounting firms”.

Users—The actual users who will use the software. Who are the users? What do they do? What are their motivations for using our software?

Tasks—What are the tasks that the users will use this software for? What are some typical tasks in their work?

Information—What does the product tell me about the tasks it automates, and how I can perform them?

Implementation—Is the software easy to use as a first time user? Is it reliable? Can I easily implement the tasks given the information and design of the product?
Under “Market”, I want to know:
- what are we promising?
- do we have written agreements?
- what do our users expect?
- what tasks do they perform?
- how does our software help them address that?
- what are our competitors doing?
- how do similar products address automation in this space?
- what are our sales targets?
and on and on… :)

Great article! I’ve found estimation to be a tricky business because there are so many *what ifs*. One company i worked fort used a simple spreadsheet for test estimation and insisted on using an *industry standard* 6 hours per day (i was sceptical of this figure as i haven’t found any reference in relation to it) to calculate estimation. When i think back to it, i don’t think we were even *close* to the estimate when testing finished (i know its an estimate but even a ballpark figure would’ve been more useful!. Often when the *estimate* was *calculated*, we were *held* to this timeframe which led to testers overly inflating testing effort just to be safe (sure you build some fat in but….). Another place wanted an *exact estimate* for each individual test case (100+ test cases) - the rebellion rose pretty quickly and the PM only just managed to avoid a coup d’etat! And yet others are not really interested and just plough ahead.
When i’m asked to estimate i tend to rely on my gut feel and then i remind myself that an estimate is exactly that! Thanks for the blog - have fun at CAST2008!

The point of the article was that I don’t recommend using templates for estimation. Instead, I provide an example of how I might approach estimation for a project and I walk through the steps that I take.

If you find that you’ve been repeatedly estimating the same type of project, then you may find that you’ll save time with a template. I’ve found that I’ve rarely had two projects that were so similar that I would be able to reuse much documentation from the previous project.

Thanks,
Mike

Thanks for the comment. You got me thinking with that one. I’m wondering why that wasn’t included in my original list; because I too feel that it’s important.

After thinking about it I think I don’t /explicitly/ look for methodology because I find I have to train (or untrain and retrain) most performance tester to use my methodology regardless of whom I hire. I just assume that we will need to spend time talking methodology and theory. All I want to know is that they know the basics (math, modeling, infrastructure, coding, etc…) so that we don’t get bogged down in those details.

But your point is well taken. I too think it’s important. And I certainly would and do ask potential candidates about what methodology they use.

Thanks,
Mike

To me, knowledge of performance testing methodology is more important than knowledge of specific or preferred tools. I assume that if the candidate has half a brain, that he/she can learn any tool.