The life cycle of a bug

Recently I wrote a paper for the company I am currently working for. It was titled "LifeCycle of a bug". Its intent was to educate the testers and developers in the company to write better bug reports. For you see, I would receive bugs with statements like "Found a bug in hte Employee data enter", or "System crash and I could not add anymore". And these would come from the
developers. While, as I said, I wrote the following paper, and felt like sharing it with you all.

---

LifeCycle of a Bug

Writing and submitting software bugs.

Overview

The purpose of this document is to provide a consistent and workable method to submit a bug, track its progress, and resolve it with the most minimal problems.

If you feel to elaborate on this document to better refine it, please feel free to do so. But please, initial you contributions.

What is a Bug?

First, let clarify what a bug is.

A bug is any abnormality in the software (or hardware) that either prevents a process from completing successfully, or behaves out side of scope of the specification or users experience (job wise), or appears incorrect (spelling errors).

It is my experience that it is not the testers place to determine if the abnormality is an actual bug or not. This is why a Triage team is created and assembled to evaluate submitted bugs to determine not only if they are if fact a bug, but how and who will handle them. I like to think of the tester as the Software Cop, and the Triage team as the Judges. The Cop writes the ticket, and Judge determines if a crime was actually committed.

How to write a complete and clear bug report

When an Issue (bug or enhancement) is submitted, the following point must be included: What (description), where (placement in the application), when (version and build number), and how (steps to reproduce), why (expected result) and finally, how was it resolved. Too often I have been assigned an issue and only the most vagueness of these points is met. If I can not reproduce the issue, I can not know if it fixed. These kinds of issues are general sent back the source for better clarification. But let us take a moment and clarify these points to better understand them.

What is the issue (Description)

This is not only the caption or summary of the issue, but also a long explanation of the issue found and placed in the Description body of the issue. It should provide enough information to give the triage team and developer a general understanding of the issue and its severity.

Where in the software was the issue found.

Like the description, this provides help to determine how the issue will be handled. It helps classify the issue into categories; like the module, form, or even the level in the application structure.

What version/build was the issue found, and fixed. (When)

It is important that not only what version was the issue discovered in, but also what build. Sometimes a bug will creep in starting at a single build. Once again, it can not be reproduced; the developer may just pass it back as irreproducible. But in fact they were looking in the wrong build. If the application contains multiple platforms, all with their own version and build numbers, when in doubt included them all. This is true with our system where there is an EAF version, and Inform version, Metadata version, and even a client side version. Try to keep track of which version the application is using.

For the developer, place the version and build number the fixed code will appear in to the issue when resolving it. This aids the tester in being sure that they are testing the correct version and build.

Steps to reproduce the issue (How)

The steps to reproduce the issue are perhaps the single most import part of submitting a bug. If the developer can not reproduce the bug on call, he/she can not find and fix the bug, nor can they unit test to validate the bug to be fixed. The same is true for the tester that gets the issue assigned to them to validate the bug is in fact fixed.

The Steps to Reproduce section should be very detailed steps. The steps should take the user (developer) from a known position to the actual point the problem occurs or can be observed. The steps are layed out in a numerical outline, for example.

1. Open Inform Standard. Notice the application name.

2. Login as yourself with password. Notice that login level is mentioned.

3. Observe that the current logged in user is you. This will help the developer understand the severity later in the steps.

4. From Welcome page, logout. Notice the page name is mentioned.

5. At the “Log Out Confirmation” page, click “Log In” button. The step may appear ambiguous, but mention it anyway.

6. In the Login ID field, type in the Administrator login. Observe the change login level is mentioned. This is to help emphasize the severity of the issue.

7. Press Enter (do not click the submit button). Notice that this emphasizes the action of the user not to use the mouse.

8. Observe that the current user is now the Administrator. This procedure allows any user to login as administrator level without a password. When stating the resulting problem, emphasize the severity of the problem.

Always validate the steps before committing the issue. If you can not reproduce the problem, how do you expect anyone else to be able to?

Expected result (Why)

It is always best to place an Expected Result section into the body of the Description portion of the issue. Sometimes the users (tester) expectation is not within the scope of the application, or has not been considered, and therefore the issue is more of an enhancement then a bug. The expectation should clear enough to relate the expected outcome.

How was it fixed? (Risk)

When the developer fixes the bug, they should always place a comment as to how it was fixed and where. This should not necessarily be technically detailed, but a enough to help the tester be able to verify the problem is resolved, and that know other risk area are effected.

Other points to have in the issue

Of coarse there many other points that is relative to classify an issue. Here are a few of them:

Project: Name of the Project

Customer: Customer that reported the problem

Status: Open or Closed

Priority: Low, medium, high, or blocker

Severity: Low, medium, high, or crash

Estimated Time to fix:

Related Issues: Any other similar issues

Attachments: Screen shots or code snippets.

Date Opened:

Date Resolved:

Date Closed:

Conclusion

Quality Assurance, Testing, and problem resolving is the last line of defense between success and a client dropping a buggy product. Personally, I would rather have a tester discover the problem then the customer. Testers get paid to find bugs, customer pay to find bugs. Who would be helper to find a bug?

---

I hope this helps others to report better bugs to the develepment and QA teams.