You are on page 1of 10

BUG

BUG- Bug is an error in software program or system that produces an incorrect or


unexpected result, or causes it to behave in unintended ways.
From a developer perspective, bugs can be
syntax or logic errors within the source code of a program.

Life cycle of Bug The Bug Cycle starts from the finding defects and the cycle goes
on to the next as fixing the bugs detected and then the retesting the same and if it
works then it is closed else reopened. The life cycle of the bug can be shown
diagrammatically as follows:

Bug Life Cycle

Various stages of BUG

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

• 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”.

• 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”.

• 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.
• 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.

• 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”.

• 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”.

• 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”.

• 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.

• 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.

Questions: - What is new and open bug?

Attributes of a Bug:
Title:
Component(where it was found)
Severity
Priority
Status
Assigned to (developer name)
Found by (tester name)
Date (found)
Resolution
OS(environment found on)
Pre-conditions
Description
Expected Results
Actual Results
Additional Information
Attached snapshots/test logs
We can have more attributes than wrt the reporting software we use.

How do you estimate the Bug?

The estimation of bugs are done by the priority and the severity. But the exp persons may give to
which bug have more priority and n more severity

Priority and Severity

Severity: seriousness of the defect with respect to functionality

Priority: Importance of the defect with respect to customer

“Priority” is associated with scheduling, and “severity” is associated with standards.

LOW- MEDIUM-HIGH- CRITICAL

Low Severity High Priority Bug:-

• Home Page in web application has misspelled client name and found at the time of delivering
the product.
• If there is a spelling mistake or content issue on the homepage of a website which has daily
hits of lakhs. In this case, though this fault is not affecting the website or other functionalities
but considering the status and popularity of the website in the competitive market it is a high
priority fault.

High Severity Low priority Bug:-

• Crash in some any module that is too be delivered later.


• For example an application which generates some banking related reports weekly, monthly,
quarterly & yearly by doing some calculations. If there is a fault while calculating yearly
report. This is a high severity fault but low priority because this fault can be fixed in the next
release as a change request.

Low Severity Low priority Bug:-

• Color of the page, size, font these are comes under low severity and low priority. Because it
doesn’t affect the functionality of the application.
• Suppose there is a spelling mistake on the pages which has very less hits throughout the
month on any website. This fault can be considered as low severity and low priority.

High Severity High priority Bug:-

• Application won't start


• Not able to access related pages properly and instead of that page if open code related stuff
• In the above banking example if there is a fault while calculating weekly report. This is a high
severity and high priority fault because this fault will block the functionality of the application
immediately within a week. It should be fixed urgently.
FAQ

1. What are the different types of Bugs we normally see in any of the
Project? Include the severity as well.

• User Interface Defects -------------------------------- Low

• Boundary Related Defects ------------------------------- Medium

• Error Handling Defects --------------------------------- Medium

• Calculation Defects ------------------------------------ High

• Improper Service Levels (Control flow defects) --------- High

• Interpreting Data Defects ------------------------------ High

• Race Conditions (Compatibility and Intersystem defects)- High

• Load Conditions (Memory Leakages under load) ----------- High

• Hardware Failures:-------------------------------------- High

2. How do we track a bug? What is the format of excel sheet in which we


write the bug details?

Tracking a bug is much easier and communicative when done through a tool.

Format of the tool:

BUG ID TEST CASE ID DESCRIPTION SEVEORITY PRIORITY ASSIGNED TO STATUS REMARKS

(Bug id is usually generated by the tool)

Outside the excel sheet we might need to fill the fields like:

Tester name (usually generated with the login name)

Date of execution etc.

a <submit> and < cancel> button

3. How to post a BUG


The posting of Bug is done by tools in now-a-days. In manual testing the Bug is
posting using Company own tools whether the tool is bought or created by the
company. In automation it is done using Rational or Test director.

4. What is the difference between a Bug and a Defect?

Bug: An Error found in the development environment before the product is shipped
to the customer.

Defect: An Error found in the product itself after it is shipped to the customer.

5. What is AUT???

AUT is Application under test .After designing and coding phase of development
cycle when the application (build) comes under testing then at that time application
state is under test so at that time period that application (build) is called Application
Under test

6. What is build interval period?

The Gap between the Present build and next build...

7. What does u mean by "Reproducing a bug"? If the bug was not reproducible, what is the next step?

This means performing the similar steps that were performed when the bug was detected. Or it can be
steps to re-produce the bug. Developer may ask you to re-produce the bug the unable to follow the
steps u mentioned in the defect description. If the bug is not reproducible (by tester/developer) then
the defect is rejected by the dev team with status Rejected-not reproducible

8. What are latent bugs?

The bug which is not identified in present version and can be able to identified in later versions.

9. WHAT IS A GOLDEN BUG

Golden Bug: A bug which occurred in all instances of application of high severity and high priority.

Ex: If an app having 3 pages in each and every page doesn’t have submitted buttons then this can be
considered as GOLDEN BUG.
Golden Bug: A bug which occurred in all instances of application of high severity and high priority.

Ex: If an app having 3 pages in each and every page doesn’t have submit buttons then this can be
considered as GOLDEN BUG.

10. What do you do when the developer disagrees with a failed test result?

I will follow below approach:

1. I send all the procedure to reproduce the defect.


