[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tag-discuss] TA definition (formerly RE: surviving the winter break)
Ooops - speaking for myself indeed! Although speaking for Patrick (and Abbie) as well it seems.
Now, thinking again about this, I think the "how" in "how to verify" should not be too strictly interpreted: 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".
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."
From: Dave Pawson [mailto:firstname.lastname@example.org]
Sent: Tuesday, January 16, 2007 12:50 AM
To: Durand, Jacques R.
Subject: Re: [tag-discuss] RE: surviving the winter break
On 16/01/07, Durand, Jacques R. <JDurand@us.fujitsu.com> wrote:
> Indeed the "how to verify" could be understood in a very concrete way
> (as defined in a test case), which we do not want.
> Do we agree on this?
Are you speaking for yourself Jacques?
Or on behalf of all of the mailing list?