[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tag] Correction: Re: [tag] TA Condition Qualifiers and TA Dependencies
Stephen: inline
-----Original Message-----
From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk]
Sent: Sunday, December 09, 2007 8:56 AM
To: tag@lists.oasis-open.org
Subject: [tag] Correction: Re: [tag] TA Condition Qualifiers and TA
Dependencies
Erratum:
Sorry for the example please read:
Example 1:
Spec: #2: item X MAY have property Y
#3: if item X has property Y then item X MUST have property Z1
#4: if item X has property Y then item X MUST have property Z2
['then item X' instead of 'then item A']
Quoting stephen.green@systml.co.uk:
> I just want to attempt to clarify those couple of points as requested
> in the F2F. Here is an example I'd like to work with
>
> Example 1:
> Spec: #2: item X MAY have property Y
> #3: if item X has property Y then item A MUST have property Z1
> #4: if item X has property Y then item A MUST have property Z2
>
> (Z1 and Z2 might, say, be properties somehow related to Y)
>
> It might be that the spec writers realize they have to further qualify
> this to help with the conformance issue: What happens when #3 or #4
> are not satisfactorily implemented?
>
> case 1: if #3 or #4 fails then #2 also fails
case 2: if #3 or #4 fails
> #2 does not necessarily fail because it is optional
<JD> I would assume that the existence of property Y is somethng that
can be
Tested in itself. In that case, #2 can be tested independently. But to
say that a test "fails" for #2 still need be defined... (does it only
mean that property Y is not there? Because its hard to fail a
MAY...)</JD>
case 3: if #3 then
> #2 fails but if #4 fails then 2# does not necessarily fail
>
> (I'll give a normal life version of Example 1 just to show how
> realistic it might be in a familiar situation:
> Example 2 - some local traffic light requirements:
> If traffic light fails in a part of a road that doesn't need one then
> it depends what sort of failure it is as to whether it MUST be
> replaced: if it fails to light up at all then it is OK but if it shows
> green when it should show red it MUST be replaced or fixed If a
> traffic light fails in a part of a road where it is essential then it
> MUST be replaced or fixed whatever the failure
>
> X = road position
> Y = traffic light
> Z1 = sequencing program
> Z2 = power supply)
>
> back to Example 1
>
> How about the TAs (especially for case 3)?
>
> I would say we can use conditions to qualify the TAs in order to show
> the dependencies between outcomes. This is nothing new, except that
> I'm favoring 'condition' over 'precondition'
> since it covers things where time is relevant - such as cause and
> effect - but also where it isn't - such as logical if..then.
> So I'd see a condition (such as 'when..then' or 'if..then') as a
> qualifier of part of the TA expression.
<JD> In the F2F we considered reusing, as best practice, something close
to the classification introduced by
Unisoft - Glossary of Assertion Based Testing Terms
http://www.unisoft.com/glossary.html
</JD>
>
> Then I'd say the TAs would be additionally linked where there are
> dependencies of the conditions on the other TAs. (This is like the
> 'prerequisite' concept of the WS-I prior art where a 'prerequisite' is
> apparently a precondition which involves another TA - except that here
> I'm separating the two concepts into the link to another TA and the
> condition which says more about how the other TA outcome relates to
> the current TA outcome.)
>
> I feel that conditions and dependencies are more generic than
> preconditions and prerequisites and cover more use cases. I feel that
> we should split (in modeling at least) the separate roles
> prerequisites play of condition/qualifier and TA pointer.
<JD> let us try to isolate a minimal set of carefully picked TAs
illustrating
The possible dependencies between Tas.
</JD>
>
> So:
> The conditions determine test outcomes.
> The dependencies are there to show that the TAs are linked.
>
> Conditions are the qualifiers. The Dependencies are to show that a TA
> uses other TAs. There may be reasons to declare Dependencies to other
> TAs for other reasons too, not just for TAs used in conditions.
>
>
> When the TA is a 'bold assertion' in prose it might contain the
> qualifier(s).
>
> When the TA is derived there is the opportunity to structure it by
> distinguishing the components. *** Aside: maybe a tool could do this
> by sub-highlighting in a different way each different
> component: TA target (subject noun), qualifier(s), verb, object noun
> (value), dependent TA(s), etc. ***
>
> I would go for this structural breakdown of the TAs:
>
> For case 2, perhaps
> TA ID (as usual)
> UUID-TA#2
>
> Spec Ref (as usual)
> UUID-#2
>
> Dependency pointers (links to other TAs required by this one)
> UUID-TA#3 UUID-TA#4
>
> TA Target
> X
>
> TA Target qualifier(s) - some by reference to Dependency pointers
> if UUID-TA#3
> if UUID-TA#4
> (another type of qualifier might say 'when XYZ' speaking
> of an event or time-constrained condition)
>
> TA verb
> has
>
> TA object/value
> property Y
>
> (UUID-TA#3 and UUID-TA#4 are the TAs related to spec statements #3 and
> #4)
>
>
> So the outcome would result from X having property Y but also depend
> on X having property Z1 according to another TA.
>
> In the real-world example:
> The road position has to have a traffic light which has to have
> correct sequencing but not necessarily a power supply.
> The sequencing and power supply have separate TAs to the road position
> TA.
>
> Trickier to deal with case 3.
>
> Although the sequencing of tests is part of the testing, the
> dependencies are so close to the spec requirements as to warrant their
> being expressed as TA conditions and this means relating one TA to
> another and showing that relationship explicitly too.
>
> Best regards
> -
> Stephen Green
>
> Partner
> SystML, http://www.systml.co.uk
> Tel: +44 (0) 117 9541606
>
> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
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]