Test Case Design: a Guide for QA Engineers With Examples

It’s very important to apply the determined processes in the best way to develop successful software. In particular, software tests and software quality are of great importance for developing more successful projects.

This article will address software test case design.

What Is Test Case Design?

To begin a software project, engineers should plan and document tests within the project’s scope. This is part of a test case design.

More specifically, a test case design is a document that includes the test’s scope, the test strategy, the test environment, the software pieces for testing, the intended test actions within the project, the resources, and a schedule.

Thus, developing test case designs aims to define the test strategy within the project; plan resource allocation; and clarify responsibilities, risks, and priorities.

However, as applications change, test cases may require updates. Therefore, preparing test case designs begins with the early stages of the software lifecycle. A test case design plan is sometimes a product or tool for performing necessary functions within a project’s scope.

After an engineer completes the test case planning process, the test case design process begins. This process includes

• preparing the test environment;
• writing test cases for integration, system, and acceptance testing; and
• preparing test procedures.

Preparing the Test Case Design Environment

Test engineers run various tests in an environment that includes the software and hardware they describe. While preparing the test environment, engineers develop auxiliary test software to use in the tests.

Then, they may use some helpers in testing software, including:

1. Test data generators—This software produces the test input data necessary to execute test cases.
2. Debugger—This software enables errors encountered during the tests to be found on the source code.
3. Emulators and simulators—These software types imitate the real hardware that the software needs; they provide the hardware data necessary for the tests.
4. Stubs and drivers—These small pieces of software replace nonfunctional system components required for tests.

Engineers must record the test environment used for testing, hardware specifications, software versions, etc., so that if the same test must run again, these records are available for reuse.

Writing Test Case Design

After a software project’s requirements are approved, the test case design phase begins. While system analysts, system engineers, and software engineers prepare the system requirements and software requirements, the test team determines the test strategy suitable for the project and updates the relevant test plans.

Then, while system and software developers perform preliminary design and detailed designs, the test team starts to create test cases.

Engineers can validate a requirement with one test case or multiple test cases. For this purpose, they should write at least one test case for each requirement to demonstrate that the developed software meets all of its specifications.

However, these written test cases are usually positive test cases that’ll test the requirement’s positive side. In addition, the necessary requirements should also include test cases that show how the software will behave in negative situations.

When the developed software performs all of the expected behaviors, this indicates that all software test cases have been tested.

A test case is an input used to demonstrate that a particular part of the program works, or that a requirement is verified, the necessary steps taken, and the test has yielded the expected results.

Test Case Content

A test case should include

1. the purpose and conditions for its execution,
2. a step-by-step setup of the test environment,
3. input data,
4. the expected result,
5. the actual result,
6. a version description of the software,
7. the software’s working environment, and
8. the test ID.

Engineers should only test one item property at a time. Thus, if the test case runs and fails, it’s easy to see which feature is problematic. In addition, test cases should include known inputs. Moreover, these inputs and expected outputs are given as validation points in test cases.

If the software gives the expected inputs and expected result, the relevant test case passed.

Furthermore, tests performed when all or a specified proportion of the tested item’s test cases pass are considered successful.

Test Case Format

Here are some various test case format templates.

Example Test Case Template 1:

Example Test Case Template 2:

Example Test Case Template 3:

Engineers can implement these test cases and write test scripts to record the results manually or automatically. Whether  test case applications are manual or automatic, they should be recorded under all circumstances.

 

Test Types for Test Case Design

Tests in software projects are carried out in four different stages. As these tests’ detail levels increase, the size of the piece tested decreases.

These test stages are

1. unit tests,
2. software integration tests,
3. system tests, and
4. acceptance tests.

Unit Tests

Unit tests confirm that small pieces of code, such as methods, procedures, or classes, are working correctly. In order to do this, separate the unit tested from other units. Then, use stubs of those methods instead of other units that’ll provide the necessary inputs for the unit under test.

Thus, a possible error in the other unit will not affect the unit under test.

Test cases are created according to the task performed by the unit being tested. Using these situations, the unit test is run, and the results are compared with the expected results to decide whether the tests were successful or not.

Unit Test Example

For example, let’s say there’s a method called isitPositive (int k). In this method, if the integer variable k is negative, the method returns as true, and if the k integer variable is positive, the method returns as false. The following snippet is an example of this method:

public bool isitPositive(int k)
{
  if(k<0)
    return true;

  else(k>0)
    return false;
}

