tag message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Some issues on current draft
- From: "Durand, Jacques R." <JDurand@us.fujitsu.com>
- To: <tag@lists.oasis-open.org>
- Date: Tue, 19 Feb 2008 09:08:52 -0800
I submit by email
these issues on the current draft, having no current access to OASIS
site.
(will file them on
wiki)
-Jacques
Issue
050:
[in
Section 1.1] ". In the simplest
case, an assertion may simply consist of text from within the
specification."
This
is a confusing statement that seems to undermine what we say later about
"mandatory"
components
of a TA.
We
expand enough later on , on the possibility to define "implicitly" several parts
of a TA, so that the
work
of defining a TA can be reduced - in some cases - to just referring to
some spec statement.
But
even then, the TA still consists of more than the spec reference - the implicit
parts (e.g. as derived
from
a rule) are still part of the TA even if not explicitly
defined.
Proposal:
remove this statement.
Issue
051:
[in Section 1.1] ". Sometimes an assertion is
included which is not testable: it acts as a placeholder to represent a
requirement not considered testable. It should be clear that
testing of this assertion is not expected"
This is confusing: Assuming
"assertion" here means "test assertion", that conflicts with the 1st sentence of
the section 1.1 defines TA as "...action
or condition that can be measured or tested". If there is some exception case to
expand on where a TA is deliberately not testable, I would not discuss it in the
Rationale section (confusing) but in a mor advanced section. As it stands at the
beginning of the guideline, this statement does not give me any useful
information - only confusion.
Proposal:
remove this statement.
Issue
052:
Title
of 2.3 "A More COmpex Case" might need rewording: it should not be understood as
something unusual that goes beyond "simple cases" - it is just a continuation of
basic design principles - only one step further in difficulty (but still on the
very "basic" side - explaining something everybody will
face)
Proposal:
replace with something like "Some Simple Design Rules" or the
like.
Issue
053:
Section
2.2 "Creating Test Assertions" is an insert that breaks the flow between
2.1 "What is a Test Assertion" and its follow-up (Section 2.3) in this
tutorial-style progression.
The
"Testability" subsection has overlap with other more general material in the
guide.
Proposal:
This section (2.2) needs probably to be broken down and redistributed: It has
both some introductory material that should belong to a prior section (or maybe
to a "best practice" insert somewhere else), and some quite challenging examples
that are better off being addressed later.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]