MBT Blog Series: Yes, You Can Create Usable Manual Test Cases!

by January 5, 2018

How to Create Usable Manual Test Cases

Creating large amounts of test cases can be done today at the click of a button – with the help of tools like CA Agile Requirements Designer. These test cases can be easily exported to other tools that organizations typically use including: spreadsheets, CA Agile Central, MicroFocus/HPE ALM and many more. The right tools even have the ability to generate test data for each test case. Perfect! But what do test cases look like? Do they tell a tester accurately what to do? What are tests called? What techniques or best practices can be used in creating manual test cases that are indistinguishable from handwritten ones – apart from their new, higher test coverage?

The Problem

Below, I have mocked up a functional process of logging in with valid or invalid data. From the flow we are able to generate two possible paths: Successful and Unsuccessful. The flow is not complicated containing only a decision defining the login validity and several process blocks representing user actions and web requests and responses.

Requirements Modeling

The two paths generate the following test case when uploaded to ALM.

Modeling Requirements

When viewing the test cases in ALM we can already see that they aren’t very useful: the login requests are now visible to the tester when not needed; the description of step 3 is hard to read/understand without any context and the tester only knows that they need valid login in details but not what details.

Filtering Test Steps

A flow can consist of lots of elements: UI elements, service calls, functional decisions, data and more. These are needed to complete map out your requirement and so need to be contained within a flow. When exporting your test cases this extra information is not necessary for a tester running the test. The question becomes, “How can we remove them?”

From the path explorer you can filter what test steps are visible. For instance, you could filter the flow by block type to reduce the visible test steps only user interaction blocks. Let’s do this with the login example.

  1. Open Path Explorer
  2. Above where the test cases are displayed click the edit filter icon
  3. Select a filter type Block Type
  4. Select block type User Interaction
  5. Apply filters


We can see this has limited the blocks which are visible. Now, the test cases are only populated with the user interaction test steps. By using the filters we can specify what we want depending on the type of test. For example, the test should also include our error step so we simply adjust our filters to include both user interactions and error blocks.

Below we can see the test cases in ALM. We have removed the unwanted calls and simplified the test case.

ALM Tests

Using Explicit Process Blocks

Decision blocks are essential for flows. They do, however, make test cases hard to read and understand. For example, the below step. Its gobbledegook! We can get around this by using explicit process blocks to represent actions the tester will need to take.

Adding the explicit user actions as processes gives more information to the tester. I have also changed the decision block from a user interaction to a code type so that it is not included in the current test step filter. If you want, you could change the filter to include only process blocks.

Test Data

Using Test Data to Your Advantage

With the large volume of tests we can produce, bottlenecks will appear when provisioning test data for each one. To speed this up we can overlay test data at a block level to produce data at the point of test data generation.

We could add this test data into our block descriptions, “Enter login credentials with the value…”. This is not very dynamic. Instead, we can utilise the test data feature of the product to give our testers better test packs.

Test Packs

In the login example, I have added test data to the decision which decides whether a login was valid or not. To see more information on test data please refer to the test data section.

You will also have noticed that I’ve switched up the flow a little. The functionality is exactly the same but the order is slightly different. Why? To simplify the model.

When using test data you will start using the same blocks repeatedly. I could have used clones (previously I had a clone of “Click Confirm” and “Login Request”) but this can make the flow visually heavy when not necessary.


With our test data attached at a block level, the data for each test case can be exported out with each test.

At the very least, you can use Test Data to profile the data you need for each test case. You can easily export the data you need for each test case out in a CSV for data procurement. You can do this from the Test Data table

Naming Test Cases Intelligently

Generating test cases in large numbers often means that the test case names produced do not relate to what the test.

By default test cases will be name sequentially based on the name of the path type (test bucket) you are saving them to. So for test cases saved in the Use Cases path type they will be called Test Case 1, Test Case 2, Test Case 3…

Immediately, we can tailor the test case name by changing the name of the storied path type. This is also extremely useful for organising our test cases as the default path types may not always make sense.

  1. Click Manage
  2. Open Manage Stored Path Types
  3. Select the path type you’d like to edit
  4. Change the name to something appropriate
  5. Save

Naming Test Cases

This is great but now we are limited to calling what the type is and we could have done this manually when storing the paths.

Next, we can incorporate test data into the names of our test cases. This allows each test to be tailored by the test data or steps that define it. For example, I have added an extra piece of test data to login decision.

Login Decisions

The variable LoginState is set to “successful” for my positive test case and “unsuccessful” for my negative test case. Now we can use resolve these pieces of test data when we name our paths

  1. Open Path Explorer
  2. Generate new paths
  3. Store all
  4. Open the data painter window (You will need to connect to a TDod Service)
  5. Create a suitable name which references the relevant data

I have named my test cases to reference my “LoginState” by simply having a template test name of “Login State LoginState”.

Login State

We can now see the that the test case name reveals the functionality that the test cases cover.

Login Success

View this video to learn more about this this technique.

CA offers comprehensive solutions that automates the most difficult testing activities – from requirements engineering through test design automation and optimization. Start your Free Trial of CA Agile Requirements Designer today and fast track your testing at the speed of agile.