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 worthofmessages


I agree that a test error is out of scope. If the test has an error
that is hardly the concern of this generalized TA. It is something
for the test itself to cover.

I'm not sure that applies to a test being inapplicable though - the
outcome of a condition not being met. So if conditions are not met
in a flow the flow might stop or take a particular branch. If the
conditions are not met in an overall TA the TA is inconclusive. We
then can say that 'inconclusive' and 'inappropriate' amount to the
same thing for the TA as a whole but are perhaps not the right terms
for a flow step.

So maybe we can define how a whole TA reaches results of pass, fail
or inconclusive. Then we can say for a step in a flow the step value
can be pass, fail or something else (not sure we have a term for the
value yet as we haven't said much about chaining steps in flows).

Can a TA overall evaluate to true/false or is it always going to be
pass/fail/inconclusive (inconclusive being an outcome of conditions
not being met on certain steps)?

What about a flow step though?

Quoting Dave Pawson <dave.pawson@gmail.com>:

> On 22/09/2007, stephen.green@systml.co.uk <stephen.green@systml.co.uk> wrote:
>
>> Yes, this is like how I was thinking with the metadata attribute like
>> 'isTrueFalse'. There would be a problem with 'isPassFail' since it
>> might be more than just pass and fail - it might be pass fail or error
>> or it might be pass fail error or inconclusive or even pass fail error
>> inconclusive or inapplicable. It is in some cases determined by the
>> logic of the TA (e.g. depending on whether there are clear conditions
>> to mean a test can be inapplicable/inappropriate) and in most cases
>> determined by the test methodology, to which the TA should be agnostic.
>
> Another scope issue?
> What happens when a test passes / fails (boolean) is an agreement
> with the spec author. If the test has an error (program logic, say)
> then it must fail.
>
> If it is inconclusive, it is badly designed.
> What happens after a pass/fail is an issue for program flow.
>
>
>
>>
>> Maybe the guideline could be that if the value is not boolean (isTrueFalse
>> = false) then it is to be assumed that the outcomes will include pass
>> and fail but not exclusively (other values may be dependent on factors
>> out of scope).
>
> I'd propose that the test is invalid. Define the test pass conditions,
> all else is a fail.
>
>
>
>
>
>
>
>
> --
> 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]