Re: [tag] Section 3.7 Specification Versions

["Stephen Green" <stephen.green@documentengineeringservices.com>]

Many thanks Paul. I've added this to the wiki Test Assertions Guidelines
- which now look remarkably complete:

http://wiki.oasis-open.org/tag/TestAssertionGuidelines?action=recall&rev=229

I'll start work today turning the wiki text into the latest document draft.

Thanks again

Best regards

Steve

2008/9/24 Paul Rank <Paul.Rank@sun.com>:
> Hi Stephen and all,
> The following is my revision to section 3.7 Specification Versions.
> Comments?
> Thanks,
> Paul
> ===================================
> 3.7 Specification Versions
>
> Where a specification is the basis for test assertions there needs to be
> consideration of how to support further versions and maybe any previous
> versions of that specification.  One solution is to create a set of test
> assertions for each version.  The references to specifications may include
> the identification of the precise specification version but this may
> restrict that test assertion to just one version of a specification. Such a
> simple strategy is less than ideal as it results in a need to re-author the
> test assertions each time there is a new specification version.
>
> Another method of dealing with multiple specification versions is to create
> a repository of test assertions for a specification and properly tag each
> test assertion for the versions of the specification where it is valid.
> This can be accomplished by introducing 2 tags, VersionAdd and VersionDrop.
>
>    tag: VersionAdd: the lowest numerical version to which the test assertion
> applies.
>    tag: VersionDrop: the lowest numerical version number to which the test
> assertion does NOT apply.
>
> Both VersionAdd and VersionDrop are optional tags.  The absence of both tags
> would mean that the test assertion is valid in all specification versions.
> If only a VersionAdd tag exists and its values is X, the test assertion will
> be valid in version X of the specification and all subsequent versions.  If
> only a VersionDrop tag exists and its values is Y, the test assertion will
> be valid in all versions of the specification prior to version Y.  If both
> VersionAdd and VersionDrop tags exist, the test assertion will be valid in
> version X and all subsequent version up to (and not including) version Y.
> Based on these rules, one can easily generate the set of test assertions
> that apply to a specific version of the specification.
>
> Care must be taken when going from one version of a specification to
> another.  The test assertion author must identify all test assertions that
> are the same between versions, that are dropped from one version, that are
> added to one version, and that modified between versions.   Test assertions
> that are the same, are dropped, or are added can easily be handled with the
> VersionAdd and VersionDrop tags.
>
> Test assertions that are modified are trickier to handle.  One could treat
> the modified test assertions as two separate test assertions and tag them
> with the appropriate VersionAdd and VersionDrop tags.  Unfortunately, this
> approach does not provide any indication that the updated assertion is
> related to the test assertion in the prior specification.
>
>



-- 
Stephen D. Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606
Associate Director
Document Engineering Services
http://www.documentengineeringservices.com

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice