[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tag-discuss] the role of an XML mark-up for TAs
|
Dave: Right. (3) should be reworded as : > 3. Test cases model and
metadata. At least this is what I captured from recent exchanges between David M.
(11/23) and Abbie, but I may have conjectured too much. Agree with you that is hard to see within scope other than as examples.
I’m ready to write off (3) anytime. Probably we should be more precise when we talk of: (a)- test assertion (b)- test case (c) – test I suggest we avoid saying just “test”. For (a) and (b), Here are some definitions that I have borrowed from a
few sources: Test Assertion:
a Test Assertion is a statement of behavior for an implementation: action or
condition that can be measured or tested. It is derived from the
specification’s requirements and bridges the gap between the narrative of
the specification and the test cases. Each test assertion is an independent,
complete, testable statement on how
to verify that an implementation satisfies a conformance requirement. Test Case:
Consists of a set of a test tool(s), software or files (data, programs,
scripts, or instructions for manual operations) that checks a particular
requirement in the specification to determine whether the results produced by
the implementation match the expected results, as defined by the specification.
Typically, a Test Case exercises (and is derived from) one or more test
assertions. Each Test Case includes: (1) a description of the test purpose
(what is being tested - the conditions / requirements / capabilities which are
to be addressed by a particular test, (2) the pass/fail criteria, (3) a
reference to the requirement or section in the standard from which the test
case is derived (traceability back to the specification), or to related test
assertion(s). Do we agree on these or should we refine them, so that everyone on the
list is in sync as of what is being discussed? -Jacques -----Original Message----- On 27/11/06, > I think so far we have discussed three types of spec/guideline
material, > and we'll have to decide which ones are within scope of a first
TC: > > 1. A [simple] guide for writing test assertions, the goal of which
is to > provide some basic guidance to most groups and TCs working on a > specification. This guide contains a model of what a TA is (what
are its > parts, what they mean, how they relate to the spec narrative,
examples, > and to an underlying test set-up, etc.), but in an entry-level and
easy > way ("TAs for dummies"). Some on this forum have stated
that this guide > alone has value. I see this as having some value, at least to make spec writers aware that a spec para should be verifiable for compliance. > > 2. An XML representation of test assertions. Some purpose for this > representation should be preferably agreed on, as the design may
vary > depending on whether it is for (a) just a support for the TA
guide, (b) > Web publishing, (c) drive a test suite, (d) help generate test > suite/test cases. -0 I really don't see that mandating XML as the way in which tests are
expressed is useful? For some it will be that the XML will be an unecessary
wrapper for simple text. > > 3. Test cases and a representation of these. How might this be a part of the scope? At best these could be examples, or the test specification for this TC's spec! I'd prefer to see if 3. A detailed specification of what is allowable and not within specifications, identification of normative (verifiable) and informative paragraphs. I.e. a far more specific requirement. I'm unsure if this would either be acceptable, or writable! > > I think that the goal "To get better (verifiable) specs from
Oasis." > will be largely served with (1) above. This sounds like the first step. How ambitious can the group be? > (3) really makes me > uncomfortable... there is already a lot done in this layer, and in > various forms (e.g. Abbie may be familiar with TTCN-3 in telecom.
There > is also ATML, and more) - so smells like a can of worms to me...
and > lots more work). +1 on the lots more work if my definition matches the authors. (though unknown acronyms don't help with understanding). I'd like to hear more on what is meant by 3 before commenting further. regards Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk --------------------------------------------------------------------- To unsubscribe, e-mail: tag-discuss-unsubscribe@lists.oasis-open.org For additional commands, e-mail: tag-discuss-help@lists.oasis-open.org |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]