Jacques,
I generally agree with your charter. I guess
the difficulty is at qualifying the ‘how to verify’ in terms of how
deep it goes. In your example, the ‘how to qualify’ only covers the
process. However, one could also looks for/interpret that the TA also should
indicate how to verify that the message M does not use A or when the
Implementation is under condition C. It would be better if we could qualify the
definition further to make it more obvious how deep the TA has to go.
- Serm
From:
david_marston@us.ibm.com [mailto:david_marston@us.ibm.com]
Sent: Tuesday, January 16, 2007
1:41 PM
To:
tag-discuss@lists.oasis-open.org
Subject: [tag-discuss] RE: TA
definition (formerly: surviving the winter break)
Jacques Durand wrote:
>In any case and to avoid controversy at
charter level, I would propose to replace the def of TA as:
>"A test assertion (TA), also sometimes defined as test specification,
is understood in this charter with the following general meaning: it describes
the expected output or behavior for an implementation under some specific
operation conditions, in a way that can be measured or tested. Each test
assertion is an independent, complete, testable statement for requirements in
the specification. 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."
>Anyone disagrees?
I
like this definition because it avoids the discussion of preconditions vs.
stimulus, relying only on the very bland "operation conditions" to
describe the situation in which a behavior may be expected. It also avoids
stating whether that behavior is always the end result of a test case (that
could be evaluated as pass/fail/whatever) or might sometimes be a condition
that can be used for compounding TAs. I suspect that the TC would want to
discuss those issues deeply, so it's best if the charter does not presume any
design philosophy at that level.
In
other words, the TC would probably want to have lively discussions about how
many different kinds of
contingencies and results should be defined. These discussions will affect
sequencing of the parts of a test and how compounding of TAs might affect the
sequence. Is a state model always needed? It's best if the definition of a TA
(and indeed, the whole charter) makes no assumptions on these topics.
.................David
Marston