Plans for Public Review process updated:

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

As decided in today's call, the plan is as follows:

 

- TC members still have until this week-end (Jan 25) to post last minute updates (only editorial or obvious flaws) to be merged with updates from our tech writer (Dimitri), by Stephen on this coming Tuesday 27.

 

- This will result in a  new final draft, to be set to vote as final CD and Public Review draft starting Wednesday 28th (electronic ballot ending Tuesday Feb 3rd)

 

- Our editor Stephen has liberty to decide what updates should go in the final draft. In particular, if there is anything controversial (i.e. opposition on the mailing list, before Tue 27) to a proposed update, it should not be part of the final draft.

 

- If the final draft is approved as CD and for public review, we discuss the public review process at next session A meeting (Wed February 4th). We'll have a session B meeting also Wed 28.

 

- Meanwhile, Version 0.999 has been voted today a Committee Draft (CD), meaning it can be posted on our Web page and also communicated outside as internally approved (although still work in progress)

 

- At next meetings we discuss our contacts with "selected reviewers" in other orgs, from whom we may want to make sure to get some feedback during the PR phase. 

 

 

Jacques

 

 

 

My own editorial comments below:

 

-------------------------------------------------------------------------------

1. In Introduction/Scope:

 

 

"These guidelines are intended to apply to any technology or business field but some of the text may apply

more to software engineering which is the primary focus."

 

Is still too heavily slanted in favor of "software engineering". In fact, all this applies very well to "information" specs such as documents, etc. not just software specs.

 

Suggest to replace with the following:

 

"These guidelines are intended to apply to any technology or business field. However, some parts of the "Advanced Features" section may be more inspired from the software engineering area."

 

-------------------------------------------------------------------------------

2. In 1.2: just after Fig 2

 

Reword:

"There is always a need to make explicit the relationship between a test assertion and the normative

statement(s) it addresses in the specification."

As:

"A test assertion must explicitly refer to the normative statement(s) it addresses in the specification."

 

We need to introduce why suddenly we talk of Conf clause and test cases, in a section that is titled "What is a Test Assertion?"

 

Suggest to add an introductory sentence Just before:"The specification will often have one or more conformance clauses1 [CONF1][CONF2]..."

 

Add: "A Test Assertion should not be confused with Conformance Clause, nor with Test Case."

 

Also, reword sentence below:

"Reference to definitions of the following terms in the Glossary, Appendix A, may avoid confusion between

related concepts: 'Conformance Clause', 'Test Assertion', 'Test Case', 'Test Metadata' and 'Tag'."

 

As:

"Reference to definitions of the following terms in the Glossary, Appendix A, will clarify further these related concepts: 'Conformance Clause', 'Test Assertion', 'Test Case', 'Test Metadata' ."

(because the previous paragraph should already have done a good job removing possible "confusion" . Also, "tag" is not a major concept  the reader has to worry about that early in the guidelines.)

 

At the end of 1.2:

"Such test assertions can then be use as a blueprint for test suites."

We should make it clear that in the former case (no knowledge of testing conditions), TAs can *also* be used as a starting point for test suites. So, reword as:

"Such test assertions can more easily be use as a blueprint for test suites."

 

-------------------------------------------------------------------------------

3. In introductory bullet list for Section 3:

Last bullet:

"test assertion targets which are categorized in conformance clauses."

remove the reference to conformance clause (not needed), and maybe mention instead:

"test assertion targets which are categorized and/or related (inheritance, composition)."

-------------------------------------------------------------------------------

4. - replace "NotApplicable" by "NotRelevant" (in Sections 2.1, 3.2 and Appendix)

 

Rationale:

- When the Prerequisite fails, the TA has still been (partially) applied, as the Prerequisite is part of the TA. So it is not correct to say it is 'not applicable'.

- The keyword 'NotApplicable' will be more appropriate when a TA does not match any suitable target at all in an implementation. That is out of scope of our guideline, but test engines will want to use this keyword in test reports, so suggest to not use it here.