AP- Simple Test Case Management

Why might we need to manage test cases?

In a well resourced project or system, the roles for Quality Assurance will be established and operating well.

But sometimes we find ourselves in situations where we do not have formal support from Quality Assurance roles, or where there is not an organizational tool available that can be used for managing testing.

When that happens it is useful to have a method, that we can fall back onto that, will let us leverage our structured documentation to, at the least, identify test cases that need to be signed off.

The test cases we identify using this approach are not fully decomposed to what is known as an imperative level.  Each use-case we identify is at what is known as the declarative levels. 

Declarative test cases describe the ‘what’ we want to see happen. Imperative test cases describe the ‘How’.

Identifying the declarative test cases is part of meeting the definition of READY. Imperative test cases are part of meeting the definition of DONE.

A single declarative test case could result in numerous imperative cases; but for our purposes we will at least be able to extract a level of documentation that can provide an ability to review and sign off—not just the test coverage—but also the code coverage. 

Where QA support might happen to be available, they can take our declarative test cases as a valuable input to their own analysis activity.

The image below shows how test cases at the various levels of deliverables reflect across to testing activities in the system.

Let’s look at how we go about doing this using an empty system design template, with some made-up headings.

Using a structured and templated approach to documentation is primarily to ensure we communicate consistently and effectively; but it has an added benefit also, in that it makes the identification of test cases very straightforward.

Watch the video to see how it works, or alternatively you can read the text below the video location.

In our template, the processing section is clearly separated from the business rules, or specification.  If we were using the business analysis template for this example, we would also have a requirements section, which would also be separate part of the document.  In each section we have specific subheadings that cover just one element.

These are the steps to take in order to use these headings to define our test cases.

The first step is to set bookmarks. We set bookmarks in word, to specify which sections we want to capture as test cases.

To set a bookmark, we highlight the section we are interested, then select insert bookmark, and give it a name.  We do that for each section we want to mark up for test case extraction.

Once we have marked up our bookmarks, go to the table of contents, highlight it and select SHIFT-F.  This exposes the field codes.  Copy these codes and go to the end of the document.

We enter a heading for our test cases, and then paste the table of contents codes as many times as we have bookmarks. In our case this is twice.

We then SHIFT-F9 again and add in the tag for our bookmark, which is backslash b followed by the bookmark name.

We then adjust the depth of headings that we want to appear in the tables of contents.

After that we select the entire document using CTRL-A , then select F9.  The tables of contents will be filled with the headings from our bookmarked sections.

We then open the toolkit excel template called Simple test Case management. In this template we create a tab for each bookmark we have, and copy over the empty table and headings.

Next, we return to the word document and copy the table of contents data, which we then paste into the spreadsheet tabs.

When this is complete, we have identified our test cases at a declarative level.  The excel template has columns for unit testing signoff, and peer review.  You can modify them as you desire, and also add more granular levels of testing, should that be useful.

The final step is to load the filled in spreadsheet back to the word document; so that everything is on one place. 

This way you can ask your QA support, engineers, and peer reviewers to maintain the spreadsheet directly in the design document and it will always be up to date.  These signoffs can form part of the definition of done for the engineering team.

Leave a Comment