2. I attach the screen shots as a proof.
3. If then also developer not accepting the bug then I will ask my QA manager to permit formal
discussion with developer and I hope that discussion should be very friendly and output should be one
conclusion.
4. If not Then I will ask to my manager to arrange discussion in the presence of client and based on
client's view and discussions it will get finalized.

11. Suppose a bug was found by the customer, As a Testing what is your comments on this issue?

If I would have faced such an issue as a tester first I would try to reproduce the bug
with same & different configurations.
In case bug is reproducible for any environment that has been tested definitely we
owe an apology.
In case it’s not reproducible an explanation about the same will go along...

12. What are the most common bugs that we find on a daily basis in web based testing.

I've faced below problems.

Network Problems:

- Page not loading properly


- Accessing the application
- Page breaking
- Data base connections
GUI :
- Java script errors

And I don’t think functional bugs are comes under common bugs let me know if I'm
wrong
13 .Duplicate Bugs

Same bug is reported twice thrice or more by same Tester or different Tester in the Bug Tracking tools
which represent the same test steps or different test steps but the bug cause is same is called
Duplicate Bugs.

14. What is meant by functional defects and usability defects in general? Give example.

Consider Login window as an example

Functionality Defect:

assume that you have given valid user name, invalid password and clicked on Login
Button, in return if application has accepted you user name and password, and Main
window is displayed then this is a functionality defect.

Usability Defects:

assume that you have given valid user name, invalid password and clicked on Login
Button, in return if application has generated a validation message stating "Please
enter valid user name" instead of "Please enter valid Password" Then this is a
Usability Defect.

14. Missing important bug

If I miss an important bug and I realize it very late then what will I do?

Missing is common nature. It’s also realistic in the Software Testing. Let’s come to
the Missing Important bug. If the bug missed in Final Release communicate the
bug to the right people (TL Developer Manager) and ask them to fix it! And deliver if
the bug missed in any Consecutive Built let it fix them in the next release and note
down the bug status as "Deferred"
If the missed bug doesn’t cause any impact to the application note it down and let
them to fix in next release. If it’s delivered means let it be fixing in maintenance
stage.

15. What are tolerance bugs?

The Bug which has the status as "deferred" is called Tolerance Bug. This is not
affect in the application any where.

16. P1 BUG or showstopper bugs


P1 bug is the priority 1 bug that means without solving or fixing this bug the application can not
continued. We rate the bugs based on the priority and severity. p1 p2 p3 p4.
P1 bugs also called as showstopper bugs

BUG REPORT SAMPLE

Sample bug report 1: Application product Bug report sample

Application testing scenario:


Lets assume in your application you want to create a new user with his/her
information, for that you need to logon into the application and navigate to USERS
menu > New User, then enter all the details in the User form like, First Name, Last
Name, Age, Address, Phone etc. Once you enter all these need to click on SAVE
button in order to save the user and you can see a success message saying, “New
User has been created successfully”.

Now you entered into your application by logging in and navigate to USERS menu >
New user, entered all the information and clicked on SAVE button and now the
application crashed and you can see one error page on the screen, now you would
like to report this BUG.

Now here is how we can report bug for above scenario:

Bug Name: Application crash on clicking the SAVE button while creating a
new user.
Bug ID: The BUG Tracking tool will automatically create it once you save
this.
Area Path: USERS menu > New Users
Build Number:/Version Number 5.0.1
Severity: HIGH (High/Medium/Low)
Priority: HIGH (High/Medium/Low)

Assigned to: Developer-X


Created By: Your Name
Created On: Date
Reason: Defect
Status: New/Open/Active - Depends on the Tool you are using
Environment: Windows 2003/SQL Server 2005

Description:
Application crash on clicking the SAVE button while creating a new user,
hence unable to create a new user in the application.

Steps To Reproduce:
1) Logon into the application
2) Navigate to the Users Menu > New User
3) Filled all the fields
4) Clicked on ‘Save’ button
5) Seen an error page “ORA1090 Exception: Insert values Error…”
6) See the attached logs for more information
7) And also see the attached screenshot of the error page.

Expected: On clicking SAVE button should be prompted to a success


message “New User has been created successfully”.

Save the defect/bug in the BUG TRACKING TOOL.

Bug report sample 2: Web Project bug report

Summary: In CTR (Click through ratio) ‘Total’ row calculation is wrong

Product: Example product


Version: 1.0
Platform: PC

URL: (Provide url of page where bug occurs)


OS/Version: Windows 2000

Status: NEW
Severity: Major
Priority: P1
Component: Publisher stats

Assigned To: developer@example.com


Reported By: tester@example.com
CC: manager@example.com

Bug Description:

Reproduce steps:
1) Go to page: (Provide URL of page where bug occurs)
2) Click on ‘Publisher stats’ link to view publisher’s revenue detail stats date wise.
3) On page (Provide URL of page where bug occurs) check CTR value in ‘Total’ row of CTR
stats table.

Actual result: Calculation of ‘Total’ row in CTR table is wrong. Also Individual row CTR for
each publisher is not truncated to 2 digits after decimal point. It’s showing CTR like
0.042556767.

Expected result: Total CTR= (Total clicks/Total searches)*100

[Attach bug screenshot if any]

Please fix the bug.

You might also like