Test Estimation - Software-Testing

In article <1144668281.954217.324040{}i39g2000cwa.googlegroups.com>, Azam
<rasheed_azam{}hotmail.com> writes
>Is there any specific formula exists for test estimation or it's all
>based on one's experience.
>

(((what you think you need /2 ) +
(What management want to budget * 2) )/2) - 1


I am not sure if it needs a smiley or it is too close to the truth.....

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris{}phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Azam wrote:
> Is there any specific formula exists for test estimation or it's all
> based on one's experience.
Assuming you have already reviewed and are pretty happy with the
specification, note down the high level types of tests needed and how long
it will take to write & execute all your tests assuming nothing goes wrong
(this requires experience to guess well).
Then double that number, because things will go wrong.

If you don't have a spec yet, grab an ****yst and coder and try to
understand as much about what you are going to be testing as possible.

Present the breakdown of types of test and timescale against each one to
your boss, this should help them plan better.
Don't agree to reduce your estimations to fit in with your bosses plan,
there are reasons why software is often delivered "late", this is one of
them.
Be ready to answer the question "What can we do to reduce the time it takes
to test?".

--
STE ;¬!

Azam wrote:

> Is there any specific formula exists for test estimation or it's all
> based on one's experience.

A project should run in very short iterations with a "release" at the end of
each one. The releeas either a deliverable or a dress-rehearsal for one,
with installers, full QA assessment, and automated tests for every feature.

The estimate for the next iteration should be very close to the actual for
the last iteration.

Running in long iterations makes everything hard to estimate.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

As mentioned before:

Estimating test creation would vary on the tool or technology you use.
The nature of the app will make it easier or harder on your estimation
of writing the tests.

But this should be your only cost, execution should be free and fast.
Or you aim for this. The maintenance release teams will thank you for
that.

Hello ,

You need to breakup the testing task as follows,

a) Time taken to perform sanity testing = x days/hours
b) Time taken to start automated testsuite = 30 min (approx) [Note: The
testsuite may run for 1/2 days]
c) Time taken by the testsuite = [Please refer above]
d) Time taken to perform manual testing (if any) = y days/hrs
e) Time taken to create test reports = 4 hours (Approx)
f) Time taken to file/report defects = z hours
g) Time taken to get the test report reviewed = w hours.

a + b + c + d + e + f + g is your test estimate.

Best Regards,
Vivekanandan M

I started from the point that there was no manual testing. The bigger
the manual testing % of the effort the less reliable the estimate.

The one point that I see is that if you need to start your automated
tests, they are not automated :-}

Their results, reports should be summarized and stored to track trends
automatically too.

I have heard "sanity testing" in the context of a short test run to
verify if a build is good enough for a full run. Usually no more than
an 1/2 hour.

Maybe you switched a and b? Some companies use different terms.

There is NO good enough formula.
It's all about the experience.
Your as a lead, you should know your estimation possible errors.
Your team each one at what is real good, what are their weakness. What
is they would have to learn, are they good at learning new things?
More complex is project more erroneous will be your estimation.

I teach and practice James Bach's Session-Based Test Management (as do
some of the people that I've taught). You can find out about it at
http://www.satisfice.com/sbtm.

Don't discount this: in many cases, those who are asking you for an
estimate already have a release date in mind. They'd like to make the
"test phase" six weeks, and they'd like you to agree to that. Towards
the end of the schedule, the realization strikes that the developers
have slipped three weeks, so now the project sponsor wants to compress
the testing phase to three weeks, and they'd like you to agree to that
too. So one way of answering the question is to say "six to three
weeks".

But what's really happening here?

- During the "test phase", do developers stop coding? No, they
continue to code. They probably change their focus to fixing. On the
first day of the "test phase", they're either fixing things that were
found earlier, or starting to fix things as they come up. They
typically don't fix bugs as fast as testing finds them, but that's not
certain, just typical.

- Before the "test phase", do testers test? If so, what's special
about the "test phase"?

- Between the time the "test phase" is over and the time the product
ships, do testers keep testing? In my experience, they do.

- After release, do testers keep testing the current product, or do
they start working on the next one? Testers might do some fix testing
or workaround testing after release, but in my experience, they're
usually on some other product, or a new version of the just-released
product.

Conclusions: a) It's not really the "test phase"; it should be called
the "fix phase".

b) Things that could prevent a capable tester from testing a product at
any time in the development process include i) absolutely nothing is
available to test; ii) the tester is assigned to some other product;
iii) management has enough information to make the decision to ship.
But most of the rest of the time, the tester should be able to do
something, to ask some question about the product.

c) Give that there are infinite tests we could run, we could always do
more testing. And given that there are finite people that can run the
tests, we can always use more.

d) Therefore, one completely sane way of estimating the test effort, in
my view, is to say, "we'll take as many testers as you're willing to
give us, as early as we can get them, and all the time you're willing
to give us before release, and we'll do the best testing that we can in
that timeframe."

That has the added benefit of being 100% accurate.

---Michael B.

hi,

i need the software testing model project,i studied testing tools
course,i finished B.Sc in 1st class,i like to work software company, if
u know any vacancies,if u give a chance i show my best.


thanks,

prabhu