Can anyone please suggest a good test effort estimation template

I am looking for a test effort estimation template. Pl开发者_JAVA技巧ease share with me if anyone has a good template.

There is no template because the estimation process has to be tailored to change. There are different approaches to estimation which consider different parts of the process.

For instance you can take a factor based approach and assume that testing will take 1.5 times development effort. This is a narrow-minded approach as not all testing effort is equal to 1.5 development effort.

Other approaches include doing function point analysis and estimating or estimating how many test cases can be written per day and how many can be executed per day. Do you include data setup in the testing time?

Another approach factors in the resources available, the stability of the environment, the skill of each resource and how much they can contribute to the project.

In all of this you need to consider what is being tested; a ui, a client-server system; does it include distributed services? Are you testing them? Are you just looking at functional testing or do you need to do some measure of security testing as well as load/performance and stress testing? All of which can take considerable time to execute.

Estimation should be done by an experienced tester who has worked on the types of system and preferably within the organisation before.

So there is no one template and nor is there a bunch of variables to fill out to come out with an accurate number of time. Testing takes different amounts of time, each and every time you do it. If you have defects then the rework and retest time needs to be included. How many defects will you raise? Not a question you can answer but if Steve is naively providing estimations to his testers he should also indicate how many bugs are still in there.

The fundamental thing to remember with estimation is that it is an estimate.

Estimating effort is one of the hardest things to do in development and testing. In our company when a developer submits an update (complete with the formal documentation) to the Testing gang, it is the responsability of the developer to estimate the amount of testing required. I do not see how that could be otherwise.

The estimates that I give to Testing are always a bit of a guess, but in general if I develop something for a week then I would estimate 2 days testing. Obviously, this does not need work well in a ll examples and need to be adapted based on the change in question. For example, I might spend a week working on an update that can be tested very quickly.

Estimating test time will cause your head to explode. It's almost easier (and more accurate) grabbing a few dungeon dice and rolling them

A developer could spend 1 hour doing a fix that requires days of testing because that one fix was so integral to the system that all other aspects of it have to be tested.

A developer could also spend 2 days fixing CSS, markup, etc. on a webpage that only requires 4 hours of testing in multiple browsers.

Developers are ok in defining what "Should be tested" but please don't rely on that, because we're prideful and in our minds (well my mind at times) people should just use the program the way it's meant to be used. Why should it allow a username to be Chuck^Norris2010. that user needs to be slapped... I would never test a username like that, I would never think of testing that.

There are many factors of testing, but the one test I know most dev's miss is boundary testing, and flow tests. These types of tests are hard to measure.

You know what needs to be tested. And as time goes on and you keep testing software you will learn how to better estimate the testing because you will know the system.

A developer will be able to tell you what was changed, and what they know needs to be tested.

Estimating isn't something that comes right away. It takes experience and knowledge, and field knowledge.

As you test you'll derive times, and when you record how long it takes you to test each aspect of a project, you'll be better equipped to give better estimates.