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] better example on "testable expression" ?


I think that would be a very decent quote in the guideline.
 
The Note on Testability could become:
 
A Note on Testability
 
"Testability has been defined as follows [1]:
 
- A proposition is testable if there is such a procedure that assesses the truth-value of a proposition with a high confidence level.
 
Judging whether the test assertion is testable may require some knowledge about testing procedures and related constraints. Sometimes there is not much knowledge of what actual testing conditions will be. In such cases the prime objective of writing test assertions is to provide a better understanding of what is expected from implementations in order to fulfill the requirements. In other cases, the test assertions are designed to reflect a more precise knowledge of testing conditions. Such test assertions can then more easily be use as a blueprint for test suites."
 
Jacques


From: Tim Boland [mailto:frederick.boland@nist.gov]
Sent: Wednesday, November 26, 2008 12:07 PM
To: Durand, Jacques R.
Cc: tag@lists.oasis-open.org
Subject: RE: [tag] better example on "testable expression" ?

Would the proposed rewording satisfy a definition of “testability”, for example, from [1], as

 

“testability

A proposition is testable if there is such a procedure that assesses the truth-value of a proposition with a high confidence level”

 

[1]: http://www.w3.org/TR/qaframe-spec/

 

 

-----Original Message-----
From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: Wednesday, November 26, 2008 12:45 PM
To: tag@lists.oasis-open.org
Subject: [tag] better example on "testable expression" ?

 

As the guideline starts to circulate,  here is a suggestion  for illustrating how the predicate could be worded, in a way that is more "testable" than the normative statement, also allowing the TA user (e.g. test suite writer) to not need be an expert in the spec domain:

 

Consider the following as a requirement from a specification on “widgets” :

·         [requirement 100] “A widget MUST be of cuboid shape”.  (cuboid = like a cube but faces could be rectangular)

Here is a test assertion addressing this requirement:

 

TA id: widget-TA100-1

Target: widget

Normative Source: “widget specification”, requirement 100

Predicate: Each one of the [the widget] facets is of rectangular shape.

Prescription Level: mandatory

"The TA predicate is worded as an assertion, not as a requirement (the 'MUST' keyword is absent from the predicate but reflected in the prescription level). It has a clear Boolean value: either the statement is true, or it is false for a particular target. In the above case, it is only assumed that the testing environment has the ability to detect rectangular surfaces - e.g. by optical scan. The wording of the predicate takes this reality into account, instead of just repeating the normative statement - so this TA will provide guidance to a test suite writer who is not expert in 3D-geometry "

 

Jacques



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