I am having problem in writing test cases from a functional spec document. The doc has many different sections and each section has sub-sections, each one describing the new functionality or modification of existing features. My web application has many different user roles like "Administrator, user etc. Each role can view different reports. If I write test cases for each user role/reports/functions, then number of cases would be in the thousands.


Also, should I club similar test cases? Please suggest a better way to write minimal no of test cases.

  • This is black box testing? And you're doing function testing, not system/integration testing? Commented Apr 4, 2016 at 20:30
  • @Kevin, yes it black box testing...it is a new enhancement that would be added to the application in release.
    – matrix
    Commented Apr 5, 2016 at 7:23
  • For modifications and extansions you do regression testing to make sure that everything is still working fine after changing the requirement (sometimes you don't even have to change the existing test cases). So, as you wrote it is an enhancement you should look at the existing test cases and use the insights to create the new ones. Commented Jun 24, 2016 at 9:45

2 Answers 2


You could use this IEEE 829-1998 Test Case Specification Template as a guideline to create the test case. Anyway, in designing test cases from specification based view, there are a few techniques you could apply such as Boundary Value Analysis, Equivalent Partitioning, to minimize the number of test cases created but still covers important areas. You could see the explanation of Boundary Value Analysis and Equivalent Partitioning on this link.

Hope this helps.


To start with I would want to know if the functional requirements outline some type of data that state the function is working as documented.

I would then use a test case template that used the information above and then break down the expected results for each role.

it would also be good to organize your test cases to be directly related to the functional requirements to help with your coverage analysis.

Hope that helps.

  • The expected result of a functional requirement should be part of the requirements (document). If not, talk with your requiremens engineer because otherwise your test cases will fail later most likely because tester and developer (and others) have interpreted the requirements differently. It's critical! Commented Jun 24, 2016 at 10:09

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.