Testing effort vs. coding effort

Usually people draw comparisons between testing effort and coding effort (which some also call Development effort whereas Development is the whole process of implementing requirements which includes testing). To use this as a trick question, I tried asking this in one of the recent interview session:

“For a given feature/user story, Programmer estimates that it will take 3 weeks to write code. How much time you think, you’ll need to test this feature?”

I got answers like:

  • At least one week of time. This is based on my experience.
  • I’ll ask for half the time as it takes at least 50% of the time to test.
  • To be on the safe side, I’ll ask for 60% time as my experience says it usually takes 50% time and then we may encounter more problems in a given feature.

Clearly the tester is thinking of testing effort is directly proportional to the coding effort. Even some people also have 10% unit testing tax formula or some suggesting law of diminishing returns on testing.

For me testing effort is not proportional of the coding effort and the answer is “it depends” :). Let me explain with two experiences.


Few years ago, with introduction of Windows 64bit versions, one of the teams I know took the approach to let their applications run as 32bit applications in 64bit environment. The did minimal changes to announce that their software “supports” 64bit and then asked the testing team to confirm each and every features “works” as expected. Easily in this case the testing effort was way more than the coding effort given that the application was a huge one.

In another project, one of the teams was having performance issues in their system. They decided to flip the design scheme to take it from ‘attaching B to A’ to ‘create A and link with B’ and it took them couple of months effort to change all the code to get in line with this new design philosophy. Once done, testing team was asked to do performance benchmarking. As the UI layer never changed, the set of tests were executed without any issues and new numbers were reported in a few days. In this case testing effort was almost not notable as compared to the coding effort.

So when you are asked next time, “how much time it will take to test?” , you should first understand what the problem is you are asked to test and then negotiate a good number.

Do you ever developed a formula for testing efforts? And do you still want to use it?



7 responses to “Testing effort vs. coding effort”

  1. Shahrukh Chaudhry says :

    So Right… Totally Agree. Most of the testers face these estimation issues. They should understand the Problem/Requirement first before committing any estimates.


  2. rumadak says :

    Completely Agree. even I have examples for both the cases when testing efforts were way more or way less than the coding effort.
    As a tester, I don’t look at the dev effort while estimating. It’s an independent thing.

    Liked by 1 person

  3. Rajesh says :

    It is definitely contextual. However, if we consider a traditional development project, the percentage of efforts for testing (for each testing phase) is something that is required for providing VROM estimates.


  4. Qamar Tarar says :

    It all depends on the number of Features/requirements and their context, you are going to test as well as the Project Phase. In requirement or concept Phase you have to verify the Contents, define testcases, make Testplan etc. But in later Project phases, you have to test more than what is in actual sprint, like Regression Testing, Testcases optimization,Defects verification, perform testruns and System tests.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.