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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag message

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


Subject: Re: [tag] Groups - TA Anatomy V0.4 (AnatomyTA-v04.doc) uploaded


On 20 Sep 2007 00:24:55 -0000, jdurand@us.fujitsu.com
<jdurand@us.fujitsu.com> wrote:
> material for "Anatomy of a TA"  section, updated after F2F and mail list
> comments.

Further comments:

Characterize the item under test (or IUT) -

'characterize' needs definition.  None of the examples are explicit.
Suggest. Define the item under test sufficiently to enable its
selection, e.g. Part title, Part number, build specification, version
number.

performed on the item under test or on the test environment,

Clarification on 'test environment'. Used without definition.

Although two tests are actually involved, a single TA is appropriate,
as these tests are about the handling of a same feature (the radix) by
the same function.

Unclear, confusing, suspect English. The word radix appears out of context.

(e.g. it should not tell where to find the argument values to be used
– this is the role of a test case).

Where is the differentiation between test assertion and test case?
Isn't the latter an
instantiation of the former? Clarify please.

Conversely, in many cases, it is acceptable to be less explicit than above.

This is supposed to be a defining document. This only confuses.

A test assertion ignores the keywords MUST, SHOULD, MAY because its
focus is on the feature to be verified on the item under test.

I quite disagree with this statement. IMHO a test assertion MUST




-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk


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