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: '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/AnatomyTA-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
>





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