Task: Develop test cases
This task creates the test cases for unit testing, such as during a Test Driven Development nanocycle.
Purpose
The purpose of this task is to create a test set of test cases to ensure that the (white box) functionality being added is correct.
Relationships
InputsMandatory:
    		Optional:
      Outputs
        Main Description
        As functionality is incrementally elaborated in models or source code, it is important to incrementally verify that it is correct. This is done by creating and apply test cases as the functionality is being developed.
        Steps
        Analyze new functionality being added
        This step involves reasoning about what tests would verify the correct functionality. All paths should be considered. All relevant data should be categorized into equivalence classes so that a value from each equivalency class may be included in the developed test cases. If the change is one of optimization (rather than new functionality), then the optimization criteria should be represented in the test cases to ensure that optimzation was adequate to meet the need.
        Develop test cases for "sunny day functionality"
        Parameters should be verified for all equivalence classes of their valid and invalid ranges. At minimum, all paths should be verified through tests, although more detailed coverage may be required, depending on the criticality of the software.
        Develop test cases when preconditions are violated
        Preconditions are things assumed to be true before a service is invoked. Sunny day tests should have already been created to verify those conditions. Precondition invariant tests verify that the software acts correctly when preconditions are violated. Examples of precondition violations are when input parameters are out of range, when the software state is incompatible with the requested service, and when resources are unavailable to fulfill a request.
        Develop test cases for when invariants are violated
        "Class invariants" are assumptions about the operational context that are always true. However, due to combinations of errors and failures, such invariants may be false. Invariant violation testing ensures that when assumptions are violated, the software acts correctly.
        Develop test cases for quality of service requirements
        Quality of Service (QoS) requirements refer to how well a service is performed. Examples include worst case performance, average performance, and reliability. QoS test cases test to ensure QoS budgets allocated to the software under development are being met.
        Analyze converage to ensure adequacy of coverage
        Coverage analysis ensures that the software computation nodes are properly visited during the execution of test cases. The degree of coverage varies with the criticality of the system under development. Standard levels are Structural Coverage (SC) - all lines of code are executed, Decision Coverage (DC)- all decision branches are taken, and Modified Condition/Decision Coverage (MC/DC) - all conditions affecting decisions have been verified independently.
        Key Considerations
        Unit tests tend to focus on functionality, but care should be taken to ensure that pre-conditions, post-conditions, and invariant violoations are checked as well as any quality of service (including performance) requirements are met as well. It is expected that this task is done in parallel with the adding of capabilities.