One of the key deliverables or a major activity for a tester is to produce test cases and defect reports. Different teams follow different styles of documenting test cases and these test cases are further used not only by testers but also by the development teams as well as the project management teams.

In this blog, we will outline some of the easy-to-use test cases documenting styles.

Why do we need test cases?

Testers mostly rely on test cases to identify what needs to be done during testing, measure the process and performance, and ultimately check if the results met the user/client expectations. Let us understand some of the major benefits:

a) Product Understanding – Documentation

Testing at the core is just understanding a product. The more you understand a product, the better tester you can do. Test cases are the medium that can help us potentially uncover defects. Now, no documentation means letting the knowledge base lie only in the hands of the person who is creating those test cases. Test case documentation avoids this problem so that these test cases can be referred and evaluated later.

b) Continuity/Reusability

The person creating a test case may not always be the one executing them, so it is important that the test cases must be written in a way that they can be easily comprehended by other team members to jump on as and when needed.

The test cases are not meant to be used for one-time purposes, instead, they need to be reused for further test cycles (Manual or Automation).

c) Test Coverage Analysis and Evidence for Test Execution

Test cases are one of the barometers to reflect if our understanding is complete for the testing coverage around the test areas.

At various stages in a testing life cycle, there is an absolute need to share the deliverables among other stakeholders to build the confidence that the testing team is heading in the right direction. Once the execution is over, the results are the main metrics to perform a test sign off.

Test Case Documenting Styles

The test cases, depending on the level of details we define, can be categorized as:

• One-Liners

• Just enough details

  

• Elaborative

  

Similarly, there are other variants you can develop, depending on how extensive or minimal the details need to be documented as per your project needs. The key factors that differentiate these test cases documenting styles are the level of details that are needed and the time available.

The elaborative style of writing test cases works for applications that require heavy regulatory/compliance standards such as Healthcare, Banking, Aerospace, and Legal due to the need for test procedure reviews, auditing, user acceptance testing (UAT), etc. Whereas, one-liners may suite for a short-lived project with stringent QA timelines where test coverage is of greater importance than the level of detail.

As one size does not fit all, any given test case documenting style should never be considered as a default option. The style can be selected based on several dependencies such as:

• • Requirements traceability to test cases
  • Test automation mapping to test case
  • Need for user acceptance testing, where test cases will be executed by the end-users of the product
  • Technical competency of the BAs
  • Testers and other stakeholders understanding the test cases

Irrespective of using any test case documenting style, the test coverage should remain the same. It is also advised to keep the test case document style format consistent, throughout the project.

By: Lavanya Kolipaka