Showing posts with label DEFECT CLASSIFICATION. Show all posts
Showing posts with label DEFECT CLASSIFICATION. Show all posts

Defects in Software Products

Software design defects that most commonly cause bad decisions by automated decision making applications include:

1• Designing software with incomplete or erroneous decision-making criteria. Actions have been incorrect because the decision-making logic omitted factors that should have been included. In other cases, decision-making criteria included in the software were appropriate, either at the time of design or later, because of changed circumstances.

2• Failing to program the software as intended by the customer (user), or designer, resulting in logic errors often referred to as programming errors.

3• Omitting needed edit checks for determining completeness of output data. Critical data elements have been left blank on many input documents, and because no checks were included, the applications processed the transactions with incomplete data.


Data Defects

Input data is frequently a problem. Since much of this data is an integral part of the decision making process, its poor quality can adversely affect the computer-directed actions. Common problems are:

1• Incomplete data used by automated decision-making applications. Some input documents prepared by people omitted entries in data elements that were critical to the application but were processed anyway. The documents were not rejected when incomplete data was being used. In other instances, data needed by the application that should have become part of IT files was not put into the system.

2• Incorrect data used in automated decision-making application processing. People have often unintentionally introduced incorrect data into the IT system.

3• Obsolete data used in automated decision-making application processing. Data in the IT files became obsolete due to new circumstances. The new data may have been available but was not put into the computer.

Finding Defects

All testing focuses on discovering and eliminating defects or variances from what is expected.

Testers need to identify these two types of defects:

1• Variance from Specifications – A defect from the perspective of the builder of the product.

2• Variance from what is Desired – A defect from a user (or customer) perspective.

Typical software system defects include:

1• IT improperly interprets requirements

IT staff misinterprets what the user wants, but correctly implements what the IT people believe is wanted.

1• Users specify the wrong requirements

2.The specifications given to IT are erroneous.

3• Requirements are incorrectly recorded

4.IT fails to record the specifications properly.

5• Design specifications are incorrect

6.The application system design does not achieve the system requirements, but the design as specified is implemented correctly.

7• Program specifications are incorrect The design specifications are incorrectly interpreted, making the program specifications inaccurate; however, it is possible to properly code the program to achieve the specifications.

8• Errors in program coding The program is not coded according to the program specifications.

9• Data entry errors

Data entry staff incorrectly enters information into your computers.

10• Testing errors

Tests either falsely detect an error or fail to detect one.

11• Mistakes in error correction

Your implementation team makes errors in implementing your solutions.

12• The corrected condition causes another defect

In the process of correcting a defect, the correction process itself injects additional defects into the application system.

85
RELATED POST

STABLE PROCESS IN SOFTWARE TESTING

Defect Classification in software testing

The defects can be classified as follows:

Critical: There is s functionality block. The application is not able to proceed any further.

Major: The application is not working as desired. There are variations in the functionality.

Minor: There is no failure reported due to the defect, but certainly needs to be rectified.

Cosmetic: Defects in the User Interface or Navigation.

Suggestion: Feature which can be added for betterment.

Defect Priority

The priority level describes the time for resolution of the defect. The priority level would be classified as follows:

Immediate: Resolve the defect with immediate effect.

At the Earliest: Resolve the defect at the earliest, on priority at the second level.

Normal: Resolve the defect.

Later: Could be resolved at the later stages.

RELATED POST

DEFECT TRACKING

Related Posts

SOFTWARE QUALITY ASSURANCE AND CONTROL

SOFTWARE QUALITY AND COST ASPECT

STABLE PROCESS OF SOFTWARE TESTING

STABLE PROCESS OF SOFTWARE TESTING PART TWO


DEFECTS IN SOFTWARE TESTING

REDUCTION OF DEFECTS IN SOFTWARE TESTING

SOFTWARE TESTING AND EFFECTING FACTORS

SCOPE OF SOFTWARE TESTING

TESTING LIFE CYCLE PART ONE

TESTING LIFE CYCLE PART TWO

TESTING LIFE CYCLE PART THREE

SOFTWARE TESTING AND CONSTRAINTS WITH IN IT

TESTING CONSTRAINTS PART TWO

LIFE CYCLE TESTING

TEST METRICS

Independent Software Testing

Test Process

Testing verification and validation

Functional and structural testing

Static and dynamic testing

V model testing

Eleven steps of V model testing

Structural testing

Execution testing technique

Recovery Testing technique


Operation testing technique


Compliance software testing technique

Security testing technique