Strategic Design of Test Cases in Testing

Introduction

In every project the Test Design is equally important as Test Execution. Because of that the QA team must have a very strong strategy to design test cases. This article explains how to define the strategy of designing test cases.

The basics: what is a test case?

IEEE Standard 610 of 1990 defines a test case as follows: (1) A set of test inputs, execution conditions and expected results developed for a specific objective, such as to exercise a specific program path or to verify compliance with a specific requirement.

This definition indicates what a test case is and what it consists of. Starting from this base, we have a general outline to start the analysis and the strategy selection process.

Initial assessment



Requirements identification

The first step of Test Case design is to identify, understand and analyze the requirements of the project very clearly. After identifing the requirements we can start the next step of Test Case design.

Case creation

When the requirements have been identified and the materials clarified, both begin to come together to create a test case. During this first step of the creation process, it is important to bear in mind that both the set up and design of the cases look to guarantee full test coverage of the object whose requirements are being validated.

Test cases must have a series of components that let us ensure that each of them is using the identified materials and that the fully apply the requirements they are designed for. For this you need a base template like the one below that shows the important elements that every test case needs:



Defining the techniques

Among the various available techniques you can choose to go with black-box testing to validate inputs and outputs from the test object, validating all possible combinations (bearing in mind that the testing of all of them would not be possible). To accomplish this, the specification should have clearly defined each possible input and output to optimize the design. Also, depending on the available documentation, other techniques can be used, such as state transition testing, equivalence class partitioning, boundary value analysis, decision table technique, use case testing, cause-effect graphics, among others.

If technical documentation is available and if the project has access to the test object's detailed code, white-box testing can be used for detailed validation of software flows that apply to a specific input combination, thus providing low-level control. These are some of the techniques available nowadays: branch coverage, path coverage, statement coverage, among others.

Depending on the project's type and requirements, it might be necessary to run security tests. These require an advanced technical level to define the reach and the way in which such tests will be designed and run. Another type of testing that may be necessary is loading tests that need tools that allow you to create and run scenarios for the various tests of this kind.

Classification and focus

The requirements produce an initial test case group. This group organizes cases according to functionality that each of them test. Nevertheless, it is necessary to create a more complete classification that gives the testing team more information about the cases, their focus and duration and that enables the testing process to be made more dynamic and flexible through the rest of the testing project.

Tools and setup

At this stage many important elements have already been identified and they provide guidance on the formal setup of test cases, the structure of the tests is clear, as are the techniques that will be used to design them, the focus, the reach and the way to organize them. The next step is to choose a team of test designers with the necessary skills to develop each identified cases and select the tools that will support the design process. Depending on the type and size of the project, the team must evaluate whether a client-server tool should be chosen, or whether it is better to use a cloud solution. They also need to bear in mind that whatever tool is selected should allow them to set up all the previously identified elements to completely map the defined strategy.

Adaptability

During this stage it is important to evaluate the adaptability of the test cases to the current stage of the project. Cases must go through a stand-still validation before being run to guarantee that they are complete and that they cover all the functionalities for the specified components. Another validation stage takes place while the tests are being run and it checks that the cases do contain all the interaction flows between the test object and the testing analyst, providing him with a step-by-step orientation to achieve the expected results.

Association

The structure for the cases should be manageable and scalable, it is necessary to identify all the relationships in the test cases, whether they are direct or indirect. A direct relationship is the logical order of test execution.

Execution

At this stage it is important to identify the tools that will support the process itself, to set up automatic test execution and to support the analysis of the results depending on the case focus. To run the cases, you might need a specific tool that allows you to access a database, or to analyze the communication between the front end and the back end. It is important to be clear about the way versions will work in terms of the documentation of the tests run on each cycle.

Evolution and optimization

Through the project's life cycle, test cases should evolve in synchrony with the project. They need to grow and improve as the documentation matures or new knowledge is acquired by the testing team. Direct and indirect relationships among cases can be improved and it is even possible to create associations from the testing sets to indicate what must be tested first.

Conclusions

Test case design needs to be strategic, guaranteeing that while the project advances, the team will acquire all the necessary elements to achieve full test cases. This means they can be understood by everyone involved, are easily adaptable, can be grown and completed and ensure total coverage of all requirements.


Similar Articles