Bug Reporting – Art and Advocacy

[B][SIZE="3"][COLOR="Blue"][URL="http://www.exforsys.com/tutorials/testing/bug-reporting-art-and-advocacy.html"]Bug Reporting – Art and Advocacy[/URL][/COLOR][/SIZE][/B]

This article highlights the essence and traits of finding bugs. It leaps to redefine the art, a tester should inculcate while finding a bug. It enumerates various artifacts in reporting a bug. Whereas, also voices the advocacy on the bugs that has been reported. The basic amenity of a tester being to fight for the bug until it is fixed.

[URL="http://www.exforsys.com/tutorials/testing/bug-reporting-art-and-advocacy.html"]Read More...[/URL]

Hi Priyanka,

This is a very good article regarding the Bug. Tracing out of bugs from the Appliction plays a vital role for the quality of the application. Hence it is necesary to track the Bug so that all the other who are all the part of the team and the client can able to see where the problem occurs and how to rectify it.

One more point to add the article, regarding the Bug Tracking tools. It is very hard to track all the bugs for an application which is complex and big in a excel sheet. There the Bug tracking tools plays a important role. Now all of the Test Management tools provides bug tracking as one of their component. For example, Quality Center or Test Director are some of the tools which also provide bug tracking facility.

Once a bug is identified it is locked in the Defect tracking system and unique number is assigned to it. Each Defect will have the Defect ID, Subject, Description, Person locked the defect, Assigned to, Severity, Priority, Status such as open or new or closed, Module, Area where the defect occurred, Type of defect, etc.,

With the use of the Defect tracking tools it is efficient to deal with the Bugs.

Regards,
Ganesan

If we consider the bugs, we should consider those bugs also, which our users reports to us, but they don't report any steps to reproduce.
Sometimes it becomes so challenges to write steps for this type of bugs. You know the bug, but not the step. And if you want that the bug should fixed, you have to write steps to reproduce it.

@ jain,
In tht situation how to reproduce tht bug without steps,,can u explain???

In my view, I had faced such situations during that we will collect the save logs during the period the bugs got reported and even we can retrieve the error logs from the back end DB using the Bug reported times we got from user.
with that information we immediately log a defect in the defect Tracking system and try to reproduce the similar bug by the Testing resources.If it got Reproduced we will confirm the same by comparing the log files, it will be assigned to the developer by providing all the information like steps to reproduce,log files,screen shots.

If the same was not able to reproduce then we can make the state of the bug logged as differed and sporadic(which is not reproducible) and see for next two builds.(observe the same if it can be reproduced during the next 2 test cycles)..if still not it will get terminated stating the reason not reproducible for the builds...

and in future if it gets observed again the same bug can be reopened and can be fixed.

--------------------
Regards,
Humpbackwhale

[QUOTE=RanjeetaRajendran;35824]@ jain,
In tht situation how to reproduce tht bug without steps,,can u explain???[/QUOTE]

It is testing team responsibility to reproduce the bug. Tester needs to execute different test cases for the scenario user is facing the bug. It is always a challenge for the testing team to reproduce bugs.

Hi Friends,

[COLOR="Navy"]What do I do if I find a bug/error?
In normal terms, if a bug or error is detected in a system, it needs to be communicated to the developer in order to get it fixed.

Right from the first time any bug is detected till the point when the bug is fixed and closed, it is assigned various statuses which are New, Open, Postpone, Pending Retest, Retest, Pending Reject, Reject, Deferred, and Closed.

(Please note that there are various ways to communicate the bug to the developer and track the bug status)

Statuses associated with a bug:
New:
When a bug is found/revealed for the first time, the software tester communicates it to his/her team leader (Test Leader) in order to confirm if that is a valid bug. After getting confirmation from the Test Lead, the software tester logs the bug and the status of ‘New’ is assigned to the bug.

Assigned:
After the bug is reported as ‘New’, it comes to the Development Team. The development team verifies if the bug is valid. If the bug is valid, development leader assigns it to a developer to fix it and a status of ‘Assigned’ is assigned to it.

Open:
Once the developer starts working on the bug, he/she changes the status of the bug to ‘Open’ to indicate thgooat he/she is working on it to find a solution.

Fixed:
Once the developer makes necessary changes in the code and verifies the code, he/she marks the bug as ‘Fixed’ and passes it over to the Development Lead in order to pass it to the Testing team.

Pending Retest:
After the bug is fixed, it is passed back to the testing team to get retested and the status of ‘Pending Retest’ is assigned to it.

Retest:
The testing team leader changes the status of the bug, which is previously marked with ‘Pending Retest’ to ‘Retest’ and assigns it to a tester for retesting.

Closed:
After the bug is assigned a status of ‘Retest’, it is again tested. If the problem is solved, the tester closes it and marks it with ‘Closed’ status.

Reopen:
If after retesting the software for the bug opened, if the system behaves in the same way or same bug arises once again, then the tester reopens the bug and again sends it back to the developer marking its status as ‘Reopen’.

Pending Reject:
If the developers think that a particular behavior of the system, which the tester reports as a bug has to be same and the bug is invalid, in that case, the bug is rejected and marked as ‘Pending Reject’.

Rejected:
If the Testing Leader finds that the system is working according to the specifications or the bug is invalid as per the explanation from the development, he/she rejects the bug and marks its status as ‘Rejected’.

Postponed:
Sometimes, testing of a particular bug has to be postponed for an indefinite period. This situation may occur because of many reasons, such as unavailability of Test data, unavailability of particular functionality etc. That time, the bug is marked with ‘Postponed’ status.

Deferred:
In some cases a particular bug stands no importance and is needed to be/can be avoided, that time it is marked with ‘Deferred’ status.
[/COLOR]

[COLOR="Red"]
1. New
2. Open
3. Assign
4. Test
5. Verified
6. Deferred
7. Reopened
8. Duplicate
9. Rejected and
10. Closed

[/COLOR]

[COLOR="DarkRed"]
Guidelines on deciding the Severity of 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.
A sample guideline for assignment of Priority Levels during the product test phase includes:
1. 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.
.
2. 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.
.
3. 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.
.
4. Minor / Low — Cosmetic defects which does not affect the functionality of the system can be classified as Minor Bugs.

[/COLOR]

Regards
Seshadri Sethi

Seshadri Sethi

Wonder full view on the Bug life cycle

Hi Seshadri Sethi ,

It looks very nice. worth to know about this .
Its good for learners.

Regards,
Vasu

hi Seshadri Sethi,

Marve less explanation boss.
this article is very useful for learners.

What do I do if I find a bug/error?
In normal terms, if a bug or error is detected in a system, it needs to be communicated to the developer in order to get it fixed.
It looks very nice. worth to know about this .
Its good for learners.



[URL="http://oceangroups.org/"]
[/URL]

It is important that the BUG REPORT be prepared by the testers with utmost proficiency and specificity. It should basically describe the famous 3. check this link to know more - [B]bit.ly/1pH7t8O[/B]