Bugs, defects and issues

This article explains the terminologies like bugs, defects and issues

All these three terms means the same. It all represents a problem in software.

Background of Bug

In 1946, a huge electromechanical computer stopped functioning suddenly. Operators traced that a bug was trapped in it's relay unit causing the problem. They fixed the problem by removing the bug. Software "bug tracking" and "bug fixing" was evolved from this!

Below is the picture of the first real bug reported:

For several years, the term "bug" and "defect" were widely used in software develop process to indicate problems in software. However, software engineers started questioning the terms "bugs" and "defects" because in many cases they argue that certain "bug" is not a bug, but it is a "feature" or "it is how customer originally asked for it". To avoid conflicts between testing and development team, several companies are now using a different term - "software issue".

Even though both "issue" and "bug" indicate some kind of problems in software, developers feel the term "issue" is less offensive than "bug" ! This is because, the bug directly indicate a problem in the code he wrote, while "issue" is a term which indicates any kind of general problems in the software including wrong requirement, bad design etc.

Whatever problems the QA or testing team find, they will call it as an "issue". An issue may or may not be a bug. A tester may call a feature as a "issue" because that is not what the customer wants, even though it is a nice feature. Or, the software is not delivered to QA team on the date planned, it can be reported as an "issue".

The tester reports issues and his role ends there. It is the job of the product manager to decide whether to solve the issue and how to solve it. Depending on the nature of the issue, the product manager assigns it to the appropriate team to resolve. Product manager may even decide to "waive the issue" if he feels that it is not a problem. If the issue is a bug, then it will be assigned to the developers and they will fix the code. When the bug is fixed, the testing team will re test the software and verify it. If the issues is fixed, then the status of the issue will be changed to "closed".

An issue can be resolved in different ways, depending on it's nature. If it is a software bug, it goes to the developer to correct the code and program. If it is due to wrong requirement, it goes to the customer or marketing to correct the requirement. If the issue was caused by bad configuration in the testing computer, it will be assigned to the appropriate hardware representative to correct the configuration problem.

Software developers like the term "issue" rather than "bug" because the term "issue" does not really indicate that there is a problem in their code ! The term "issue" is becoming the standard in software testing process to indicate problems in software.

Golden rules for bug reporting

Introduction
Read these simple golden rules for bug reporting. They are based on years of practical testing experience and solid theory.
Make one change request for every bug
- This will enable you to keep count of the number of bugs in the application
- You'll be able to give a priority on every bug separately
- You'll be able to test each resolved bug apart (and prevent having requests that are only resolved half)

Give step by step description of the problem:
E.g. "- I entered the Client page
- I performed a search on 'Google'
- In the Result page 2 clients were displayed with ‘Google’ in their name
- I clicked on the second one
---> The application returned a server error"

Explain the problem in plain language:
- Developers / re-testers don't necessarily have business knowledge
- Don't use business terminology

