A few words about a good test case

In the article below, I will try to explain the type of the most multitasking test documentation — a test case. I will describe its functions and structure, as well as present the multitude of its applications at various stages of the project. I will also present the benefits of combining test cases into test scenarios and tell you for what purpose they can be used. Finally, I will introduce the tools that allow you to create test cases.

What is a test case?

A test case is a form of question asked to a program. The answer you get will depend on how it was formulated. Therefore, it can be assumed that a measure of the quality of a test case is the ability to obtain valuable information after the test has been performed. The case must be executable, and its content should allow for the assessment of the function’s compliance with the design documentation.

Like good questions, good test cases depend largely on the context and whether they are properly structured. It should be constant for all cases for a given project, increasing transparency and making it easier to read test documentation containing many test scenarios. The basic elements of the structure that a test case should contain are:

• Unique case identifier
• Information about the component of the system / module it concerns
• The investigated function of the above-mentioned item
• Purpose of the verification
• A set of preconditions that must be met for the case to be realized
• Steps to take to follow the case (Path)
• Expected result
• The current result
• Detailed data on the tester, test tools, application version and test date

Example:

ID: 1.1.0

Module: “Login screen”

Screen: “Log in”

App version: 2.0.1

Function: Screen completeness

Preconditions:

1. The app is not launched
2. The device is connected to the network

Path:

1. Launching the app
2. The LOGGING SCREEN appears

Purpose of verification:

1. Checking the completeness of the displayed elements on the LOGIN SCREEN

Expected result:

The following elements are displayed on the LOGIN SCREEN:

1. Field “User’s name”
2. Field “Password”
3. Button

Current result:

As expected

Verified by:

John Doe

Date:

02/29/2016

The above example doesn’t contain detailed test data that can be placed in different sections depending on the purpose of the test performed. For instance, preconditions could include information about the device on which the test is carried out or include it in a separate case section. If the purpose of the verification was to enter special characters into the fields of the login form, the test data — an example of login and password, should be placed in the “Path” section to facilitate the reproduction of the scenario.

The presented test case allows to state that the content of the login screen complies with the requirements in a specific version of the system. By placing it in the design documentation and test plan for the next version, you can verify that no unwanted regression has occurred in the next version of the system with identical preconditions and path. On one hand, the case becomes a description of how the application should react to user actions. On the other, when properly documented, it allows you to track possible changes and anomalies in the program’s behavior.

What are test scenarios?

The sets of single test cases are called test scenarios. There are many approaches to creating them. The ISTQB syllabus defines a scenario as “a document specifying a sequence of actions to perform a test”, which gives room for interpretation. We assume that the test case scenarios relate to individual system functions, and the cases included in the scenario will describe the operation of one system function. Below is an example of a test scenario in a spreadsheet:

Test scenarios can be very extensive, so it is good practice to select the test cases appropriately. For functionalities, the full coverage of which requires the use of a large or infinite amount of test data, the test cases should be documented in accordance with the testing techniques used. Worth documenting are also cases that showed a defect. This is important for regression testing as the change may re-cause the failure.

Test scenarios can be very extensive, so it is good practice to select the test cases appropriately. For functionalities, the full coverage of which requires the use of a large or infinite amount of test data, the test cases should be documented in accordance with the testing techniques used. Worth documenting are also cases that showed a defect. This is important for regression testing as the change may re-cause the failure.

Test case in project reality

User stories represent the requirements at the project backlog level. A complete user story usually includes a positive path which can be described with a high-level test case even before the acceptance criteria are specified. After establishing acceptance criteria, you can start designing test cases. The framework doesn’t place the responsibility of case design on testers alone. The “happy patch” test case report by a business analyst is used. A good design practice is the preparation by those responsible for the implementation of the solution and its tests (programmer and tester) of test cases supplementing the happy patch cases, also with edge cases.

This activity brings measurable project benefits. It provides the developer with knowledge about potential defect spots that can be eliminated during the implementation of the solution. The tester learns how the functionality works, how to test it and what nomenclature, e.g. fields, endpoints will be used, which allows him to create more detailed and complete test cases before implementing the functionality.

Joint coordination of activities at such an early stage reduces the risk of failure and shortens the test process. The resulting test cases are combined into sets of cases describing the operation of a given functionality. This, in turn, is associated with measurable benefits for business stakeholders. Together with the Product Owner, they can assess the compliance of the program description with the expectations before implementation by reviewing the test cases themselves. Another advantage of creating test scenarios before working functionality is created is identifying the behavior of the program that is not foreseen in the acceptance criteria and determining the expected result when it occurs. In the event of non-compliance, they are detected at an early stage which in turn allows for the identification and examination of the business rule on which the implementation was to be based. This happens before deployment and crash reports are produced.

Another advantage of keeping documentation of test cases is the possibility of preparing and conducting acceptance tests based on them. For this purpose, representative cases are selected from the set of test scenarios describing various functionalities and combined into the acceptance test scenario, mapping them with the requirements. The scenario created in this way should have a structured form, be transparent and understandable to the client. Well-written acceptance test scenarios require close cooperation of a business analyst, tester and client, and their aim is to confirm the quality of the delivered software. Passing acceptance tests brings the achievement of these goals closer, building stakeholder trust in the final product and often enabling its receipt.

Tools for creating test case artifacts

Modern tools for failure reporting and IT project management often have the functionality of creating test case artifacts. The following is an example of an artifact created in Azure DevOps:

These tools allow you to combine test cases into test sets, also providing advanced options for reporting test results or the ability to configure with automatic regression tests.

Especially the last time-consuming activity combined with on-demand activation and anomaly monitoring speaks for the implementation of tools with solutions of this type.

Summing up

Considering the above, it can be concluded that despite the significant amount of time involved in introducing a test case into the project as part of the test documentation, the benefits obtained are high. The test cases describe how the program works, so they are a source of knowledge for technical and business stakeholders as well as new members of the development team. The scenarios created on their basis can be used for acceptance tests, the successful completion of which is associated with confirmation that the customer has received a product that complies with the requirements. The test case surprises with the versatility of benefits at various stages of software development, which is why, according to the author of this article, it should appear as a documentation of IT projects as often as possible.