Defect

 

What is Defect?

Defect is any difference between expected and actual result. Defect is also known as the bug.

A reason for defects:

 1)Requirement Phase Problems:

Requirement related problem lead to developed functionality not as per user expectation. The problem can be:

Unclear or missing Requirement: The customer is either not clear about his requirement.

Frequently changing requirement: Changes become on overhead on the entire team and requirements may be either wrongly implemented or may be completely missed out.

2)Design Related Problem:

Design problem can lead to design not catering to performance expectations of a user or the technology not supporting certain requirement features.

3)Implementation-Related Problem:

Implementation issues can cause incorrect working of the program leading to defects. The problems can be incorrect implementation by developers due to human errors or due to lack of good programming skills. Also, while fixing the defects, new defects can get introduced into the same module or another module.

Defect Reporting:

Capture12

Defect reporting is keeping a record of all the defects in detail for easy and effective tracking.

Advantages of Defect Reporting:

-Used by developers while resolving defects.

-Track defect till they get closed.

-Forms basis for quality measurement

-Use this knowledge for future similar projects.

-Process improvement

-Gather statistics to predict defect in future applications.

-Take decision about readiness to hand over the application for user acceptance test

Defect Attributes:

Defect Id: A unique identification assign to each defect

Project Name: Name of project

Module Name: Name of module where defect is found

Phase: Level of testing when defect is found(Unit/Integration)

Type of defect: Functional/ Non-functional/ Enhancement

Severity: Indicates the impact of the defect

Priority: Indicates the urgency of fixing the defect.

Summary: One line statement mentioning defect description

Description: Details of the defect with steps to reproduced, screenshots, more information on what is happening and what should happen.

Status: New, Open Assign, Duplicate, Fixed, re-open, closed.

Defect Severity and Priority:

Severity and priority can be set of qualitatively using terms like high, low.

Severity:

Very high: Application is not starting, application hang, data corruption, Application terminates.

High: Function is not working according to specifications.

Medium: Incorrect error messages

Low: Spelling, Grammatical error, Enhancement request

Defect Life cycle:

Capture11

  • During the testing, the defect is identified by tester then tester that bug is logged into the bug tracker. Default status is bug “NEW”
  • NEW status bug assigns to the developer which will look into the bug and decide whether bugs valid or not. If they found the bug is invalid then they will change the status “Invalid” with proper explanation of bug. The tester will either reopen the bug and closed it based on the developer explanation.
  • If tester assign bug is valid and accepted by the developer. After fixation of the bug developer will change the status “ASSIGNED” and assign it back to the tester to verify the bug is fixed or not. Here the status of bug is change as ” RESOLVED”.
  • Bug which is fixed now change its status to either VERIFIED or REOPENED, depending on bug fixed or reproducible.
  • The bug is fixed successfully and application is behaving as expected. The status of that bug is change “VERIFIED” to “CLOSED”.
  • The bug fix did not work expected, then the tester may mark the status from “RESOLVED” to “REOPENED” after giving the necessary reason for why it is still a bug.
  • After the bug is REOPENED and status is changed to “ASSIGNED” again and development team will fix it according to the requirements and send it again to the test team to verify.
  • Again if the bug fix worked as expected then tester will set it to “VERIFIED” and “CLOSED”. And if it still has some issues then the cycle goes on till the bug is in the CLOSED state.
  • If bug reported by a tester or end user is unclear to any of project team then they may ask for more information about the bug required a team at any state of bug life cycle. The bug fix did not work expected, then the tester may mark the status from “RESOLVED” to “REOPENED” after giving the necessary reason for why it is still a bug.
  • After the bug is REOPENED and status is changed to “ASSIGNED” again and development team will fix it according to the requirements and send it again to the test team to verify.
  • Again if the bug fix worked as expected then tester will set it to “VERIFIED” and “CLOSED”. And if it still has some issues then the cycle goes on till the bug is in the CLOSED state.
  • The bug deferred status means the bug is expected to fix in the next release. The reasons for changing the bug to this state have many factors.  The priority of the deferred bug is low absence of time for the release or the bug may not major effect on the software.
  • If bug reported by a tester or end user is unclear to any of project team then they may ask for more information about the bug required a team at any state of bug life cycle.

Kanchan Patil

Kanchan is well experienced manual tester with 1.5 years of experience.

Kanchan Patil

About Kanchan Patil

Kanchan is well experienced manual tester with 1.5 years of experience.