RE: [tag] 'Condition' Re: [tag] Groups - TA Anatomy V0.7(AnatomyTA-v07-rtf.rtf) uploaded

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

Stephen:

Point well taken about the misuse of the term "condition".

At the F2F, we did not have a strong consensus on what this part of a TA
should be named after. We used "assertion expression" but on second
thoughts, that seemed to me not precise enough, could be confused for
the entire TA definition, and not convey precisely enough the true/false
value it is supposed to evaluate to.  

We had considered "predicate"  before, and I was concerned it could
sound a bit too technical (that is why I proposed the more intuitive
"condition" instead).
But I agree "predicate" appears as the most appropriate term (or
"assertion predicate") instead of "test condition" I used in V0.7. 

"Condition"  should indeed better be used in an "if...then..."  context.
There are predicates that can be expressed in conditional form (see the
"conditional assertion of UniSoft glossary:
http://www.unisoft.com/glossary.html), in which case such predicates
will have a "condition"  part.

Now, about "pre-condition", it is again an intuitive term. But it should
not be considered as contributing to the true/false evaluation result of
the "assertion predicate". It is a mere qualifier of the target, before
even evaluating the "predicate". Alternatives are:
- qualifier, which is focused on the target (does it qualify for the
TA?)
- prerequisite, which allows for a broader interpretation (e.g. some
state or context not necessarily reduced to a target property/behavior)

So I'd propose:
- "predicate" (or "assertion predicate") isntead of currently "test
condition" in V0.7
- "prerequisite" for what we considered the pre-condition, which could
also include the fact that the target (or part of it) is supposed to
evaluate to "true" 
 
Would that work for everyone?

Jacques


-----Original Message-----
From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk] 
Sent: Saturday, December 15, 2007 4:36 AM
To: tag@lists.oasis-open.org; frederick.boland@nist.gov
Subject: [tag] 'Condition' Re: [tag] Groups - TA Anatomy
V0.7(AnatomyTA-v07-rtf.rtf) uploaded

We seem, with the matter of test assertions, to be plagued by words with
multiple meanings, especially words whose multiple possible meanings all
relate to aspects of our subject matter.

Take: 'predicate'
this has a logical meaning useful to us: an expression evaluating to
  true or false
it also has a lexical meaning, again useful to us: the part of an
assertion which is the assertion minus its subject (target) Strangely
the overlap of these two meanings is fortuitous to us since it so
happens we mean both of these things and they do not contradict very
much. So a test assertion predicate means
logically: the whole test assertion
lexically: the part of the test assertion other than the subject/target

Another problem word is 'when' which can have two differing uses with
test assertions 1. as part of an expression much like 'if' - its use in
programming
    so that 'if ... then ...' can also be written 'when ... then ...'
    ('when' being similar or synonymous with 'while' in such
expressions) 2. as a way to describe the target behavior at the time an
event occurs
    such as 'when the event A occurs then the behavior Y occurs'


Another word with multiple meanings, all of which relate to test
assertions, is 'condition'.
One sense is that of qualifier to a logical predicate:
the logical meaning being that part of an expression which accompanies
the qualifiers like 'if...', typically following the 'if'.
Another sense is as the generalization of our technical construct
'precondition' which we are saying qualifies the test assertion but
which is outside of the part of the assertion expected to be tested and
so acts as an assumption.
Another sense again is in 'postcondition' which we see in other TA
structures where its meaning relates to its use as a means of relating
the true or false evaluation to the pass or fail outcome.

With these existing meanings of 'condition' it worries me that we might
add yet another meaning by using it to refer to the expression as a
whole. I would really rather see it used as the part of an 'if..'
expression between the 'if' and 'then'.

So if a test assertion has 'if' expressions attached to it there can be
two ways of doing so 1. as part of what is to be tested 2. as part of
the assumptions which aren't necessarily the part to be
     tested (but the TA is only relevant if they are true) Both of these
are just a part of the TA, 1. being more a part of the TA expression.
If any of a TA were called 'condition', in my view it would be either
the part of 1. or 2. which followed the 'if' or MAYBE 1. or 2. as a
whole find it a bit confusing if 'condition' is used of the TA as a
whole.

--Steve


Quoting jdurand@us.fujitsu.com:

> Update based on F2F discussions, using terminology aligned with latest

> glossary proposals, etc. The section is still incomplete, but posted 
> for early review before Wed 19th meeting.
>
>  -- Mr Jacques Durand
>
> The document revision named TA Anatomy V0.7 (AnatomyTA-v07-rtf.rtf) 
> has been submitted by Mr Jacques Durand to the OASIS Test Assertions 
> Guidelines
> (TAG) TC document repository.  This document is revision #3 of 
> AnatomyTA-v04.doc.
>
> Document Description:
> The section has entirely been remodeled.
> - TA is introduced first in its "structured" version.
> - TA parts are introduce gradually, on the basis of their rationale.
> Special emphasis on the "test outcome".
> - so far, no mention on pre-condition (it seems to blend in "test
trigger"
> at least in examples used.)
> - no mention of post-condition (yet).
> - the "prose" TA is introduced as a variant of above structure, where 
> unmentioned parts are automatically inferred from a rule, instead of 
> just absent.
> V0.6:
> - a few corrections based on comments (e.g. stated the default
dependency:
> not(Pass)-> Fail)
> - tried to illustrate better the notion of "test trigger" (renamed 
> here Test Flow), for review.
> - more semantics on pre-requisites, test trigger/flow.
> - various edits.
> V0.7:
> - serious rewording, based on F2F discussions. Still incomplete.
>
> View Document Details:
> http://www.oasis-open.org/apps/org/workgroup/tag/document.php?document
> _id=26485
>
> Download Document:
> http://www.oasis-open.org/apps/org/workgroup/tag/download.php/26485/An
> atomyTA-v07-rtf.rtf
>
> Revision:
> This document is revision #3 of AnatomyTA-v04.doc.  The document 
> details page referenced above will show the complete revision history.
>
>
> PLEASE NOTE:  If the above links do not work for you, your email 
> application may be breaking the link into two pieces.  You may be able

> to copy and paste the entire link address into the address field of
your web browser.
>
> -OASIS Open Administration
>




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php