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 (formerly RE: surviving the winterbreak)


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

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



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