Should We Put Too Much Detail Into Test Cases?

Writing test cases is an essential part of the software testing activities that take place before the actual test execution begins. Hence, test cases must be written by keeping a clear understanding of the requirements in one’s mind. How smooth does a test execution phase goes depends mainly on how well the test cases were written and also depends on how well the requirements were understood.

While putting unnecessary or unwanted details should be avoided into a test case but putting in required and important details play an important role.

You also may like this article: How Not To Write Test Cases

Preparing test cases with required granular details helps in the following key activities:

1. Well written test cases can be passed on to a different tester and hence are tester independent:

Should We Put Too Much Detail Into Test Cases

Imagine a situation where a person who wrote test cases is not available either for the complete test execution phase or during a part of the test execution phase. In such a situation if test cases are self-sufficient in nature and include all the relevant test details required to carry out test execution successfully, it becomes very easy to involve other testers in the execution activity. Helps during the time of tight deadlines. Also, when other team members get involved directly in execution phase with a view to helping out well-written test cases reduce dependency on the primary tester.

2. It is much easier to review well-written test cases:

In an ideal testing world, all the test cases must be reviewed and signed off by stakeholders to avoid any unwanted surprises in the end. If the test cases are written in a simple language without skipping any steps then they are easy to understand and give feedback on.

3. Clearly written test cases also instill confidence in business partners:

If the test cases are clearly understood then business partners or stakeholders know what is being tested and it gives them a sense of confidence that the end product would be as per there requirement.

4. Detailed test cases help in raising defects easily:

If a test case fails and a defect is raised against it then linking a well-written test case with the defect ID also helps the developer in reproducing the defect and understanding the area of the problem. This would lead to a shorter time for raising defects and hence faster test execution.

5. Well documented test cases could serve as a training source for new testers:

In situations where not a lot of training material is available to train new team members and get them on board faster, test cases with the right amount of details in it would help new tester navigate easily through the application and gain the required knowledge. This again takes off the load from senior testers to train new members on the less important topics of the application being tested.

6. It is easy to reuse test cases with the right amount of details in them:

In future iterations of SDLC if a similar project is undertaken then it is very helpful to fetch the test cases from earlier iterations and only modify the required bits to reuse the test cases.

7. Relevant details that should be included in a good test case:

  • Precise test case name – Test case name should not be very long but should define and explain the purpose of the test case briefly
  • Test ID – There should be a unique test id assigned to a test case
  • Pre Requisite – If there is any precondition that needs to be met before the test case execution begins then it should be mentioned
  • Test Steps – Clear and concise test steps should be written as these are similar to a command that needs to be followed by a tester. It should clearly follow what needs to be done.
  • Test data – If there is any particular test data that should be given as an input to the application. It could be for boundary value analysis or for testing if some calculations are done properly by an application or not.
  • Expected results – Once a test step is carried out and required test data is fed then what are the expectations from the application or how an application should respond should be clearly illustrated.
  • Actual result – Actual result is the behavior observed when the test step was executed. This should be recorded and compared with the expected results.
  • Final result – Depending on whether actual result matches the expected result a test step should be marked as pass/fail
  • Defect ID – If a test step fails then a defect should be raised against it and defect ID should be noted against the test step. This helps a lot in tracking defects.
  • Notes – Notes could be entered if there are any follow up items available on a particular test step
  • Requirement ID – A requirement ID should be put against the test step/case wherever applicable which also helps in making sure that all the requirements have been covered through the test cases.

Here is an excel & word test case format: Download Sample Test Case Format

8. Can easily be passed onto the automation team:

If a need arises where some or most of the parts of an application have to be automated then test cases with granular details serve a great deal. Automation teams are usually shared between different testing teams in an organization. Hence, automation testers unlike manual system testers do not have in-depth knowledge of the application being tested. For that reason, they need to be guided or a sufficient amount of detailed information has to be passed on to them so that they are able to create automated scripts successfully. Well written test cases help guide automation testers and save a lot of rework.

9. Culture of only exploratory testing leads to knowledge being stored only with testers:

While exploratory testing is a great way of learning new things about the application under test an environment of only exploratory testing leads to knowledge being stored only with the testers. If a tester moves on to a new role or a new set of work then the knowledge gained by him/her moves along with them leaving a knowledge gap behind.

10. Test cases serve as evidence:

Test cases are not only written to guide during the test execution phase but they have a long term purpose to serve. One of the most important purposes is to serve as evidence of testing that was carried out by testers.

11. In some situations may also help with root cause analysis:

It also helps in backtracking the defects if ever encountered in production or higher environments of testing. A tester could also perform root cause analysis by finding out the real reason behind a defect leak to production. It very quickly tells you if the test condition that led to the leaked defect was tested or not in the first place. If it was tested and passed then are there any environmental issues that led to a defect in a real-life environment.

While writing down test cases with the right amount of details has many long term benefits, there still are certain situations where putting too many details in a test case may have detrimental effects such as:

  1. The situation of tight deadlines or time constraint:

In the real testing world, not all situations are ideal. Hence, there could be a situation when not enough time is left with testers to write down test cases at a granular level. It could be because of a tight deadline. In such situations, a tester will have to get straight to execution once the requirements have been understood. As defects would be uncovered only during execution.

  1. Ad hoc or one-off testing:

If a one-off or ad hoc testing has to be carried out with minimal budget then the main focus should be on the test execution.

  1. It is very important not to lose focus with unnecessary details:

Test cases with unnecessary details tend to lose focus from the main objective of the test case. Whatever the details are entered in a test case should always be associated with the main objective of a test case.

  1. To enter details which could change over time:

Details such as passwords that expire in a few months should not be entered in a test case as this affects the reusability of a test case. Such information should be refrained from being entered into a test case.
You may be interested in reading » 
Over to you:

The act of writing down a test case should be a well-balanced activity and should be performed with keeping important points in mind such as the time available to write down the test cases, need to reuse the test cases, expectations from stakeholders, and other documentation available with the project, etc.


⇓ Subscribe Us ⇓


If you are not regular reader of this website then highly recommends you to Sign up for our free email newsletter!! Sign up just providing your email address below:


 

Check email in your inbox for confirmation to get latest updates Software Testing for free.


  Happy Testing!!!
 

Leave a Comment

Share This Post