- Test estimation is based on the requirements specified in the
functional specs. The Test estimation is initially prepared before
starting the testing process.This test estimation includes the time
taken for test cases preparation and execution of test cycles.
- Test
estimation determines how much time testing will take. This is the
total time of test case preparation + test case execution + test results
documentation. Generally it would be 40% of development time of that
particular requirement.
- Test Estimation will be done based on three attributes.
- Size
- Effort
- Schedule.
- Size - The size of the project needs to be determined in order to estimate the testing. Size can be measured in 3 ways
1. LOC (Lines of Code)
2. Function Points (Functions Features in the application has to be taken as inputs)
3.
No. of Screens/Forms. While estimating the size we should take the time
required for automation and number of configuration the application to
be tested.
- Effort - Once the Size estimation is done
the effort required to be estimated which can be done using the Size
estimates + Productivity (Time that can be taken for Test
authoring/execution per organization standards) +amount of time takes to
test the product on multiple combinations.
- Schedule - The
testing should be categorized into different phases and based on the
effort estimated for the project the schedule will be estimated. It will
be done using the WBS (Work Breakdown structure) with start and end
dates for each activity.
- WBS units can be taken while estimating the Size and Effort also.
- According
to the British Computer Society International Systems Examinations
Board Test Practitioner course syllabus, "a test estimate is an
approximate calculation or judgement, typically based on the
professional understanding of experienced practitioners".
- All of
us typically do test estimation, but may not even realise we are doing
it. We may, for example, think of a test to execute, and then because we
judge that it would take about two hours to complete, we plan it for
tomorrow because we only have an hour until we have to travel home.
- Some
people talk about using "industry averages" in estimating because they
don't want to take the time to proper define the requirements, design
and approach. They just want to move as quick as possible into the
Coding phase; Here not using "industry averages" as they tend to be too
generic and quite often recommend less time than what is really needed.
- Applications
today are more complex than ever and if a Test Engineer is to do a
thorough in-depth test effort, it will take a lot of time to test. A lot
of companies will make no effort to really figure out the true test
effort and go with the industry average that QA will take 30-40% of the
development time. However a developer could take 10 minutes to make a
change in a critical part of the system (like the report engine of a
financial app) and this would imply that QA time would only be 4 minutes
which everyone would laugh at. Although they should laugh at the fact
that the developer only spent 10 minutes developing before turning the
project over to QA – what happened to the Unit Testing? So obviously
industry averages are not very useful unless it is a big project and you
are pressured to throw out an estimate for some meeting – then go with
the 40% of development time. Otherwise if you have the ability to do
your job correctly then put some meaningful effort into looking at past
test efforts.
- The
development team cannot prioritize the modules based on the
importance/priority. Ultimately leading to the misinterpretation of
functionality flow
- The project management will also be affected
since there will be long time plan due to the lack of clear idea about
the interfaces.
- Testing is compromised as the coverage is not verified at every stage of the life cycle.
- In the case of delivery team it is really hard for them to declare that the product is ready to be demonstrated.
- Finally
maintenance becomes really tedious as identification and analysis of
the impacted work products and requirements becomes tedious
