Re: [tag-discuss] TA definition

[Vladimir Sosnin <Vladimir.Sosnin@Sun.COM>]

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.

Regards,
Vladimir
begin:vcard
fn:Vladimir Sosnin
n:Sosnin;Vladimir
org:Sun Microsystems Inc.;J2SE JDMX BU322
adr:;;;St. Petersburg;;;Russia
email;internet:Vladimir.Sosnin@Sun.COM
title:Software Engineer
tel;work:x33105
x-mozilla-html:TRUE
version:2.1
end:vcard

S/MIME Cryptographic Signature