| Shrinik 2005-10-21, 3:59 am |
| Hi,
I am interested in knowing about your method of estimating testing
effort. This is something that test professionals world over are
struggling to find suitable answer (IMHO).
1. What are these categories of testing that you use to estimated test
effort?
2. What is the life cycle model for testing you assume - lifecycle
model - where there is an independent test team all along from the day
1 of the project team till UAT?
3. How do you estimate for test case design and review?
4. Do you estimate for bug logging, followup and verification?
5. Till development team hits code complete milestone (they are done
with the implementation of what all need to go into that release) - the
schedule is development driven, there after it is test driven. That is
to say they are only bug fix cycles. how do you estimate the effort
for these cycles?
6. What are the productivity factors you use for various activities?
7. At what stage/phase in project you perform this estimation?
8. how often you revisit the estimation ...
There are many more such questions regarding test estimation.
One reason that makes test estimation complex as compared dev estimate
is that
test is chasing an unknown thing - "prove that software is of good
quality" or "Software works". If there is finite number of ways to
build a software ( at least for software development - business stand
point) there are infinite ways to prove that software does not work.
Here is where complexity comes in.
Your views ansd suggestions are welcome.
Shrini
Wayne Woodruff wrote:
> On 19 Oct 2005 05:56:42 -0700, "Michael Bolton"
> <google@michaelbolton.net> wrote:
>
>
> #1. We have out tests broken up into various categories. We measure
> the time it takes to execute each category. After several cycles, you
> will have a very accurate representation. We can predict within 1% the
> test effort required for each catrgory.
>
> #2. You can use defect prediction models to estimate remaining
> defects. They do work, but require a lot of training an understanding
> to effectively use the models.
>
> #3. some organizations use Defect Density as a "Quality Index".
> Sounds like you are implying that the quality improves if you test
> more. Quality can't be tested in, although most companies thing that
> way. Quality needs to be planned into the project from day 1.
>
>
>
> Wayne Woodruff
> http://www.jtan.com/~wayne
|