tag message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: some thoughts and comments from reading a month worth of messages
- From: "Serm Kulvatunyou" <serm@nist.gov>
- To: <tag@lists.oasis-open.org>
- Date: Thu, 20 Sep 2007 16:51:36 -0400
I would like
the recall the discussion I had with JD when we sketching the TA model.
We didn't like the pre-test and post-test conditions because the
antecedent and consequences encompasses more than just conditions as it could also be event
and/or action. So we tried to make it
general. One of the reason we didn't want
to go into the specific of separating the pre-condition, action, and event
because one form could be written using another form and event and action may
contain conditions. For example, the condition "the light is on" could be
written as an event "the system turns the light on", so is this consequence a
test affect or a post-condition or both. Given the recent version of the TA
model, maybe we can clearly
distinguish the test affect and post-condition in that 1) post-conditions
indicate the state the IUT and/or environment need to be in in order to evaluate
the test affect which leading to the pass/fail outcome. The post-condition may
be empty, but if it is not it is a prerequisite the the test affect, i.e., if
post-condition is not met the IUT cannot be evaluated to fail hence the outcome
is "cannot be determined" (or "technical fail" may be is a common term used in
IIC). 2) test affect is everything else beyond the post-condition that is
necessary & sufficient for determining the "pass" or "fail" outcome. The
point is we need more guideline.
There were some discussions about TA
testability. There is a proposed TA
defintion which implies that all TAs must be testable. It is common that some specification requirements are not testable or partially testable, does it mean that we need no TA for them?
I think we just use UML as non-normative for
illustration and explanation. We don't want to deal with the issue to map UML to XML/marks up.
I think as far as spec dependency, it seems
like if writing a TA for a specific specification, conformances to other dependent
specs can be easily stated. However,
if writing TA for something like a SID (standard
integration deployment) profile, TA needs to be
sort of cross-spec. In that case, a TA for SID may need to ref individual TA in
each related spec.
I generally
lik the Rationale for Test Assertion is by Patrick Curran but I think some workdings need to be revised. It can
be used for motivation/background section of the TAG
doc.
What is the definitive point of what is an implicit
vs. explicit reference?
Concerning one of the Dave Pawson comments, I think
the separation of the TA from MUST, SHOULD, MAY
in the specification is the right statement. It is true that TA always indicate
the MUST conditions, but I think we are making an
argument that we want to separate TA from determining the level of conformance. That is what JD is saying is that
regardless of MUST, SHOULD, MAY that is
associated with the requirements in the spec, TA only indicates condition to determine whether the requirement is
met.
It seems like the
current annatomy of TA
includes (in order of increasing formality/machine friendliness):
-
Prose - normative for human
consumption
- Pointer to
specification - normative for human consumption
and analysis
-
TA Model - detail break down of TA
components
-
Serm
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]