Be concrete
- Errors usually don't appear for every case you test
- What is the difference between this case (that failed) and other cases (that didn't fail)?

Give a clear explanation on the circumstances where the bug appeared
- Give concrete information (field names, numbers, names,...)

If a result is not as expected, indicate what is expected exactly
- Not OK : 'The message given in this screen is not correct"
- OK: 'The message that appears in the Client screen when entering a wrong Client number is "enter client number"
--> This should be: "Enter a valid client number please"

Explain why (in your opinion) the request is a "show stopper"
- Don't expect other contributors to the project always know what is important
- If you now a certain bug is critical, explain why!

Last but not least: don't forget to use screen shots!
- One picture says more than 1000 words
- Use advanced toold like SnagIt (www.techsmith.com/screen-capture.asp)

When testers follow these rules, it will be a real time and money saver for your project ! Don't expect the testers to know this by themselves. Explain these rules to them and give feedback when they do bad bug reporting!

Defect

DEFINITION

A Software Bug / Defect is a condition in a software product which does not meet a software requirement (as stated in the requirement specifications) or end-user expectations (which may not be specified but are reasonable). In other words, a bug is an error in coding or logic that causes a program to malfunction or to produce incorrect/unexpected results.

A program that contains a large number of bugs is said to be buggy.
Reports detailing bugs in software are known as bug reports.
Applications for tracking bugs are known as bug tracking tools.
The process of finding the cause of bugs is known as debugging.
The process of intentionally injecting bugs in a software program, to estimate test coverage by monitoring the detection of those bugs, is known as bebugging.



Software Testing proves that bugs exist but NOT that bugs do not exist.

CLASSIFICATION

Software Bugs /Defects are normally classified as per:

Severity / Impact
Probability / Visibility
Priority / Urgency
Related Module / Component
Related Dimension of Quality
Phase Detected
Phase Injected
Severity/Impact

Severity indicates the impact of a bug on the quality of the software. This is normally set by the Software Tester himself/herself.


Critical:

There is no workaround.
Affects critical functionality or critical data.
Example: Unsuccessful installation, complete failure of a feature.
Major:

There is a workaround but is not obvious and is difficult.
Affects major functionality or major data.
Example: A feature is not functional from one module but the task is doable if 10 complicated indirect steps are followed in another module/s.
Minor:

There is an easy workaround.
Affects minor functionality or non-critical data.
Example: A feature that is not functional in one module but the task is easily doable from another module.
Trivial:

There is no need for a workaround.
Does not affect functionality or data.
Does not impact productivity or efficiency.
Example: Layout discrepancies, spelling/grammatical errors.
Severity is also denoted as S1 for Critical, S2 for Major and so on.

The examples above are only guidelines and different organizations/projects may define severity differently for the same types of bugs.


Probability / Visibility

Probability / Visibility indicates the likelihood of a user encountering the bug.

High: Encountered by all or almost all the users of the feature
Medium: Encountered by about 50% of the users of the feature
Low: Encountered by no or very few users of the feature
The measure of Probability/Visibility is with respect to the usage of a feature and not the overall software. Hence, a bug in a rarely used feature can have a high probability if the bug is easily encountered by users of the feature. Similarly, a bug in a widely used feature can have a low probability if the users rarely detect it.

Priority / Urgency

Priority indicates the importance or urgency of fixing the bug. Though this may be initially set by the Software Tester himself/herself, the priority is finalized by the Project Manager.

Urgent: Must be fixed prior to next build
High: Must be fixed prior to next release
Medium: May be fixed after the release/ in the next release
Low: May or may not be fixed at all
Priority is also denoted as P1 for Urgent and so on.

Normally the following are considered when determining the priority of bugs

Severity/Impact
Probability/Visibility
Available Resources (Developers to fix and Testers to verify the fixes)
Available Time (Time for fixing, verifying the fixes and performing regression tests after the verification of the fixes)
If a release is already scheduled and if bugs with critical/major severity and high probability are still not fixed, the release is usually postponed.

If a release is already scheduled and if bugs with minor/low severity and medium/low probability are not fixed, the release is usually made by mentioning them as Known Issues/Bugs. They are normally catered to in the next release cycle. Nevertheless, any project’s goal should be to make releases will all detected defects fixed.

Related Module /Component

Related Module / Component indicates the module or component of the software where the bug was detected. This provides information on which module / component is buggy or risky.

Module/Component A
Module/Component B
Module/Component C
…
Related Dimension of Quality

Related Dimension of Quality indicates the aspect of software quality that the bug is connected with.

Functionality
Usability
Performance
Security
Compatibility
…
Phase Detected

Phase Detected indicates the phase in the software development lifecycle where the bug was identified.

Unit Testing
Integration Testing
System Testing
Acceptance Testing
Phase Injected

Phase Injected indicates the phase in the software development lifecycle where the bug was introduced. Phase Injected is always earlier in the software development lifecycle than the Phase Detected. Phase Injected can be known only after a proper root-cause analysis of the bug.

Requirements Development
High Level Design
Detailed Design
Coding
Build/Deployment
Note that the categorizations above are just guidelines and it is up to the project/organization to decide on what kind of categorization to use. In most cases the categorization depends on the bug tracking tool that is being used. It is essential that project members agree beforehand on the categorization (and the meaning of each categorization) to be used so as to avoid arguments, conflicts, and unhealthy bickering later.

A BUG JOKE

“There is a bug in this ant’s farm.”
“What do you mean? I don’t see any ants in it.”
“Well, that’s the bug.”

A BUG STORY

Once upon a time, in a jungle, there was a little bug. He was young but very smart. He quickly learned the tactics of other bugs in the jungle: how to bring maximum destruction to the plants; how to effectively pester the animals; and most importantly, how to maneuver underground so as to avoid detection. Soon, the little bug was famous / notorious for his ‘severity’. All the bugs in the jungle hailed him as the Lord of the Jungle. Others feared him as the Scourge of the Jungle and mothers started taking his name to deter their children from going out in the night.

The Jungle Council, headed by the Lion, announced a hefty prize for anyone being able to capture the bug but no one was yet successful in capturing, or even sighting, the bug. The bug was a living legend.

For years, the bug basked in glory and he swelled with pride day by day. One day, when the Lion was away hunting, he burrowed to the top of the Lion’s hill and, standing atop the hill, he roared “I have captured the lily-livered Lion’s domain. I am now the true King of the Jungle! I am the Greatest! I am Invincible!”

His words resonated through the jungle and life stood still for a moment in sheer awe of the bug’s capabilities. Just then, it so happened that a Tester was passing by the Jungle and he promptly submitted a bug report with the exact longitude and latitude of the bug’s location. Then, a Developer hurriedly ‘fixed’ the bug (The bug was so swollen up after his boastful speech that he could not squeeze himself back into the burrow on time.) and that was the tragic end of the legendary bug.

NOTE: We prefer the term ‘Defect’ over the term ‘Bug’ because ‘Defect’ is more comprehensive.

what type of bugs are usually rejected and deferred by developer

Chance 1:
Differed means if one bug is raised in this cycle ,developer know about this bug but they don't fix it in this cycle they fix in next cycle or next version that time they kept this bug in differed stage.
if the bugs are raised by tester it is not valid like any validations .they reject the bugs


Chance 2:
Developer Rejected the bug when---
--Ths Bug is not Genuine.
--Result are not same

Developer Deferred the bug when---
--Priority Of bug may be low
--Lack of time for release
--The bug may not major effect on our application

Chance 3:
1. Tester will raised the bug with reproduction steps. Project Team will analysis whether the raised bug is valid or not. If the bug is not able to reproduced in the application . then Project team will "Reject" the bug.
2. If the bug is not so important for the present release, then Project Team will " Deferred" the Bug.

How to write better bug reports

How often do we see the developers requiring more information on the bug reports filed by us?
How often do we need to spend more time investigating on the issue after the bug report has been filed? How often do we get to hear from the developers that the bug is not reproducible on their end and we need to improvise on the Steps To Reproduce? In a broad sense, we end up spending more time on these issues rather than investing more time testing the system. The problem lies in the quality of bug reports. Here are some areas which can be improved upon to achieve that perfect bug report.

The Purpose Of A Bug Report
When we uncover a defect, we need to inform the developers about it. Bug report is a medium of such communication. The primary aim of a bug report is to let the developers see the failure with their own eyes. If you can't be with them to make it fail in front of them, give them detailed instructions so that they can make it fail for themselves. The bug report is a document that explains the gap between the expected result and the actual result and detailing on how to reproduce the scenario.

After Finding The Defect
Draft the bug report just when you are sure that you have found a bug, not after the end of test or end of day. It might be possible that you might miss out on some point. Worse, you might miss the bug itself.
Invest some time to diagnose the defect you are reporting. Think of the possible causes. You might land up uncovering some more defects. Mention your discoveries in your bug report. The programmers will only be happy seeing that you have made their job easier.
Take some time off before reading your bug report. You might feel like re-writing it.

The Summary
The summary of the bug report is the reader’s first interaction with your bug report. The fate of your bug heavily depends on the attraction grabbed by the summary of your bug report. The rule is that every bug should have a one-liner summary. It might sound like writing a good attention-grabbing advertisement campaign. But then, there are no exceptions. A good summary will not be more than 50-60 characters. Also, a good summary should not carry any subjective representations of the defect.

The Language
Do not exaggerate the defect through the bug report. Similarly, do not undertone it.
However nasty the bug might be, do not forget that it’s the bug that’s nasty, not the programmer. Never offend the efforts of the programmer. Use euphemisms. “Dirty UI” can be made milder as “Improper UI”. This will take care that the programmer’s efforts are respected.
Keep It Simple & Straight. You are not writing an essay or an article, so use simple language.
Keep your target audience in mind while writing the bug report. They might be the developers, fellow testers, managers, or in some cases, even the customers. The bug reports should be understandable by all of them.

Steps To Reproduce
The flow of the Steps To Reproduce should be logical.
Clearly list down the pre-requisites.
Write generic steps. For example, if a step requires the user to create file and name it, do not ask the user to name it like “Mihir’s file”. It can be better named as “Test File”.
The Steps To Reproduce should be detailed. For example, if you want the user to save a document from Microsoft Word, you can ask the user to go to File Menu and click on the Save menu entry. You can also just say “save the document”. But remember, not everyone will not know how to save a document from Microsoft Word. So it is better to stick to the first method.
Test your Steps To Reproduce on a fresh system. You might find some steps that are missing, or are extraneous.

Test Data
Strive to write generic bug reports. The developers might not have access to your test data. If the bug is specific to a certain test data, attach it with your bug report.

Screen Prints
Screen prints are a quite essential part of the bug report. A picture makes up for a thousand words. But do not make it a habit to unnecessarily attach screen shots with every bug report. Ideally, your bug reports should be effective enough to enable the developers to reproduce the problem. Screen shots should be a medium just for verification.
If you attach screen shots to your bug reports, ensure that they are not too heavy in terms of size. Use a format like jpg or gif, but definitely not bmp.
Use annotations on screen shots to pin-point at the problems. This will help the developers to locate the problem at a single glance.

Severity / Priority
The impact of the defect should be thoroughly analyzed before setting the severity of the bug report. If you think that your bug should be fixed with a high priority, justify it in the bug report. This justification should go in the Description section of the bug report.
If the bug is the result of regression from the previous builds/versions, raise the alarm. The severity of such a bug may be low but the priority should be typically high.

Logs
Make it a point to attach logs or excerpts from the logs. This will help the developers to analyze and debug the system easily. Most of the time, if logs are not attached and the issue is not reproducible on the developer’s end, they will revert to you asking for logs.

If the logs are not too large, say about 20-25 lines, you can paste it in bug report. But if it is large enough, add it to your bug report as an attachment, else your bug report will look like a log.

Other Information
If your bug is randomly reproducible, just mention it in your bug report. But don’t forget to file it. You can always add the exact steps to reproduce anytime later you (or anyone else) discover them. This will also come to your rescue when someone else reports this issue, especially if it’s a serious one.
Mention the error messages in the bug report, especially if they are numbered. For example, error messages from the database.
Mention the version numbers and build numbers in the bug reports.
Mention the platforms on which the issue is reproducible. Precisely mention the platforms on which the issue is not reproducible. Also understand that there is difference between the issue being not reproducible on a particular platform and it not being tested on that platform. This might lead to confusion.
If you come across several problems having the same cause, write a single bug report. The fix of the problem will be only one. Similarly, if you come across similar problems at different locations requiring the same kind of fix but at different places, write separate bug reports for each of the problems. One bug report for only one fix.
If the test environment on which the bug is reproducible is accessible to the developers, mention the details of accessing this setup. This will help them save time to setting up the environment to reproduce your bug.
Under no circumstances should you hold on to any information regarding the bug. Unnecessary iterations of the bug report between the developer and the tester before being fixed is just waste of time due to ineffective bug reporting.