Scribd
Upload
336 views

Nature of Defects in SDLC: by Lalit.N.Patel Roll No.896 Mms-Ii (Mimr)

Defects in software development can arise from misinterpreting requirements, poor programming habits, incorrect logic, or insufficient testing. A defect is defined as a programming error that causes malfunction or fails to meet customer expectations. Defects go through a lifecycle of states like new, open, assigned, tested, verified, and closed. The nature of a defect, like critical, major, minor, determines the priority for fixing it. Proper quality practices, configuration management, and defect tracking can prevent or minimize defects.

Uploaded by

lalitpatel2118
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
336 views

Nature of Defects in SDLC: by Lalit.N.Patel Roll No.896 Mms-Ii (Mimr)

Defects in software development can arise from misinterpreting requirements, poor programming habits, incorrect logic, or insufficient testing. A defect is defined as a programming error that causes malfunction or fails to meet customer expectations. Defects go through a lifecycle of states like new, open, assigned, tested, verified, and closed. The nature of a defect, like critical, major, minor, determines the priority for fixing it. Proper quality practices, configuration management, and defect tracking can prevent or minimize defects.

Uploaded by

lalitpatel2118
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

Nature of Defects in SDLC

By
LALIT.N.PATEL
Roll No.896
MMS-II (MIMR)
Definition
“Software defect” has many interchangeable names: software bug, error, fault, failure, crash and
anomaly. The institute for electrical and electronic engineering (IEEE), the standards body regulating
even the software profession, defines a software bug as a programming error that causes software to
malfunction. IEEE sees defect as a product anomaly when software does not confirm to customer
expectation and specification. A crash is an extreme case of a software defect that stops the software
from further working.

Software is rarely free from errors or defects. Though defects in software may sometimes be disastrous,
they can be prevented or minimized through good quality assurance practices, configuration
management and defect tracking technologies. The software defect life cycle, which overlaps the
software development life cycle (SDLC), enables us to track defects and eliminate them as early as
possible in the SDLC.

Some Sources of Defects/Bugs:

Software defects can arise from:-

 Misinterpreting customer requirements


 Poor programming habits
 Wrong programming logic
 Poor testing
 Untested software implementation scenarios.

For example, a customer specifying a blue background to a website and the developer producing a white
background is a defect. Even though the website runs fine, it does not meet customer requirements.

2
Defect/Bug Life Cycle:-
In software development process, the bug has a life cycle. The bug should go through the life cycle to be
closed. A specific life cycle ensures that the process is standardized. The bug attains different states in
the life cycle. The life cycle of the bug can be shown diagrammatically as follows:

Fig. States of defect/bug life cycle.

3
The different states of defects/bugs can be summarized as follows:

1. New.

2. Open.

3. Assign.

4. Test.

5. Verified.

6. Deferred.

7. Reopened.

8. Duplicate.

9. Rejected.

10. Closed.

Description of Various Stages:

1. New: When the bug is posted for the first time, its state will be “NEW”. This means that the bug is
not yet approved.

2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he
changes the state as “OPEN”.

3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer or
developer team. The state of the bug now is changed to “ASSIGN”.

4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of
testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It
specifies that the bug has been fixed and is released to testing team.

5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases.
The reasons for changing the bug to this state have many factors. Some of them are priority of the bug
may be low, lack of time for the release or the bug may not have major effect on the software.

4
6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the
bug is changed to “REJECTED”.

7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one
bug status is changed to “DUPLICATE”.

8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the
bug is not present in the software, he approves that the bug is fixed and changes the status to
“VERIFIED”.

9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the
status to “REOPENED”. The bug traverses the life cycle once again.

10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists
in the software, he changes the status of the bug to “CLOSED”. This state means that the bug is fixed,
tested and approved.

Nature of Defect/Bug:
Indicate the impact each defect has on testing efforts or users and administrators of the application under
test. This information is used by developers and management as the basis for assigning priority of work
on defects.

Nature of Defect/Bug during the product test phase includes:

 Critical / Show Stopper --An item that prevents further testing of the product or function under
test can be classified as Critical Bug. No workaround is possible for such bugs. Examples of this
include a missing menu option or security permission required to access a function under test.
 Major / High --A defect that does not function as expected/designed or cause other functionality
to fail to meet requirements can be classified as Major Bug. The workaround can be provided for
such bugs. Examples of this include inaccurate calculations; the wrong field being updated, etc.
 Average / Medium --The defects which do not conform to standards and conventions can be
classified as Medium Bugs. Easy workarounds exists to achieve functionality objectives.
Examples include matching visual and text links which lead to different end points.
 Minor / Low -- Some defects which do not affect the functionality of the system can be
classified as Minor Bugs.

5
BIBLIOGRAPHY:-

www.ehow.com

www.wikepedia.com

www.google.com

You might also like