|
The original Call For Participation for this TC may be found at http://lists.oasis-open.org/archives/tag/200704/msg00000.html
The charter for this TC is as follows.
Name of the TC:
OASIS Test Assertions Guidelines (TAG) TC
Statement of Purpose:
The design of Test Assertions (TAs) associated with a specification or standard - referred to in this charter as target specification - has the following recognized benefits: (i) it improves the quality of this specification during its design, and (ii) it reduces the lead time necessary to create a test suite for this specification.
A test assertion (TA), also sometimes defined as test specification, is understood in this charter with the following general meaning: A TA is an independent, complete, testable statement for requirements in the specification. A TA always refers to an item under test (IUT), which is assumed to implement all or parts of the target specification, so that this IUT is concerned with the requirements addressed by the TA. This reference is either implicit or explicit if it is necessary that the TA identifies the item under test in some unambiguous manner. A TA describes the expected output or behavior for the item under test within specific operation conditions, in a way that can be measured or tested. A TA may refer to a test harness architecture, of which a description limited to the interactions between its components and the IUT may be sufficient. Test assertions are generally different from test cases, which are more detailed and contingent to a concrete test framework: TAs are the basis to write test cases, and relate the latter to the narrative of the target specification.
The general objective served by this TC is to facilitate the creation and usage of test assertions by any group involved in designing a specification or standard of which software implementations are expected to be developed, with a primary focus on OASIS technical committees. The first step in achieving this is to establish a common and reusable model, metadata, methodology and representation for TAs.
This is aligned with the intent of the former OASIS Conformance TC, although the focus in the current initiative is not on the various aspects of quality and conformance, but on a specific one, namely test assertions.
This TC also may submit its deliverables to the OASIS Technical Advisory Board (TAB) with the ultimate intent of having these deliverables recommended to the OASIS Board of Directors for contribution to a future revision of the OASIS TC Process, rules aiming at improving the quality and adoption of OASIS output. The TC would accept feedback and recommendations from the TAB and OASIS Board.
The TC will also facilitate the promotion of its deliverables and give them the visibility necessary to reach potential users in other standard organizations.
Scope of Work:
The scope of activity for this TC must be within the following topics:
— TA model: A model for designing Test Assertions (TA model), that is
independent from any particular target specification or standard, but that may
recognize different types of test assertions, and may accommodate these in a
specific way. Test assertions may be for verifying conformance of an
implementation to a specification, or interoperability between implementations
of the same specification. The TA model may address any useful relationship
identified between TAs, such as pre-requisites or pre-conditions. It may
include support for grouping several TAs - or grouping entities - but will not
pretend to fully model such entities as conformance profiles, specification
modules or implementation roles.
— Test Environment modeling:
Guidelines for characterizing the test environment or test harness assumed by
the test assertions, as well as the item under test or IUT (an implementation
of all or part of the target specification). Such characterization may remain
abstract by just focusing on the interaction between test environment and IUT.
This characterization may state the expected properties and mode of operation
required from the test environment in order to verify the TAs. It may be seen
as some of the requirements for a real test harness intended to process test
cases based on these TAs.
— Related Notions: Within scope is the
selection and/or refinement of definitions of concepts expected to be related
to TAs, even if not directly targeted by the modeling and methodology work of
this TC. Such concepts may include: test case, conformance profile or level,
test environment / harness, test execution.
— Methodology: A
methodology to make use of this model. This may include examples derived from
applying the above TA model to particular specifications or standards.
— XML Markup: An XML representation for TAs and - if appropriate - for
their grouping entities. Additional notations supporting the modeling of TAs
(e.g. UML) are also within scope. The intent of the XML representation is
left at the discretion of the TC. It could be intended as an exchange format
for editing tools, or as a source for rendering/publishing, or as an input for
a test tool, or a combination of these.
— Case Studies: Investigation
off current practices in other OASIS TCs or other organizations which have
already written test assertions for their specifications.
— Liaison
and Promotion: Within scope are efforts to liaise with other organizations than
OASIS, and cooperation with external contributors and groups that can provide
input to the TC as well as become users of its deliverables. Joint deliverables
are within scope. Explicitly Out of Scope :
—
Defining test case metadata or representation. (Several developments are
occurring in this area.) — Modeling or methodology of dimensions
of variability such as conformance profiles / levels / modules / discretionary
items. Substantial prior work exists in these areas. However the TC may use
this prior work as a foundation and may also accommodate these constructs when
designing an XML markup for TAs. Deliverables:
The TC will produce the following deliverables, in this order:
(a) Test Assertions Guideline document, including definitions, abstract model and structure not excluding the use of a modeling notation (e.g. UML), methodology and examples showing how to extract TAs from a target specification.
(b) A representation of TAs in XML, that refers to and supports the TA model of (a).
Timeline:
The TC will aim at a Public Review draft of the Test Assertions Guideline (a) before end of 2007. The guideline will be processed at least to Committee Specification level, and up to OASIS standard if considered appropriate by the TC.
The TC will aim at a Public Review draft of the TA XML Markup (b) within first half of 2008. The TA Markup will be processed at least to Committee Specification level, and up to OASIS standard if considered appropriate by the TC.
IPR Mode:
Royalty-Free on Limited Terms.
Anticipated Audience:
The TC is welcoming any OASIS member with an interest and/or experience in conformance, testing and quality assurance. Users of the TC deliverables are expected to be members of any OASIS technical committee.
Language:
English
|
