Home > Archive > Software Testing > April 2006 > Test Estimation
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| Is there any specific formula exists for test estimation or it's all
based on one's experience.
| |
| Chris Hills 2006-04-10, 8:20 am |
| 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 \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
| |
| STE ;¬! 2006-04-10, 8:20 am |
| 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 analyst 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
[url]http://www.greencheese.org/Z Land[/url] <-- NOT a blog!!!
| |
| Jose Cornado 2006-04-10, 7:07 pm |
| 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.
| |
| Vivekanandan M 2006-04-11, 8:13 am |
| 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
| |
| Jose Cornado 2006-04-11, 8:13 am |
| 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.
| |
| dumitru.corobceanu@gmail.com 2006-04-11, 8:13 am |
| 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.
| |
| Michael Bolton 2006-04-12, 4:06 am |
| 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 ws, and they'd like you to agree to that. Towards
the end of the schedule, the realization strikes that the developers
have slipped three ws, so now the project sponsor wants to compress
the testing phase to three ws, and they'd like you to agree to that
too. So one way of answering the question is to say "six to three
ws".
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.
| |
| satishraju.k@gmail.com 2006-04-12, 7:08 pm |
| Azam,
I don't think some specific formula exists for the test estimation.It's
all about experience
While doing test estimation we have to consider these, as per my
experience.
1.How clear the requirements are
2.What kind of Testings planning to do
3.Efficiency of testing Team
4.Is the team is dedicated to one project/Product or multiple
5. Cycle speed/interval( Bug report and fix again report and fix
.....etc )
6.What are the deliverables, organisation expecting from testing team
Regards
Satish
| |
| Shrinik 2006-04-14, 4:11 am |
| Michael brings an imporatant issues related to "estimates in testing".
That is the purpose of making estimates, who is asking for estimates
and how this estimate be possible used/misused downstream?
I have been in such situations where I was asked to provide "expert
opinion"or estimate for testing of an application, when I gave an
estimate which thought was *resonable* in the context - almost 99% of
the times, my manager shot me down with his possible date. So when
somebody asks you for an estimate - you shoot back saying "do you have
any specific deadline in mind?" As I have seen in practice, all
managers who ask for estimates typically have a *date* in mind. Once
you know that date - working towards estimate will be reduced to task
of fitting all planned testing actities in the specified time band.
On a lighter note - I do feel that giving estimates is nothing but
getting into a trap - there will external factors because of which you
will not get the required time to do testing then there will be a drama
of "Selecting Critical test cases" and trying complete
most_important_features of the application. If this is a case in majory
of scenarios -- why to worry about estimating when at the end - all one
need to do is - "test what is possible in given time"
Test estimation is like a mirage in desert ...
Shrini Kulkarni
http://shrinilblogspot.com
| |
|
| Shrinik wrote:
> Test estimation is like a mirage in desert ...
I estimate it will take a w to get you that estimate.
--
Phlip
[url]http://www.greencheese.org/ZLand[/url] <-- NOT a blog!!!
| |
| Steve Devonport 2006-04-18, 4:08 am |
| Test Estimation is the bane of my professinal life!
In my experience every company, programme, project, test team have
differing ways of providing an estimate. Many times I've been asked to
provide an "estimate" after just 2 days into a new project (with a new
team) of how long the testing effort will take. One approach I've
recently taken is to ask when the "ship date" is then ask what "project
related" tasks must happen before we can ship the code/product. By
continously asking this type of question I eventually arrive at a date
whereby testing has to finish - according to the stakeholders, in that
particular meeting. So by a natural regression of steps I have deduced
a timeframe for testing and therefore can focus my team on covering the
"most important" areas of functionality (important=risky, changed, new)
to the stakeholders. This does not imply that we will have covered ALL
the documented requirements, to me, it identifies that we will deliver
the most important aspects of the project within the required timeframe
as stated by the stakeholders. Of course if the stakeholders want us to
test more then they realise they have to "find" more time, either
before or after the planned start/end of testing. Which is good for my
team!
Whilst not perfect and not suitable for every test team/project/company
- it has worked for me and provides me with a different mechanisim for
providing the same piece of information - besides it's miles better
than providing a WAG.
| |
| suvrab@gmail.com 2006-04-25, 10:05 pm |
|
Azam wrote:
> Is there any specific formula exists for test estimation or it's all
> based on one's experience.
To Answer your question.....
Yes, there's formula that exists for Test Effort Estimation. But, based
on the development technique, one needs to fugure out whether the
formula can be used or not. If the development team uses Functional
Point method for estimating the LOC, Test Point method can be used for
that project in order to arrive at an estimated Test Effort.
Following is the method used for the Test Point Analysis:
1. Based on the number of Function Points (the total # of Function
Points should be obtained for the testable code from the Development
Team), calculate the Dynamic Test Points.
2. Based on the Static Quality Characteristics, one needs to calculate
the Static test Points.
3. The Total number of Test Points are arrived by using a formula on
the Static and Dynamic Test Points.
4. The Total number of Test Points derived is then used along with the
"Environmental Factor" and "Productivity Factor" to get the Primary
Test Hours.
5.Finally, the total number of Test Hours is obtained by adding an
Allowance "Control Factor" to add the Planning and Control Hours with
the Primary Test Hours.
You can refer the following paper to understand the TPA method in
details along with the Formulae used to obtain the effort estimation:
Test Point Analysis: A Method for Test Estimation by Erik van
Veenendaal.
Regards
-Suvransu Basu-
|
|
|
|
|