1. Testing Business Applications Guide
  2. Test Cases

Test Cases

A test case represents an application behavior that needs to be verified. For each component, application, and business process you can identify one or more test cases that need verification. The following image shows an example of a test case list. Test plans typically contain multiple test cases.

Sample Test Plan: Test Case List

The example shown in this image uses the following numbering schema for the Test Case ID:

  • TC1.x – New records and seed data required to support other test cases

  • TC2.x – Positive test cases

  • TC3.x – Negative test cases

  • TC4.x – Data Conversion testing

  • TC5.x – System integration testing

Notice how the test schedule is included in the example: TC1.0 – New Contact is performed during Functional Cycle 1 (Functional C1) of the functional testing. Whereas TC3.0 – Contracts occurs during Functional Cycle 2 (Functional C2) and during system integration testing.

During the Design Phase of a test plan, there are a number of test types that you must define as follows:

  • Functional test cases. Functional test cases are designed to validate that the application performs a specified business function. The majority of these test cases take the form of user or business scenarios that resemble common transactions. Testers and business users should work together to compile a list of scenarios. Following the business process testing practice, functional test cases should be derived directly from the business process, where each step of the business process is clearly represented in the test case.

    For example, if the test plan objective is to validate support for the Manage Quotes Business Process, then there should be test cases specified based on the process definition. Typically, this means that each process or subprocess has one or more defined test cases and each step in the process is specified within the test case definition. The following image illustrates the concept of a process-driven test case. Considerations must also be given for negative test cases that test behaviors when unexpected actions are taken (for example, creation of a quote with a create date before the current date).

    Business Process-Driven Test Case with its Corresponding Process Diagram

  • Structural test cases. Structural test cases are designed to verify that the application structure is correct. They differ from functional cases in that structural test cases are based on the structure of the application, not on a scenario. Typically, each component has an associated structural test case that verifies that the component has the correct layout and definition (for example, verify that a view contains all the specified applets and controls).

  • Performance test cases. Performance test cases are designed to verify the performance of the system or a transaction. There are three categories of performance test cases commonly used:

    • Response time or throughput. Verifies the time for a set of specified actions. For example, tests the time for a view to paint or a process to run. Response time tests are often called performance tests.

    • Scalability. Verifies the capacity of a specified system or component. For example, test the number of users that the system can support. Scalability tests are often called load or stress tests.

    • Reliability. Verifies the duration for which a system or component can be run without the need for restarting. For example, test the number of days that a particular process can run without failing.