javabyKiran Manual Testing call : 8888809416

Everything about defects.

• What is defect?

o Actual Result : What we see in product / application or website

o Expected Result : Whatever written in requirement documents. FD [functional
document], BRD [Business Requirement Document]
o A defect is difference between actual and expected result.
o A Defect in Software Testing is a variation or deviation of the software
application from end user’s requirements or original business requirements. A
software defect is an error in coding which causes incorrect or unexpected results
from a software program which does not meet actual requirements. Testers might
come across such defects while executing the test cases.
o If expected and actual results are not matching, then testers raise a defect.

• Defect Life Cycle - Important

o Defect life cycle is a cycle which a defect goes through during its lifetime. It
starts when defect is found and ends when a defect is closed, after ensuring it’s
not reproduced.
o Defect life cycle is related to the bug found during testing.
o The Life cycle of the bug can be shown diagrammatically as follows:

Javabykiran.com 1
javabyKiran Manual Testing call : 8888809416

o New: When a defect is logged and posted for the first time. Its state is given as new.
o Assigned: After the tester has posted the bug, the lead of the tester approves that the
bug is genuine, and he assigns the bug to corresponding developer and the developer
team. Its state given as assigned.
o Open: At this state the developer has started analyzing and working on the defect fix.
o Fixed: When developer makes necessary code changes and verifies the changes then
he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.
o Ready to retest : After fixing the defect the developer has given that code for
retesting to the tester. Here the testing is pending on the testers end. Hence its status
is pending retest.
o Retested / verified : At this stage the tester does the retesting of the changed code
which developer has given to him to check whether the defect got fixed or not. If the
bug is not present in the software, he approves that the bug is fixed and changes the
status to “verified”.
o Reopened : If the bug still exists even after the bug is fixed by the developer, the
tester changes the status to “reopened”. The bug goes through the life cycle once
again.
o 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.
o 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“.

Javabykiran.com 2
javabyKiran Manual Testing call : 8888809416

o 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”.
o 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.
o Data issue: The bug, changed to Data Issue state means the bug arise due to wrong
data input or wrong master data present in Database.
o Not a bug: The state given as “Not a bug” if there is no change in the functionality of
the application. For an example: If customer asks for some change in the look and
field of the application like change of color of some text then it is not a bug but just
some change in the looks of the application.

• How to track defects.

o Famous Defect Tracking Tools:

▪ Bugzilla
▪ JIRA
▪ ALM (QC)
▪ Mantis hub

o A typical Defect Tracker will have:

▪ Defect id
▪ Date
▪ Created By
▪ Assigned TO
▪ Bug description
▪ Steps to Reproduce
▪ Expected Result
▪ Comments
▪ Screen shots

Javabykiran.com 3
javabyKiran Manual Testing call : 8888809416

Below is picture from some website where we can raise defects.

While raising defects we need to check priority and severity properly. Check below details.
• Severity: It is the extent to which the defect can affect the software. In other words, it
defines the impact that a given defect has on the system.
• If an application or web page crashes when a remote link is clicked, in this case
clicking the remote link by a user is rare but the impact of application crashing is
severe. So, the severity is high, but priority is low.
• Critical: The defect that results in the termination of the complete system or one
or more component of the system and causes extensive corruption of the data.
The failed function is unusable and there is no acceptable alternative method to
achieve the required results then the severity will be stated as critical.
• Major: The defect that results in the termination of the complete system or one
or more component of the system and causes extensive corruption of the data.
The failed function is unusable but there exists an acceptable alternative method
to achieve the required results then the severity will be stated as major.
• Medium: The defect that does not result in the termination, but causes the
system to produce incorrect, incomplete, or inconsistent results then the severity
will be stated as moderate.
• Minor: The defect that does not result in the termination and does not damage
the usability of the system and the desired results can be easily obtained by
working around the defects then the severity is stated as minor.
• Cosmetic: The defect that is related to the enhancement of the system where the
changes are related to the look and field of the application then the severity is
stated as cosmetic.

Javabykiran.com 4
javabyKiran Manual Testing call : 8888809416

• Priority: Priority defines the order in which we should resolve a defect. Should we
fix it now, or can it wait?
• This priority status is set by the tester to the developer mentioning the time
frame to fix the defect. If high priority is mentioned, then the developer must fix
it at the earliest. The priority status is set based on the customer requirements.
• For example: If the company name is misspelled in the home page of the
website, then the priority is high, and severity is low to fix it.
• Low: The defect is an irritant which should be repaired, but repair can be
deferred until after more serious defect has been fixed.
• Medium: The defect should be resolved in the normal course of development
activities. It can wait until a new build or version is created.
• High: The defect must be resolved as soon as possible because the defect is
affecting the application or the product severely. The system cannot be used until
the repair has been done.
• Few very important scenarios related to the severity and priority which are asked
during the interview:
• High Priority & High Severity: An error which occurs on the basic
functionality of the application and will not allow the user to use the system.
(E.g., A site maintaining the student details, on saving record if it, doesn’t allow
to save the record then this is high priority and high severity bug.)
• High Priority & Low Severity: The spelling mistakes that happens on the cover
page or heading or title of an application.
• High Severity & Low Priority: An error which occurs on the functionality of
the application (for which there is no workaround) and will not allow the user to
see the system but on click of link which is rarely used by the end user.
• Low Priority and Low Severity: Any cosmetic or spelling issues which is
within a paragraph or in the report (Not on cover page, heading, title).

Javabykiran.com 5