OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tag-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [tag-discuss] TA definition

Dave Pawson wrote:
> On 01/02/07, Durand, Jacques R. <JDurand@us.fujitsu.com> wrote:
>> 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]".
> The royal we is back :-)
> 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")?
> No, otherwise there is no need for testing. The Item | Unit under test is
> of unknown conformity until tested.
>> 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.
> Test scenario?
> Not module implementation though?
> Implementations?
> 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).
> I'd view that as a different I | U UT, i.e. the two beasts are
> different, sender and
> receiver.
Sender and receiver are roles in some context and for such case it could 
be assumed or not by TA. But concrete test item 
Interface|Method|Parameter (or anything else like them) can be 
explicitly stated.
>> 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."
> I object to the use of 'implementation'. I see the point of it, but
> dislike the term.
> It implies I can implement the item in n different ways. Fine, but
> nothing to do
> with testing. IUT configuration perhaps? Or simply its IUT A or IUT B.
>> If nobody complains, I'll use this wording in the coming charter 
>> draft....
> Take mine as a complaint.
> Modified proposal.
> "A TA always assumes an item under test(IUT). When necessary, the TA
> may identify  the item explicitly in some appropriate manner. A TA may
> refer to an abstract test harness architecture that characterizes test
> components in terms of their interaction with the IUT.
I have a simple proposal for this definition. I prefer to change 
"assumes" to "refer" (or like this). It's because TA defined in 
specification can be introduced in a: requirement, use case, scenario, 
example; but it always says about specific test item for which it can be 
verified. So, TI is a natural part of TA and definition of TA should 
contain such property.

fn:Vladimir Sosnin
org:Sun Microsystems Inc.;J2SE JDMX BU322
adr:;;;St. Petersburg;;;Russia
title:Software Engineer

S/MIME Cryptographic Signature

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]