5 Checklists for Customizing Fields in ReQtest – Part 2: Test cases

Part 2: Test cases

This is the second post in our five-part series about customising fields in ReQtest. You can read the first part here.

These are the most commonly modified fields in the form for test cases:

Title  

Brief summary, e.g. “Change customer data”

Description

A description of the test case, for clarity.

Subsystem

It is common that the test case is linked to a specific subsystem. If not, the field can be hidden.

Test suite

A common example of the use of test suites is regression testing. Test suites are useful if you frequently reuse test cases. In a test suite, one can place the test cases in a specific order. When you then add the suite to a test run, test cases automatically end up in the right order. It may be helpful to consider the naming of test suites.

If you are working with test suites you can make test suite a visible field in the test case form. Then you can immediately assign the case to a test suite when creating the test case. You can also assign test cases to test suites later, so it is not really necessary to have the test suite field visible in the test case form.

Priority

Priority can be used to determine the execution order in a test run in order to ensure that you test it first things first.

What scale should then be used? Examples of scales:

• High, Medium, Low
• MoSCoW (Must, should, could, won’t)
• Normal, High

Status

Describes what happens to the test case right now. Can be handy if you have a process where you write test cases for future system versions, but you do not want someone to accidentally select those test cases for the current version of the system where these upcoming test cases are not valid yet.

Examples of statuses include: not completed, upcoming, active, no longer active.

Preparations/preconditions

Activities that the tester must do before the test case steps can be performed, e.g. create customer. See “Preconditions and Postconditions” below.

Postconditions

Restoration of the system so that the system is as before the test steps were performed, e.g. change back the customer. See “Preconditions and Postconditions” below.

Configuration

If you test different configurations, you can describe the configuration here, such as which version of Windows or web browser to use. Configurations can also be handled in the form of test runs or as instructions in test runs.

Reviewer and review status

These fields are used if you have the practice to review test cases before they are put into use. Whoever is assigned a test case to be reviewed will receive an email from ReQtest and it also appears on the start page. If you do not review test cases, these fields should be hidden.

Execution result

Displays the result of the last time the test case was executed. The field can be displayed in the “Show test cases” list. The field is normally hidden in the test case form but can be displayed if you need it.

Test step and expected results

The most important field in the test case. Type in instructions to the tester on how to test the feature and check that the result is OK.

Type of test case

Example: Functional test case, performance, boundary value.

Risk probability and consequence

Used for risk-based testing to make it easier to find the test cases that are associated with the highest risk. You can for instance use a four-point scale.

Preconditions and postconditions

Sample precondition is that the tester should prepare test data before running the test. Post condition may be that you need to restore data when the tests are completed.

In ReQtest you have the ability to manage preconditions and postconditions in four ways:

1. Fields for preconditions and postconditions in each test case.
2. Fields for preconditions and postconditions in test run. This is useful if a test run with a number of test cases has the same preconditions and postconditions.
3. If you do not need preconditions and postconditions in your test cases, you can delete or hide these fields.
4. You can, of course, have preconditions and postconditions both in the test case and in the test run.

This concludes the second post of our five-article series about customising fields in ReQtest. Stay tuned for our next checklist, which will cover the most commonly modified fields when conducting test runs.