The step-by-step instructions that realize a test design specification, enabling its execution.
Role:  Implementer 
Optionality/Occurrence:  Depends on the scope and granularity of developer testing: for subsystem testing there will be as many as needed to provide the appropriate coverage; in the case of smaller components, only the critical aspects are usually tested.
Templates and Reports: 
     
Examples: 
     
UML Representation:  Not applicable.
More Information:   
Input to Activities:    Output from Activities:   

Purpose To top of page

The purpose of the Developer Test is to provide the implementation of a subset of required tests in an efficient and effective manner.

Brief Outline To top of page

Each Developer Test should consider various aspects including the following:

  • The basic computer hardware requirements; for example, Processors, Memory Storage, Hard-disk Storage, Input/ Output Interface Devices
  • The basic underlying software environment; for example, Operating System and basic productivity tools such as e-mail or a calendar system
  • Additional specialized input/output peripheral hardware; for example, Bar-code scanners, receipt printers, cash draws, and sensor devices
  • The required software for the specialized input/ output peripheral hardware; for example, drivers, interface and gateway software
  • The minimal set of software tools necessary to facilitate test, evaluation and diagnostic activities; for example,  memory diagnostics, automated test execution, and so forth
  • The required configuration settings of both hardware and software options; for example, video-display resolution, resource allocation, environment variables, and so on
  • The required "preexisting" consumables; for example, populated data sets, receipt printer dockets, and the like.

Properties To top of page

There are no UML representations for these properties. The level of formality for Developer Tests varies, so some of the following information might be missing or embedded in the implementation. In general, the larger and more critical the component under test is, the more effort needs to be put into maintaining the developer tests.

Property Name 

Brief Description 

Name  An unique name used to identify this Developer Test. 
Description  A short description of the contents of the Developer Test, typically giving some high-level indication of complexity and scope. 
Purpose  An explanation of what this Developer Test represents and why it is important. 
Dependent Test and Evaluation Items  Some form of traceability or dependency mapping to specific elements such as individual Requirements that need to be referenced. 
Preconditions  The starting state that must be achieved prior to the Developer Test being executed. 
Instructions  Either the step-by-step instructions for executing the manual test, or the machine readable instructions that, when executed, stimulate the software in a similar manner to the actions that would be undertaken by the appropriate Actor, human or otherwise. 
Observation Points  One or more locations in the Developer Test instructions where some aspect of the system state will be observed, and usually compared with an expected result. 
Control Points  One or more locations in the Developer Test instructions where some condition or event in the system may occur and needs to be considered in regard to determining the next instruction to be followed. 
Log Points  One or more locations in the Developer Test instructions where some aspect of the executing test script state is recorded for the purpose of future reference. 
Postconditions  The resulting state that the system must be left in after the Developer Test has been executed. 

 

Timing To top of page

Most of the Developer Tests are created in the same timeframe as the software components that need to be tested. The tests driven by Change Requests are developed after the components have been developed, and most of the times are short-lived if their goal is only to reproduce a defect in a more controllable environment.

Responsibility To top of page

The Implementer role is primarily responsible for this artifact. Those responsibilities include:

  • develop the tests according to the design specifications, in an efficient and effective manner
  • follow the defined guidelines, ensuring that the tests are maintainable and compatible with the other tests
  • manage the changes
  • identify the tests that need to be maintained and clean up or mark the ones that are limited in purpose and time
  • identify opportunities for reuse and simplification

Tailoring To top of page

The overall goal is to implement a simple and efficient developer testing framework. For the "one time only" tests, most of the documentation overhead should be avoided. Special attention should be given to the tests that will be used as regression tests for subsystems or the more "volatile" components, in terms of documentation, maintainability, efficiency, effectiveness and robustness.



Rational Unified Process   2003.06.13