|A documented record of any of the following:
process control and enactment decisions, standards to be adhered to, or
good-practice guidance generally to be followed by the practitioners on
a given project.
||There is no UML representation for this artifact.
||One or more artifacts. We recommend that
you maintain at least one artifact to record your test process enactment
decisions, and at least one artifact to capture the new practices you
discover. May be initially inherited and reused from the controlling organization.
||Some process control and enactment aspects of
the Test Guidelines can be presented appropriately within the Software
Development Plan or the Iteration Test Plan.
Test Guidelines serve two related, yet subtly different purposes:
- To record adjustments (often tactical) to the way the process is enacted
on a given project.
- To capture project-specific practices discovered during the dynamic enactment
of the process.
As discussed in Activity: Develop Test Guidelines,
it's useful to think of Guidelines as coming under one of three general categories:
project control and enactment guidance (either strategic or tactical), standards
adherence, and project-specific practices.
Here are some suggestions for topics that could be addressed by Test Guidelines:
1. Project control and enactment
2. Standards Adherence
- Naming Conventions for Test Assets
- Test Automation language conventions Variable naming, use of language
features, style conventions.
- Required compliance with formally recognized or certified standards
ISO, IEEE, and so forth
3. Project-specific practices
- Arguably the most rich and interesting category of guideline. Often
in nature, typical subjects include:
- Test Idea Catalogs
- Test Automation Function Library Catalog
- A repository of code examples common to Test Automation problems
- Test Automation Frameworks
- Test Patterns
- Documented Failure and Fault Models
There are no UML representations for these properties.
||An unique name used to identify this Test
||A short description of the contents of the
typically giving some high-level indication of complexity and scope.
||An explanation of what this Test Guideline 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.
If possible, this artifact should initially be produced in the Inception phase,
and then, on an ongoing basis, in each Build or Iteration cycle in all remaining phases.
The Test Designer is the role primarily responsible for
this artifact. The responsibilities are split into two main areas of concern:
The primary set of responsibilities covers the following process management
- Deciding on what Test Guidelines to follow.
- Defining internal conventions and standards.
- Documenting those decisions.
- Documenting good-practice guidelines for reuse.
The secondary set of responsibilities covers the following design and
- Identifying emerging good practices.
- Understanding and defining the key aspects of each practice.
You should use an appropriate medium, based on the category of Test Guidelines
and on the culture of the project team; that might mean a document or an
intranet Website. Both process enactment and control, as well as standards, guidelines
typically suit either a text-based planning document or a static Web site.
For gathering and developing practitioner heuristic guidelines, we recommend
you consider using a WikiWikiWeb as discussed in Activity:
Develop Test Guidelines or some other form of collaborative, interactive
Regarding the Test Guideline template that comes with RUP, you may want to
tailor it in the following ways:
- Some sections may be removed or added to handle the specific features
and limitations of the specific programming language.
- Some of the sections may be irrelevant for your project.
- The order of the various sections may vary, depending on the system's
stakeholders and their focus or interest.
© 1987 - 2001 Rational Software Corporation