OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [tag] some thoughts and comments from reading a month worth of messages


On 20/09/2007, Serm Kulvatunyou <serm@nist.gov> wrote:
>
>
> 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.

Isn't this just a case of establishing clear boundaries?
For any test the UUT must be in a stable state (stable is variant, I've tested
where the stability was a 4uSec window, but it was stable none the less) in
order for the test to take place. Anything which is necessary to define that
stable state is a precondition (including timed events).




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.

If it is necessary for the test to work correctly it is a pre-condition.
If it is switched on as part of the test it it just that, part of the test.


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.

Boundaries could produce a variation. Two things.
1. After a test pass the UUT must be in a  known state.
2. After a test fail the UUT may be in one of N states depending on
the failure mode.

If something is necessary to evaluate the pass/fail it is part of the test, not
a post-condition. I.e it may change due to testing actions.



The
> post-condition may be empty,

In which case there are no post conditions, but that seems highly unlikely
with a real world scenario.



> There were some discussions about TA testability. There is a proposed TA
> defintion which implies that all TAs must be testable.

I get twitchy with this. How meta do you want to go?
If I write a TA for a TA, do I write another for that TA?
I'd propose that this is generally not required.



> 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.

Sun may have found a use for XML markup in testing. I'd find it very
hard to apply in the general case without the real meat being in the
embedded prose of the mixed content.


>
> 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.

Experience may dictate otherwise. DoD specs nest almost infinitely deep :-)
A good example of implicit tests.



> What is the definitive point of what is an implicit vs. explicit reference?

Example, from the above.
  A spec  for some sort of electrical item. The implicit test is that the
item complies with relevant electrical safety specifications. Unlikely
to be stated explicitly within the body of the spec, other than by
some embracing statement.


>
> 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.

See my other email. I do think this needs to be very clear to avoid
confusion by any readers. The simplest response is to establish
a hierarchy of the TA and the requirement on which it is based.
The requirement takes full precedence over the TA covers that.

regards

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]