RE: [tag-discuss] TA definition

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

>Does TA definition reference some specific "entity" under the test  or it just say
>about something that could be implemented?

If we assume (even implicitly) some kind of test harness as context to the existence of a TA, as several of us believe based on recent mails, I believe we also assume an entity called "the implementation [under test]". I looked into W3C QA framework doc and did not find much said about what is pervasively referred to as "a conforming implementation".

Does a TA have to say more about "a conforming implementation" of the target spec (can we asume all TAS are implicitly about the same "conforming implementation")?

Because a specification may have modules and profiles (quoting W3C QA fmk), in some cases I believe it will be necessary to be more specific about which implementation profile or of which module implementation we are talking about. For example, if a messaging specification assumes that implementations may take either a "sender" role or a "receiver"  role (not necessarily both), a TA would not be meaningful if it does not refer to which role is under test (often this role can be inferred from the TA wording - e.g. "if an implementation sends a message..." --> "sender" role , but that kind of hint may not be reliable). 

Keeping this discussion focused on finalizing the charter, I would propose to extend our TA def as follows (see two first sentences added to previous extension):

"A TA always assumes an implementation under test. When necessary, the TA may characterize the implementation that is under test, e.g. by identifying the specification profile or module covered by this implementation. A TA may refer to an abstract test harness architecture that characterizes test components in terms of their interaction with the implementation under test. A TA may specify which interactions or operations between implementation and test harness are expected to be observed or exercised."

If nobody complains, I'll use this wording in the coming charter draft....

-Jacques

-----Original Message-----
From: Vladimir.Sosnin@Sun.COM [mailto:Vladimir.Sosnin@Sun.COM]
Sent: Wednesday, January 31, 2007 11:07 AM
To: Durand, Jacques R.
Cc: Dave Pawson; tag-discuss@lists.oasis-open.org
Subject: Re: [tag-discuss] TA definition (formerly RE: surviving the winter break)

Durand, Jacques R. wrote:
>
> Dave:
>
> 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."
>
> Anyone disagrees?
>
I think that phrase "describes the expected output or behavior for an implementation" needs some clarification. Does TA definition reference some specific "entity" under the test  or it just say about something that could be implemented? If it describe "entity" then such entity should be explicitly defined as part of specification or a part of TA definition. If it generally says about something that could be implemented then it's not as much useful for automated processing.

Regards,
Vladimir

--
Vladimir Sosnin
Sun Microsystems                   vladimir.sosnin@sun.com