Work Product Descriptor (Artifact): Developer Test
The instructions that validate individual software components perform as specified.
Purpose
Evaluate that a software component performs as specified.
Relationships
RolesResponsible: Modified By:
Input ToMandatory: Optional:
  • None
External:
  • None
Description
Main Description

This artifact covers all of the steps that are required to validate a software component. It specifies test entries, execution conditions, and expected results. These details are identified for the purpose of evaluating a particular aspect of a scenario.

The tests should be self-documenting in a way that makes it clear upon completion of the test whether the component has run correctly.

Brief Outline

There is no predefined template for this work product and a testing tool will affect how the work product is handled, but here are some key issues that should be addressed:

  • Setup
  • Inputs
  • Script
  • Expected Results
  • Evaluation Criteria
  • Clean-Up
Properties
Optional
Planned
Tailoring
Impact of not havingNot having developer tests can inhibit iterative development, because there is no assurance that modified components are still working correctly when you modify components iteration by iteration.
Reasons for not needingIf the tests can be embedded into the actual production code, you might not need a separate work product. Nonetheless, some level of support for developer testing is always necessary.
Representation Options

The following are recommendation and options for representing this work product.

Recommendation: Automated Code Unit

The most appropriate technique for running these tests is using code that tests the components fully and that you can run regularly as you update the system during development.

When code is the sole form of the tests, you must take care to ensure that the code is self-documenting, including specifications of what conditions you are testing and what setup or clean-up is required for the test to run properly.

Option: Manual Instructions

In some cases, manual instructions can suffice. For example, when testing a user interface, a Developer could walk through a script, explaining the component. In this case, it can still be valuable to create a test harness that goes straight to the user interface. That way, the Developer can follow the script without having to walk through a complicated set of instructions to get to a particular screen or page.

Option: Embedded Code

Certain technologies (such as Java™ 5 Test Annotation) enable you to embed tests in the implementation. In those cases, there will be a logical work product, but it will be assimilated into the code that you are testing. Here, too, take into consideration that you must ensure that the code is self-documenting.

More Information
Guidelines