 |
The Developer Test validates a specific aspect of an implementation element.This artifact encompasses the work traditionally thought of under Unit (black box) Testing and white box testing. |
Domains: Development, Test |
|
Purpose
This
artifact is used to evaluate whether an implementation element performs as
specified. |
Relationships
Fulfilled Slots |
|
Roles | Responsible:
| Modified By:
|
Tasks | Input To:
| Output From:
|
Description
Main Description |
This artifact covers all of the steps to validate a specific aspect of an implementation element. For example, a test
could ensure that the parameters of a method properly accept the uppermost and lowermost required values. A developer
test specifies test entries, execution conditions, and expected results. These details are identified to evaluate a
particular aspect of a scenario.
When you collect developer tests for a specific implementation element, you can validate that the element performs as
specified.
The tests be self-documenting so that it is clear upon completion of the test whether the implementation element has
run correctly.
|
Brief Outline | Although
there is no predefined template for this work product, and testing tools affect
how the work product is handled, you should address the following issues:
- Setup
- Inputs
- Script
- Expected Results
- Evaluation Criteria
- Clean-Up
Each Developer Test should consider the following where appropriate:
-
Basic computer hardware requirements: processors, memory, hard-disk size, input/output interface devices,
etc.
-
The underlying software environment: operating system and basic productivity tools such as e-mail or a calendar
systems.
-
Additional specialized input/output peripheral hardware: bar-code scanners, receipt printers, cash draws, sensor
devices, etc.
-
The required software for the specialized input/output peripheral hardware: drivers, interface and gateway
software, etc.
-
The minimal set of software tools necessary to facilitate test, evaluation and diagnostic activities: memory
diagnostics, automated test execution, etc.
-
The required configuration settings of both hardware and software options: video-display resolution, resource
allocation, environment variables, etc.
-
The required "preexisting" consumables: populated data sets, receipt printer dockets, etc.
|
Key Considerations
Most of the Developer Tests are created in the same timeframe as the software components that need to be tested.
The entire suite of developer tests should be run often to reduce the number of regression errors introduced during
implementation.
Developer tests are often shared with integration and system testing organizations so regression tests can be run on
the integrated system.
|
Tailoring
Impact of not having | If
you do not run developer tests, you cannot ensure that elements that you modify
over time are working. This can inhibit iterative development and maintenance.
Neglecting developer testing will seriously degrade the quality of the system.
Finding errors during integration testing (or after release) instead of during development makes those errors more
costly and time consuming to fix.
|
Reasons for not needing | If
you can embed the tests into the production code, you might not need a separate
work product. Nonetheless, some level of support for developer testing is
always necessary when you develop application software. |
Representation Options | Suggestions and options for representing this work product:
Suggestion: Automated code unit The most appropriate technique
for running these tests is to use code that tests the implementation element
scenarios and that you can run regularly as you update the system during development. When
code is the sole form of the tests, ensure that the code is self-documenting.
The code should document the specifications of the conditions you are testing
and the setup or clean-up that is required for the test to run properly.
Option: Manual instructions In some cases, you can use manual
instructions. For example, when testing a user interface, a developer might
follow a script, explaining the implementation element. In this case, it is
still valuable to create a test harness that goes straight to the user interface.
That way, the developer can follow the script without having to follow a complicated
set of instructions to find a particular screen or page. Option:
Embedded code You can use certain technologies (such as Java™
5 Test Annotation) to embed tests in the implementation. In these cases, there
will be a logical work product, but it will be assimilated into
the code that you are testing. When you use this option, ensure that the code
is self-documenting.
Developer Tests may have the properties listed in the table below. 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.
|
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.
|
More Information
|