RE: testability definition

On Sun, 8 Sep 2002, Kirill Gavrylyuk wrote:

> Alex, I found your statement interesting:
> > I do not need to prove that the process can be built. I need to apply
> > an existing process to an existing implementation or document. I do
> > not care if a spec is testable in some abstract way.
> which I read that you don't care whether the spec is testable or not,
> you care whether the particular implementation is testable.

I care whether the spec specifies testable implementations (among
other things). I cannot comment on the above until you provide
definitions of spec (done below) and implementation (missing?)

> Those 2 are a bit different notions.  The spec is testable when:

> - you can check all the requirements stated in it

I do not know what "check" means anymore. Do you mean "find/isolate"?
Note that the current definition of testability, that you said you
have no problems with, says "check that a requirement has been met". I
do not think you can perform that kind of check without an
implementation because it is the implementation that meets the
requirement, not the spec itself. So something does not add up here.

> - the requirements are unambiguous

OK, though you would need to define that adjective too.

> - the behavior for every possible input is addressed.

OK. Though I am unsure how this is related to testability. If behavior
for some input is not defined, you can still test with other inputs.
This smells more like a "complete coverage" requirement to me.

> One can build testable and not testable implementation for a testable
> spec. A testable implementation does not mean the spec is testable
> either.

What's your definition of a testable implementation? Without it, I am
not sure I understand the distinction you are making.



                            | HTTP performance - Web Polygraph benchmark | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

Received on Monday, 9 September 2002 01:24:33 UTC