Software reliability depends heavily on defects in a software product and a repair activity undergone to correct them consequently as an entity to characterize these defects, Faults is used. Fault can be defined as defective, missing or extra instruction or set of relative instruction that is the cost of one or more actual or potential failure types. The program is executed and faults are counted by observing the repair actions taken in response to failures. Number of faults in software is a difference between the number introduced and the number removed by the repair activity.
Faults are introduced when the code is being developed by programmers. They may introduce faults during original design or when they are adding new features making design changes or repairing faults that have been identified. Developed code is defined as instructions that have been created or modified. In general, only code that is new or modified results in fault introduction. Code that is inherited from another application does not usually introduce any appreciable number of faults except possibly in the interfaces because it generally has been thoroughly tested and debugged in the previous application. The process of fault removal introduces some new faults because it involves modifications or writing of new code. Two major approaches to the concept of faults are Absolute and Operational faults.
The Absolute concept view the fault as an independent entity that can be identified without reference to failure as an entity that may exist only with reference to actual or potential failures. Potential indicates that failure will occur for input state if the state is executed. In the operational view, we would define the fault as a defect that is the cause for a particular failure time. Absolute concept makes it necessary to postulate a perfect program to which an actual program can be compared. Then the fault is a defective, missing or extra instruction or set of instructions. It may be an instruction in the perfect program that is not matched in the proper sequence in the actual program. Alternatively it may be an extra instruction in the actual program.
Operational concept of a fault refers to an implementation defect and the implementation has the physical reality. Faults have an independent reality, but is one that is not fully known until the program been thoroughly inspected and executed. The discovery of faults usually occurs through observation of potential failures by code inspection or actual failures by execution and output state inspection.
Fault removal depends on occurance of the associated failure. Occurrence depends both on the length of time for which the software has been executing and on the execution environment or operation profile. When different functions are executed, different faults are encountered and the failures that are exhibited tend to be different. Faults can also be found without execution through inspection, compiler diagnostics, design or code reviews. Fault removal is also dependent on the efficiency with which faults are found and removed.
The set of input states that produces failures for a fault at any point in time will be called it Fail Set. Repair activity involves changing the size of fail set. A fault is considered, removed or completely repaired when the fail set if null. A partial repair has occurred in the size of the fail set, changes but does not reach zero.
The two types of fault detection process are – Direct and Indirect fault detection methods.
Direct methods do not involve actual execution of program such as requirement reviews, design reviews, code reviews, walkthroughs and inspections etc.
Indirect methods detect faults while executing the program during testing or in real operation.