|
|
 | | From: | H. S. Lahman | | Subject: | Re: Every software defect should be able to reproduce?? | | Date: | Tue, 11 Jan 2005 21:37:21 GMT |
|
|
 | Responding to Jrefactors...
> If the testers find a bug (unexpected behavior) in software, but that
> bug cannot be reproduced every single time for the same input, or maybe
> because of the environment setting problem, we may consider it as an
> intermittent bug? But we should still consider this as a bug?
It depends on how you define 'bug'. B-) Generally the test literature
distinguishes between the notions of 'fault' and 'defect'. A fault is
any failure to meet requirements. A defect is a fault that is traceable
in a causal fashion to the software. Conventionally the term 'bug' is
usually associated with faults (e.g., "The system has a bug" is
different than "There's a bug in the software.")
Any intermittent failure would be a fault _when it occurs_. Whether it
represents a defect in the software is another issue entirely...
>
> I think every bug should be able to reproduce, there may be other
> variables to consider: configuration setting, environment, OS, etc...
> If we can match all those variables, the bug is able to produce.
> Otherwise, this is not a bug.
The conditions under which a fault is generated will always be
deterministic. (Whether they are known is separate issue.) But
conditions are different than the mechanism that causes the fault to be
manifested when those conditions prevail. I think it is important to
distinguish the mechanism from the conditions.
For example, different conditions can trigger the same mechanism. So an
intermittent fault could result under different
circumstances due to the same defect in the software. Similarly, in
asynchronous environments one can have a different fault mechanism
activated in some cases even though exactly the same conditions
prevailed to trigger the fault (i.e., one effectively has a race
condition to determine which mechanism will be triggered). This raises
the interesting question about whether the /combination/ of conditions
and mechanisms constitutes a unique fault.
Just to complicate things a bit more, I have to point out that even
conditions and mechanisms can get blurry. Consider a classic memory
write problem where heap memory is trashed by an out-of-bounds write.
The write may occur long before a subsequent read that manifests the
fault. In fact the write might /always/ occur but most of the time the
memory is rewritten correctly before access, so it will only be
intermittently manifested as a fault.
The condition seems fairly clear: the bad write occurs AND there is a
read of the memory prior to correction. But what about the mechanism?
Is it the bad write or the read that actually triggers the fault? From
a defect perspective one would tend to think the bad write was the
mechanism because it isolates a software problem. But from the
perspective of meeting requirements, there is no failure unless there is
an actual read of the data.
Generally it is easier to classify faults based upon the conditions
while it is easier to classify defects based upon the mechanism. So in
the example one would likely create a fault type for the condition, like
Memory Access Error. But one would tend to map the defect into the
mechanism of the bad write as a Memory Write Error.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH
|
|
|
