RE: testability definition

I think the definition is fine as it is - after removing 
"cost-effective".  We may want to add, A testable specification uses 
concrete terms and measurable quantities, and avoid words such as "works 
well", "looks good" or "shall usually happen".  Additionally any ambiguous 
requirement is not testable.

This definition is consistent with an IEEE definition - which goes on to say:
-- Statements such as "the program shall never enter an infinite loop" is 
non-testable, because the testing of this quality is theoretically 
impossible.  An example of a testable statement is:  Output of the program 
shall be produced within 20 s of event x 60% of the time; and shall be 
produced within 30 s of event x 100% of the time.  This statement can be 
tested because it uses concrete terms and measurable quantities.

If a method cannot be devised to determine whether the software meets a 
particular requirement, then that requirement should be removed or revised."

regards
Lynne


At 01:24 AM 9/9/02, Alex Rousskov wrote:

>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?)
>testability.
>
> > 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.
>
>Thanks,
>
>Alex.
>
>--
>                             | HTTP performance - Web Polygraph benchmark
>www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
>                             | all of the above - PolyBox appliance