[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tag-discuss] RE: surviving the winter break
Indeed the "how to verify" could be understood in a very
concrete way (as defined in a test case), which we do
not want.
I think what we want to convey, is that between the
narrative of a specification and the operational aspect of a test case,
there is room for a statement more abstract than a test case, but
still indicative of the way the spec requirement should be tested (therefore
indicative of conformance conditions).
Here is actually the exact terms used in " Conformance
Requirements for Specifications 1.0", OASIS, which we should probably use
instead:
"...Each test assertion is an independent, complete, testable statement
for requirements in the specification."
Let me try to illustrate by an example how I understand
this:
1. specification
requirement(s):
" Message element X MUST use A under
condition C. An error E SHOULD be generated
otherwise."
2. Test case(s):
- describes the test harness and the state it should be in
for the implementation under test, and the test procedures used, say, for
causing a message to be generated under condition C, then the procedure for
verifying if the element X inside generated message contains A..
- Also a negative case describes how to generate a faulty
message M (X without A), and how to verify that the receiving implementation
generates the proper error message.
In between, a TA - or a couple of TAs - could consider an
implementation S in the role of generating a message M with element X, and
assert that element X contains A when operating under C. Alternatively,
considering an implementation S in therole of receiving a message M, the TA
would assert that if M was generated under C (which can be known somehow by
S) then if element X does not contain A, a well-formed error message E is
generated by S.
So the TA may not be more precise about the details of the
test harness and procedures to be used, but it is before all a statement about
an *implementation* and tells what it takes for this implementation to conform
to the spec requirement. Also, I would argue that for the sake of
"testability" a TA in above example may decide to restrict the scenarios
under which "condition C" may occur, so that derived test cases would not
worry about scenarios that may be very hard to realize. The TA would then
effectively state conformance conditions for an
implementation.
So it is really a "test centric" expression of the
original requirement.
Sure, in several cases, it may end up as a mere rewording
of the requirement, but in other cases may be more assertive on the general
conditions under which the tests are to take place (i.e. make the requirement
"testable").
Do we agree on this?
Jacques
From: Abbie Barbir [mailto:abbieb@nortel.com] Sent: Friday, January 12, 2007 5:45 PM To: Patrick.Curran@Sun.COM; Durand, Jacques R. Cc: tag-discuss@lists.oasis-open.org Subject: RE: [tag-discuss] RE: surviving the winter break Patric
I do agree with you.
Abbie From: Patrick.Curran@Sun.COM [mailto:Patrick.Curran@Sun.COM] Sent: Friday, January 12, 2007 7:55 PM To: Durand, Jacques R. Cc: tag-discuss@lists.oasis-open.org Subject: Re: [tag-discuss] RE: surviving the winter break This charter looks pretty good to me, but I have a concern about this statement: Each test assertion is (as far as possible) an independent, complete, statement of how to verify that an implementation satisfies a requirement in the target specification.How to verify whether an implementation satisfies a requirement is, I believe, a matter for the test case rather than the assertion. I'm sure we can resolve this as we proceed with our discussions, so I don't consider it a serious matter. -- Patrick Durand, Jacques R. wrote:
--------------------------------------------------------------------- To unsubscribe, e-mail: tag-discuss-unsubscribe@lists.oasis-open.org For additional commands, e-mail: tag-discuss-help@lists.oasis-open.org |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]