Is there any estimation technique that can help us to estimate the number of needed test cases in traditional software projects? For example, we have a Software requirements specification (SRS) with 200 use cases; can I say "we need 200 *10 = 2000 test cases", as a rough estimation?

We need this estimation to write a test plan for the project manager. Sometimes we don't fully understand the application from the SRS because of having spent too little time performing test planning.

  • What do you mean by "end user testing"? In my experience, this refers to validation. The end user has a set of needs or expectations that have been expressed to a development team and "end user testing" or validation is totally directed by the end user to confirm that the thing actually built will meet their needs. How long do they need to execute their testing to give them confidence that the delivered system will meet their needs?
    – Thomas Owens
    Jul 31, 2019 at 18:28
  • i mean with "end user testing", that the software is being tested by testing team to be confirmed and ready to publish on user PC Aug 1, 2019 at 16:53
  • That is not consistent with any definition of "end user testing" that I've ever heard, especially since your testing team is not the end user of the system. What are you are describing is a form of verification.
    – Thomas Owens
    Aug 1, 2019 at 17:01

1 Answer 1



There's no single formula for determining how many tests a set of specifications will require. However, you can estimate level-of-effort and set quality targets based on your test plans, provided the people making the estimates are the ones who will be doing the actual work.

The Testing Pyramid and Its Effects on the "Iron Triangle"

There is no universal formula for how many tests you need for each specification. That will vary based on the product, the frameworks that you're using, the complexity of the specifications, and the criticality of each unit of functionality. However, you can get reasonable estimates by asking the actual task performers (e.g. the developers and testers who will be doing the work) to estimate the amount of testing they anticipate for each block of work on the project plan.

In general, you should expect that an agile shop will have many unit tests, and very few manual tests. For example:

Traditional vs. Agile Testing

Sliders and Trade-Offs

There are many variations of the testing pyramid, and the details of what belongs in each layer can vary based on your product, industry, and process. However, experienced developers and testers who are invited to collaborate with you on the planning and estimation of the project can often provide reasonably-accurate estimates regarding the level of effort involved for each phase or component of testing, and help you make the necessary trade-offs between:

  1. percentage of test coverage
  2. speed of test development
  3. speed of test execution
  4. speed of development
  5. speed of regression testing
  6. speed of defect reproduction/isolation

These factors, which are often complementary or opposing sliders, will impact your project's costs, schedule, and quality. It will also have a major impact on your technical debt and defect rates, depending on what the team and organization agree to.

Incorporate Test Metrics into the Definition of Done

Your Definition of Done should always include agreed-upon targets for test coverage. The rest of the testing details are likely to be more of a negotiation and a set of guidelines than a fixed percentage.

See Also

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.