Artifact: Developer Test |
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: Test
Purpose
This artifact is used to evaluate whether an implementation element performs as specified.
Relationships
Fulfilled Slots | [Technical Implementation]
Roles | Responsible: Developer | Modified By: Developer
Tasks | Input To: Run Unit Tests Analyze Runtime Behavior Analyze Target Assure a Quality Solution Conduct Security Assessment Fix Vulnerabilities Identify Targets of Test Implement the Solution Integrate and Create Build Run Performance Test Run Tests Define Testability Elements Identify Test Ideas | Output From: Implement the Solution Implement Unit Tests Run Unit Tests
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(TM)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
Checklists | Developer Test
This program and the accompanying materials are made available under the Eclipse Public License V1.0, which accompanies this distribution. OpenUP Copyright © Copyright IBM Corp. 1987, 2009. All Rights Reserved.