Re: [tag-discuss] TA definition (formerly RE: surviving the winter break)

["Dave Pawson" <dave.pawson@gmail.com>]

On 16/01/07, Durand, Jacques R. <JDurand@us.fujitsu.com> wrote:

> Ooops - speaking for myself indeed!
Thank you.


>
> Now, thinking again about this,  I think the "how" in "how to verify" should
> not be too strictly interpreted:
Exactly.
Verified 'for what purpose' is a local decision?
Your reasons for verification may differ from mine.


 If stating TAs authorizes - as currently in
> charter draft -  " ...characterization of the test environment or test
> harness assumed.. " (e.g. in my previous example, TAs would assume a test
> component able to generate messages to a system under test, as well as to
> receive messages from it), then this already says something on "how to
> verify".

..... (Or on how to report back?)


>
> 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
'an expected'
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.
<aside> Given some precondition</aside>


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."

Given the caveats I've inserted..
I'd ride with that for a 'starter'

regards


-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk