ASSIGMENT – II

BUG TRACKING PROCESS

1. What is a BUG?

A bug is an error either in the document or in the product functionality or

connections in between the modules, which is not meeting the expected
results while executing the test cases.

OR

If an error is found during the testing process, it is said to be a bug. If

client found any error after delivering the product, it is said to be a defect.

2. What should a test engineer do when a bug is identified?

When a test engineer finds a bug (i.e.) the expected result is not meeting
the test cases while executing. The following steps should be followed.

STEPS:

1. Tester will log the bug in the bug-tracking tool with its details.
2. Tester will mark the status of the bug as New.
3. He will send the new bug to the authorized personnel either TL or PM.

3. What is the problem when a bug is intimated directly to the developer

without logging in to the bug-tracking tool?

LIST OF PROBLEMS:

1. Tester cannot able to track the status of the bug (i-e) maintainability
become difficult or repeatability may occur.
2. Tester would not have any proof of sending the bug or reporting the
bug.
3. Basically, it is a must to review the bug before sending to the
developer by PM or TL.
4. Tester cannot send the work directly to the developer because the
developer might be in different team or location.
5. Anyone of the testing team may send the same bug, which has been
identified by other person of the testing team.
6. Testing team may not aware of that bug being processed.
4. What is the FIELDS present in the bug-tracking tool?

Date and time:

Date and time of bug identification and sending.
Bug-id:
Unique identification number has to be assigned to the each bug.
Test case-id:
Unique identification number of the test case.
Build-id:
Unique identification number module that being tested.
Detected by:
Here we enter the name of the person who has identified
that bug. Normally we give test engineers name who identified the
bug.
Assigned to:
Here we enter the name of the person who has assigned to
fix that particular bug. Normally we give developers name who is
fixing that bug.
Status:
Here we can see the current status of the bug.
Severity:
Here we select the levels of the severity caused by the bug.
1. Low
2. Medium
3. High
4. Critical (showstopper)
Priority:
Here we select the levels this is the importance has to be given to
the bug.
1. Cosmetic bugs
2. Low
3. Medium
4. High
5. Very high

Synopsis:
Summary of the bug.

Bug-description:
Here we give the detail of the bug.
Steps to reproduce:
Here we give the steps to reproduce that particular bug.

Bug Description:
Explanation of the bug.
Test data:
 Data’s which has to be given as inputs to execute the test case.
Expected result:
These are the results, which we are expecting to come as per the
test case execution.
Actual result:
These are the results, which we are getting as output after
executing the test case.
Fail / Pass:
This fields are entered according to the results what we get after
executing the test case. Generally if the actual result is equal to the
expected result we enter it as pass if not equal we enter it as fail.

5. Difference Between Description and Summary?

DESCRIPTION:

The full detail of a process, (i-e) it will tell about the top to
bottom of that process.

For ex: If we execute a test case, this summary will tell us all the details
about the test cases; what is the expected result, what is the actual result is
that test case is an fail or pass, does it generates any warnings. It will give
the detailed information about that test case.

SUMMARY:

This will give details of a particular bug. It will describe the

context what does it mean.

6. Difference Between Severity and Priority?

SEVERITY
Impact of the bugs on the
functionality.
When the bug occurs, it stops our
proceeding to the next environment
PRIORITY
Order of importance given to the
bug.
This is the importance given to the
bug. Normally, a bug’s priority
depends on the deliverable time
given by the customers.

Note:
Severity and Priority are both independent.

7. Example cases:
1. Low severity, low priority:
Some spelling mistakes.
 Dead line of the release is very far.
Bug in the uncovered area of the current release.

2. Low severity, High priority:

If dead line of the release is very near and still we have some
spelling mistakes and change in the color backgrounds (cosmetic
bug).

3. High severity, low Priority:

Bug in the uncovered area of the current release.

4. High severity, high Priority:

If OK button does not work during testing process.

8. BUG LIFE CYCLE:

Test engineer New-LOG

Managers, team leads

Differed Rejected Assigned

Managers
Developer
Managers

Fixed
Answer only
Network persons Developer
Post pond to latter version

Released

Test engineer

Re-test
. Test engineer

Closed
9. Explain the meaning of status of the bug and who converts from one status to
another status?

EXPLANATION:

Log:
When ever a bug is identified that will be entered in this part.

Test Engineers will enter this.

Rejected:
When a test engineer misunderstood the test case and wrongly entered a
log it as a bug.

Managers, team leads will decide this.

Differed:
When a test engineer log it as a bug. But the priority of the bug is very low
or some times that kind of functionalities not needed to be completed with
in current release managers will decide to keep it in on the hold. If we
have more time we can fix it.

Managers, team leads will decide this.

Post pond to latter version:
After coming in to the differed status we decide that we are going to fix
that bug in the next release or latter versions.

Managers, team leads will decide this.

Managers and network and system admin people involved in this.

Assigned:
Developer will be scheduled to fix a bug. The manager or team lead will
assign developer this work.

Managers, team leads will assign this work and developer will be
committed.
Fixed:
Developer will do some coding for clearing the bug. After he finished that
bug status comes as fixed.
Developers will do it.

Released:
Developer will do some coding for clearing the bug. After finishing the coding he
will create a new build for this.

Developers will do it.

 Re-open:
After a new build is enrolled again test engineers will reopen and retest that built.
If it satisfies the test case he will close that bug, or he will again log it as a bug.

Test Engineers will enter this.

Closed:
After reopened and tested when test engineer certifies the bugs are rectified. It
comes in to close stage.

10. What are the problems will occur in a project when not using any bug tracker?

Tracking the status of the bug (i-e) maintainability become difficult.

Cant able to track what work is assigned to whom.
Cant able to have any proof of our testing process to show to the customers.