[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tag] 'Condition' Re: [tag] Groups - TA Anatomy V0.7(AnatomyTA-v07-rtf.rtf) uploaded
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]