To test this method, the cases where the k value is tested by first giving values less than 0 and then greater than 0 are shown:

public void testCase_1()
{
  bool tc1 = false;
  int m = 3;
  td1 = isitPositive(m);
  
  if(tc1 == true)
     System.out.println("Test Case 1: Passed");
 
  else
     System.out.println("Test Case 1: Fail");

public void testCase_2()
{
  bool tc2 = true;
  int m = 4;
  tc2 = isitPositive(m);
  
  if(tc2 == false)
     System.out.println("Test Case 2: Passed");

  else
     System.out.println("Test Case 2: Fail");
}

Integration Tests

After successfully concluding unit tests in software projects, integration tests begin. Although unit tests serve to verify that the individual modules perform their expected functions, integration tests aim to verify that the components in an integrated software work in harmony with each other.

In tests, both positive and negative test cases use the appropriate parameters. Then, the results are compared with the expected values to verify that the system performs the expected behavior.

Integration tests can use different strategies, including big bang, bottom-up, or top-down.

Big Bang Strategy

After integrating with each other all the high- and low-level modules developed according to the big bang strategy, the tests begin.

In this strategy, since the tests involve considering the system as a whole, performing them is fast and saves time. However, it’s difficult to determine at which level layer or from which module an error occurs.

Bottom-Up Strategy

First, the bottom-up integration testing strategy starts with running unit tests.

Then, lower-level modules that successfully complete unit tests are integrated with each other. After this, integration tests are performed on low-level modules.

Following the successful completion of these tests, a system of upper-layer modules is integrated, and the necessary integration tests are performed. This integration continues until the whole system is built and the integration tests are completed successfully.

In this approach, the basic condition is that the unit tests of the modules to be integrated are successfully completed. This approach can help easily determine how much of the targeted system is completed and tested, represented as a percentage.

Top-Down Strategy

The top-down integration testing strategy starts with testing the top module (the outermost module, usually the user GUI module) for the system. This module uses the stubs of the required submodules.

The number of test cases run reaching a certain rate or passing all of them indicates completed integration tests. Engineers should report errors found at this stage to software developers according to a defined error-reporting mechanism.

System Tests

System tests evaluate the developed software’s features including performance, reliability, and functionality. It’s verified that the software developed in unit tests and integration tests is developed in accordance with the design.

On the other hand, system tests aim to verify what the customer wants from the system. For this reason, in system test cases, scenarios encountered in the real environment are defined based on the system requirements.

The first step of system testing is verifying the functional requirements performed. As a result of this verification, engineers can see that the system works functionally. After verifying functionality, they perform non-functional tests.

Nonfunctional Tests

• stress tests—These tests help observe the system’s behavior when the input rate to the system exceeds the system design rate.
• performance tests—These tests evaluate whether the system outputs can be produced within the specified and acceptable time frame.
• configuration and compatibility tests—These tests evaluate how the developed system behaves on different platforms and hardware.
• security tests—These tests evaluate the system’s behavior in unauthorized use attempts.
• usability tests—These tests evaluate user-system interaction and ergonomics.
• rollback tests—These tests evaluate the system’s automatic or manual recovery in the event of a failure.
• user interface tests—These tests evaluate how the user and the software will interact as a graphical representation, and how the system will process the inputs that the user will give to the system with the keyboard, screen, or mouse (i.e., the touchpad).

The system that has its nonfunctional tests completed is now ready for user acceptance tests. Errors that occur during system tests are reported according to the project error management process, and necessary corrections are made.

After the necessary fixes, the system undergoes iterative tests to evaluate that the fixes did not affect the rest of the system.

Acceptance Tests

Project acceptance tests validate customer requirements.

For this purpose, test cases serve to validate each user requirement. In the developed system, these defined test cases are applied in accordance with the “acceptance test plan” with the customer’s participation.

To sum up, after the entire system passes these tests, the customer can accept the system.

Conclusion

To summarize, we’ve highlighted how important test case design is. Software testing becomes much more important in very large projects because a product on the market that is constantly causing problems due to malfunctions causes a great loss of time and money.

For example, test engineers with good theoretical knowledge are very important for projects that have an important place in software technologies such as banking software, military software, public software, and games.

To that end, the need for good testers and good coders increases day by day.

What to read next

Test Scenarios vs. Test Cases: A Guide For QA Engineers

Test Strategy vs Test Plan: Managing QA in the Enterprise