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 - Intro Material for TA Guide (Rationale.html)uploaded


 
-----Original Message-----
From: Dave Pawson [mailto:dave.pawson@gmail.com] 
Sent: Thursday, September 20, 2007 3:51 AM
To: jdurand@us.fujitsu.com
Cc: tag@lists.oasis-open.org
Subject: Re: [tag] Groups - Intro Material for TA Guide (Rationale.html)
uploaded

On 20 Sep 2007 00:31:23 -0000, jdurand@us.fujitsu.com
<jdurand@us.fujitsu.com> wrote:
> F2F presentation: Intro Material for TA Guide (Patrick Curran)
>
>  -- Mr Jacques Durand
>
> The document named Intro Material for TA Guide (Rationale.html) has 
> been submitted by Mr Jacques Durand to the OASIS Test Assertions 
> Guidelines
> (TAG) TC document repository.

Comments.
Each test assertion is an independent, complete, testable statement of
requirements in the specification.

The 'complete' bothers me. Either define it or remove it. With the other
words it may be unnecessary. It stands pretty well without it.

<serm> Not only the 'complete' bother me, but also the 'independent' because
we are talking about prerequisite. Maybe the right term is 'modular', but
maybe it is better to define whatever term we want to use, e.g., "change in
one TA does not require change in another TA". 'Testable' could be
problematic too because there is no test cases implemented yet, it is only
an anticipation. Maybe we could add a separate sentence that says "TA should
be written with sufficient information that executable test cases can be
derived.", but that may be too risky. I think "each test assertion is a
normative statement of requirements in the specification that assists other
activities in the testing process." can be sufficient. Acknowledging from
the discussion that we are going in the direction of allowing different
levels of formality of the test assertion. </serm>

Re benefits.

I'm uncomfortable with the relationship between coverage and mapping.
Classic of a high level requirement which needs 23 tests. Shown in the
coverage but has a one to many mapping, requirement to tests. Each test is
independent, but the coverage of the requirement isn't complete until all 23
have been run?
Does this need stating? Possibly not, but it is implicit.


Coverage analysis

Define coverage goals for each section.
Each section of what? The test suite? or the specification. Unclear as it
stands.

For each partition,
is this a section?

What percentage of assertions are covered by at least one test?
Should this be requirements? In the requirements document?

Need a way of making it clear which document is being spoken of.

<serm> Is it possible that we are talking about 2 different but connected
levels of coveraage - specification coverage by test assertions and test
assertion coverage by tests (test cases). </serm>


I can see where it's going, I've previously called this the test plan.
I think it needs re-work to aid clarity?

Generally a very useful document. IMHO due a place fairly high in the output
of this SC.

regards




--
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]