Interview Questions and Answers for QTP (Quick Test Professional)

Friday, October 28, 2005

The Testing Estimation Process

One of the most difficult and critical activities in IT is the estimation process. I believe that it occurs because when we say that one project will be accomplished in such time by at such cost, it must happen. If it does not happen, several things may follow: from peers’ comments and senior management’s warnings to being fired depending on the reasons and seriousness of the failure.

Here are a few rules for effective testing estimation:

Rule 1: Estimation shall be always based on the software requirements
All estimation should be based on what would be tested, i.e., the software requirements.
In many cases, the software requirements are only established by the development team without any or just a little participation from the testing team. After the specification have been established and the project costs and duration have been estimated, the development team asks how long would take for testing the solution.

Instead of this:
The software requirements shall be read and understood by the testing team, too. Without the testing participation, no serious estimation can be considered.

Rule 2: Estimation shall be based on expert judgment
Before estimating, the testing team classifies the requirements in the following categories:
- Critical: The development team has little knowledge in how to implement it;

- High: The development team has good knowledge in how to implement it but it is not an easy task;
- Normal: The development team has good knowledge in how to implement.

The experts in each requirement should say how long it would take for testing them. The categories would help the experts in estimating the effort for testing the requirements.

Rule 3: Estimation shall be based on previous projects
All estimation should be based on previous projects. If a new project has similar requirements from a previous one, the estimation is based on that project.

Rule 4: Estimation shall be recorded
All decisions should be recorded. It is very important because if requirements change for any reason, the records would help the testing team to estimate again. The testing team would not need to return for all steps and take the same decisions again. Sometimes, it is an opportunity to adjust the estimation made earlier.

Rule 5: Estimation shall be supported by tools
Tools (e.g a spreadsheet containing metrics) that help to reach the estimation quickly should be used. In this case, the spreadsheet calculates automatically the costs and duration for each testing phase.
Also, a document containing sections such as: cost table, risks, and free notes should be created. This letter should be sent to the customer. It also shows the different options for testing that can help the customer decide which kind of test he needs.

Rule 6: Estimation shall always be verified
Finally, all estimation should be verified. Another spreadsheet can be created for recording the estimations. The estimation is compared to the previous ones recorded in a spreadsheet to see if they have similar trend. If the estimation has any deviation from the recorded ones, then a re-estimation should be made.

QTP and Winrunner Questions and Answers
Contact: qualityvista @

Post to: IpadIt! | blinkbits | blinklist | Blogmarks | co.mments | | | digg It! | Fark| feedmelinks | Furl | LinkaGoGo | Ma.gnolia | Netscape | Newsvine | Netvouz | RawSugar | Reddit | scuttle | Shadows | Shoutwire | Simpy | Smarking | Spurl | TailRank | Wists | YahooMyWeb!


At 9:07 PM, November 09, 2005, Anonymous Brad Kuhn said...

Excellent points, but of course you're preaching to the choir :)

Two things that you didn't address which have always interested me:
- What do you do when the schedule is handed to you (typically by management working backwards from the desired end date)? I've never been in a situation where I could refuse a schedule, but I always try to document my reasons/issues with dictated schedules.
- You're in test for political reasons, and you probably shouldn't be, and things of course are not going well. How do you at that point provide an accurate estimation for completion.

I'm also a big advocate for maintaining estimates & actuals over time. You can pretty quickly get to a point where you can assess the quality of your estimations, which only helps to make future ones that more accurate.

At 10:22 PM, June 09, 2008, Anonymous Anonymous said...

This article is a cut and paste of a snipet from an article by Antônio Cardoso. You should give credit to whom it's due.


Post a Comment

<< Home