JReality
JavaTM Virtual Reality Applications and
Related Technologies
"Freedom" Service-Oriented Methodology
Implementation and Test Process
Principles -- Implementation and Test
- DDI Principle:
Design drives implementation
Implement modules consistent with the design specifications.
If the design specifications appear incorrect, change them; but
do not ignore them.
- DDT Principle:
Design drives testing
Implement test code consistent with the design specifications.
If the design specifications appear incorrect, change them; but
do not ignore them.
- DDD Principle:
Design drives documentation
Implement API documentation consistent with the design
specifications. If the design specifications appear incorrect,
change them; but do not ignore them.
- Test Segregation Principle:
Testers should not be the developers
Tests should be developed by different people than the code
to be tested. This not only avoids obvious conflict of interest,
but helps identify ambiguities and false assumptions in the
design specifications and the code.
- Test All Principle:
Test all code; validate all documents
All code modules should be regression tested, and all
documentation checked for correctness and completeness, by the
test team. Anything not tested or checked is almost certain to
have errors.
Create Code and Unit Tests
Source code conforming to the
behavior tables for the current
release group is developed and added to the
user interface mockup. Source code for the supporting
common service objects is also developed based on the
interface specifications and
operation/method behavior tables. All source code utilizes
the coding and commenting standards adopted for the project.
As with other tasks, the
quality requirements are used to guide selection among
competing implementation alternatives.
The entry point operation (e.g., Java main method) of
common service objects is used to host developer
unit test code. Developers write unit tests for the classes
they develop to ensure that the code delivered to the test team for
regression testing is reasonably bug free. In order to encourage
adequate unit testing, management may choose to reward developers
whose code consistently exhibits low failure rates during regression
testing.
Create Regression Tests
In parallel with the source code development, black box
regression tests are developed by test team personnel
based on the same
interface specifications used to develop the source code.
All regression tests utilize the coding and commenting
standards adopted for the project.
Perform Regression Tests
The test team invokes the
regression tests on the completed
source code. Failures due to errors in the source code are reported
to the development team using any efficient internal reporting
mechanism such as direct communication with the appropriate developers,
or "pair testing" (i.e., having the developer who wrote the code
assist in running the regression tests for that code). Use of formal
bug reports for internal communication should be avoided.
Failures due to errors in the regression tests are immediately
corrected by the test team, and the tests rerun.
Any
common service module interface changes deemed necessary from
the coding or regression tests processes
are promulgated as changes to the
interface specifications and
operation/method behavior tables. Regression tests and application
source code are then revised in parallel based on the modified
specifications.
Note that changes to reusable common service module interfaces are
not permitted once the reusable code is
Released to the
reuse library. Interface changes to reusable code
after initial release must take the form of new operations or methods,
with the old code being deprecated.
Create Application Program Interface (API) Documentation
API documentation records the black box view of the
common service objects and
reusable
functionality objects of the application program,
formatted for easy reference by developers and maintainers.
API documentation is created by the developers based on the
interface specifications used to develop the source code,
as well as on the
header comments of the source code. The API documentation
is the primary reference documentation for
reusable code,
and serves as maintenance documentation for the application.
Validate Application Program Interface (API) Documentation
The
API documentation is validated by test team personnel.
Validation includes checking the content for completeness and
consistency with the source code, as well as checking natural
language descriptions for correct spelling and grammar. Any
deficiencies noted are reported to the development team using any
efficient internal reporting mechanism, such as direct communication
with the appropriate developers.
Create User Documentation
User documentation records usage instructions for each human user
stimulus set of the application program, and may include
stimulus sequences for common
Enterprise Process Model tasks
that can be performed using the application program. User
documentation should include a table of contents and index for ease
of reference, and may be published in hard copy or soft copy
(on-line) form.
User documentation is created by the developers, or by technical
publications personnel with the assistance of the developers,
based on the human user branches of the
functionality tree, associated
behavior tables, and
user interface design. The user documentation is the only
formal book documentation consistently produced using Freedom. All
other formal documents, such as formal requirements and design
documents, are at the discretion of customer management.
Validate User Documentation
The
User documentation is validated by test team personnel.
Validation includes checking the content for completeness and
consistency relative to the user interface branches of the
functionality tree and the associated
behavior tables, as well as checking natural language
descriptions for correct spelling and grammar.
All documented stimulus sequences for
Enterprise Process Model tasks are performed by test team
personnel to ensure accuracy and clarity of the documented usage
processes. Any deficiencies noted are reported to the development
team using any efficient internal reporting mechanism, such as direct
communication with the appropriate developers.
home
about
downloads
gallery
goal
plan
products
e-commerce
future
science & engin
you & me
Copyright (C) 2000-2003 LDJ Trust
