Click here to Skip to main content
Click here to Skip to main content

Tagged as

10 Pieces of Advice on Software Test Estimation Time

, 6 Mar 2012 CPOL
Rate this:
Please Sign up or sign in to vote.
10 pieces of advice on Software Test Estimation Time

Introduction

 

Development cycle plays an important role in any project, but test estimation and correct execution are also of great importance. If you adhere to the declared estimation time, you can establish a good reputation with a client.

The main companion in estimation of the software testing services time is your experience. Work experience helps you to prepare a correct time of the estimation for the testing cycle. Certainly, you cannot give some numbers at random. Time estimation should be real and precise.

Factors that can influence software test estimation and some general advice on how to estimate accurately:

  1. Some reserve time

    Add some reserve time to your estimation. Yet, the numbers should be real. Having this extra time in estimation helps to cover any delays that may occur during testing. Plus it enables maximum test coverage.

  2. Take into consideration the bug cycle

    Bug cycle is also a part of test estimation. Sometimes it happens that the actual test cycle lasts a couple more days than was planned. That’s why it’s necessary to consider the fact that test cycle relies upon stability of the build. If the build is not stable, then more time is needed to fix it and therefore testing cycles automatically get longer.

  3. Accessibility of all resources for estimated period

    While doing test estimation, one should take into consideration all vacations/holidays that are planned by the team member, especially long ones in the nearest weeks or in the next few months. This will guarantee that the estimation is realistic. The estimation should also reflect some fixed number of resources for a test cycle. If the number of estimation changes, in most cases it decreases, then the estimation should be reconsidered and refreshed according to the change.

  4. The possibility of parallel testing

    If there are some previous versions of the same product, why not compare the output data? It can profusely simplify your current task. However don’t forget to consider that the estimation is done of the current product version.

  5. Estimations can go wrong – reconsider the estimations regularly in initial stages before you get down to work

    At the beginning of the project, it’s useful to reconsider the test estimation often and make adjustments if necessary. It is not a good idea to make the estimation longer once it’s frozen, unless, of course, there are considerable changes in requirements.

  6. Previous experience can help

    Previous experience from the projects plays a big role while calculating the estimation time. There is a great chance to prevent all the problems or issues that occurred in previous projects. You can analyze the previous estimation, make conclusion as how it was and if it helped to release the project on time.

  7. Mind the extent of projects

    Define the end goal of the project and list all final results. Small and large projects are different and consequently the factors that influence them are different. Large projects involve setting up test bed, generating test data, test scripts, etc, which means that the estimation should include all these factors. Yet, in small projects test cycle, as a rule, contain the writing, execution and regression of test cases.

  8. Whether you are going to perform load testing or not

    If you are going to do load testing, then assign some extra time on performance. Estimation for projects where load testing is involved should be assessed in another way.

  9. Team factor

    Do you know the strengths and weaknesses of the team you are working with? If yes, you can estimate testing tasks more accurately. Consider also the fact that everyone is working with his own productivity level. Some people perform faster than others. However it is not the main factor, still you should pay attention to it, because it can add up to the overall delay in results.

  10. Cooperation with other departaments

    Maybe this factor is not totally up to testers team, but it is also very important. The thing is that tester's work is connected with other specialist's work such as developers and management. If you want to save the time, the cooperation betwee these departaments should be very close. 

These pieces of advice could be useful not only for single testers but for company owners who want to increase their software testing unit’s productivity. And no matter if it is software outsourcing company or not, the productivity of software testing groups is important in all the cases.

Absolutely right that these pieces of advice are not everything it's possible to say on this subject. If you have any ideas, post them in comments.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Qarea Team
QArea - software outsourcing company
United States United States
QArea is a software development outsourcing company that specializes in wide range of professional fields:
 
- custom software development
- software testing
- web development
- mobile applications development
 
Our company has a huge experience in these fields and we are always glad to share our knowledge with others. We are looking forward you to find our articles and tips useful.
 
Visit our website: www.qarea.com
Follow on   Twitter

Comments and Discussions

 
QuestionSimilar article PinmemberMember 936719619-Aug-12 1:21 
QuestionNot an article PinmemberSlacker00729-Feb-12 3:41 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web02 | 2.8.141022.2 | Last Updated 6 Mar 2012
Article Copyright 2012 by Qarea Team
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid