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: Some issues on current draft


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]