Re: Code Coverage and QC

From: Anthony Williams (anthony_w.geo_at_yahoo.com)
Date: 03/08/04 

Date: Mon, 08 Mar 2004 09:17:01 +0000

"Vladimir Trushkin" <NspamOtrushkin@tut.by> writes:
> You are obviously confusing structured and behavioral testing activities.

Quite possibly. I am airing my ignorance in public in order to learn.

> They have different classes of defect to trigger. Not all of design
> decisions map directly into functionality. Some of aspects of system design
> may be invisible, obscured if viewed from functional perspective. This is
> when code coverage comes to play to help us improve testing as to make sure
> that there will be no path in the code not examined for correctness.

I understand your words, but not the reason behind them. If there are aspects
of the system design which are "invisible, obscured if viewed from the
functional perspective", what purpose are they serving?

Surely the purpose of the application is to perform some function, and any
code which does not contribute to the performing of that function is
extraneous. I include code that contributes to making the function easier,
faster or more pleasant to perform from the user perspective as contributing
to the function of the application; it is also quite clearly visible from a
functional perspective.

>> If there is code in the system which is not executed during normal use of
> the
>> application, it doesn't matter what it does, it is not currently a bug.
>
> Normal use may vary.

True. So you work closely with all your customers to determine how they intend
to use the system.

> You can't predict all the possible defects up-front.

If you could, software development would be a lot easier.

Anthony 

-- 
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.