Test Case

Definition

A test case is a testing work product that automatically performs a single test on an executable work product.

Goals

The goals of a test case is to automate or document the following:

• Perform a single test (e.g., a single test of a use case path or class method).
• Cause failures that uncover underlying defects so that they can be identified and removed.
• Help improve the quality of the item under test.
• Help developers understand the behavior of the item under test.
• Help developers improve the quality of the specifications (e.g., use case path and class responsibilities) of the item under test.

Objectives

To support these goals, the objectives of a single test case include:

• Document the purpose of the test case (i.e., the part of the item under test being tested, the type of failures to be elicited).
• Document the producer of the test case.
• Prepare the item under test for testing (i.e., place the item under test, the test stimuli, and the collaborators of the item under test into their correct pretest states, and provide the necessary test data).
• Stimulate the item (e.g., send it test messages, raise test exceptions).
• Observe how the item responds (e.g., values returned, exceptions raised, changes in state, and messages sent) to the test stimuli.
• Compare the actual responses (i.e., postconditions) to the expected responses to identify failures that imply the existence of defects in the item under test.
• Report the results of the associated test.

Benefits

A test case provides the following benefits:

• Automates a single test, thereby supporting regression testing.
• Documents a single test in terms of objective, oracle, etc.
• Documents test results
• Failure to produce test cases increases the probability that the item under test will contain defects that will make the application fail to meet its requirements.
• Failure to automate test cases makes regression testing more expensive and less likely to occur.

Contents

• Test case objectives
• Test preparation (e.g., to place objects under test into the appropriate pre-test states)
• Test stimuli (e.g., to send test messages or raise test exceptions)
• Expected behavior (i.e., test oracle)
• Test reporting script
• Test finalization script

Stakeholders

• Producers:
  • The Requirements Team for requirements model test cases.
  • The Architecture Team for architecture model test cases.
  • The SoftwareDevelopment Team for design model and unit test cases.
  • The Integration Team for integration test cases.
  • The Independent Test Team for system test cases.
• Evaluator: Test Inspection Team
• Approvers: None.
• Maintainers:
  • The Requirements Team for requirements model test cases.
  • The Architecture Team for architecture model test cases.
  • The Software Development Team for design model and unit test cases.
  • The Integration Team for integration test cases.
  • The Independent Test Team for system test cases.
• Users:
  • The Requirements Team for model testing of the:
    • use case model
    • domain object model
  • The Architecture Team for:
    • Model testing of the software architecture
    • Unit testing of the software architecture prototype
  • The SoftwareDevelopment Team for:
    • Model testing of the software design
      Unit testing of the software components
    • The Integration Team for performing integration testing.
    • The Test Team for performing system testing.

Phases

• Initiation: Completed
• Construction: Completed
• Delivery: Completed
• Usage: Maintained
• Retirement: Archived

Preconditions

A test case typically can be started if the following preconditions hold:

• The relevant sections of the Project Test Plan are completed.
• The relevant team is staffed.
• The relevant requirements, architecture, or design are completed.
• The relevant item under test is started.
• The relevant test suite is started.

Inputs

• Work products:
  • Project Test Plan
  • System Requirements Specification
  • System Architecture Document
  • Software Architecture Document
  • Javadoc including responsibilities
  • Software components (e.g., method signatures, assertions, branching and looping logic)
• Stakeholders:
  • None

Guidelines

• Test cases will be used at all levels of testing (e.g., model testing, unit testing, integration testing, and system testing).
• To support regression testing, test cases will be automated whenever practical.
• The oracle can be incorrect, and the test case developer can make mistakes. Thus, test cases need to be evaluated for defects.
• If the quality of the test cases is not at least as good as the quality of the item under test, then it will be difficult to know if the defect causing the failure is in the item under test or in the test case.
• Test cases need not document how to perform the test unless they are automated. When performed manually, this information is documented in the associated test procedure.
• Test cases do not document the results of the tests, which are documented in the associated test report.

Conventions

A test case is constrained by the following conventions:

• Content and Format Standard
• Inspection Checklist

Examples

• EAS Example Test Case