what is a defect or bug

8/3/2019 What is a Defect or Bug

http://slidepdf.com/reader/full/what-is-a-defect-or-bug 1/14

What is a Defect or Bug:

While testing when a tester executes the test cases he might observe that the actual test results do

not match from the expected results. The variation in the expected and actual results is known asdefects. Different organizations have different names to describe this variation, commonly defects arealso known as bug, problem, incidents or issues. Every incident that occurs during testing may not be a defect or bug. Am incident is any situation inwhich the software system has a questionable behavior, however we call the incident a defect or bugonly if the Root Cause is the problem in the tested component. Incidents can also occur by some other factors as well like testers mistake in test setup, environmenterror, invalid expected results etc. We log these incidents just to keep track of the record of what is observed during the testing so thatwe can find out the solution to correct it.

Defect life Cycle:

Defect /Bug Life Cycle & Guidelines

In this tutorial you will learn about Bug Life Cycle & Guidelines, Introduction, Bug Life Cycle,

The different states of a bug, Description of Various Stages, Guidelines on deciding the Severityof Bug, A sample guideline for assignment of Priority Levels during the product test phase and

Guidelines on writing Bug Description.

Introduction:

Bug can be defined as the abnormal behavior of the software. No software exists without a bug.

The elimination of bugs from the software depends upon the efficiency of testing done on the

software. A bug is a specific concern about the quality of the Application under Test (AUT).

Bug Life Cycle:

In software development process, the bug has a life cycle. The bug should go through the life

cycle to be closed. A specific life cycle ensures that the process is standardized. The bug attains

different states in the life cycle. The life cycle of the bug can be shown diagrammatically as

follows:



The different states of a bug can be summarized as follows:

1. New2. Open

3. Assign

4. Test5. Verified

6. Deferred

7. Reopened

8. Duplicate9. Rejected and

10. Closed

Description of Various Stages:

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

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

3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to correspondingdeveloper or developer team. The state of the bug now is changed to “ASSIGN”.

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



5. 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 arepriority of the bug may be low, lack of time for the release or the bug may not have major effect

on the software.

6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the stateof the bug is changed to “REJECTED”.

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

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

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

10. 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 meansthat the bug is fixed, tested and approved.

While defect prevention is much more effective and efficient in reducing the number of defects,

most organization conducts defect discovery and removal. Discovering and removing defects is

an expensive and inefficient process. It is much more efficient for an organization to conduct

activities that prevent defects.

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

Guidelines on writing Bug Description:

Bug can be expressed as “Result followed by the action”. That means, the unexpected behavior

occurring when a particular action takes place can be given as bug description.

1. Be specific. State the expected behavior which did not occur - such as after pop-up did not

appear and the behavior which occurred instead.

2. Use present tense.

3. Don’t use unnecessary words.

4. Don’t add exclamation points. End sentences with a period.

5. DON’T USE ALL CAPS. Format words in upper and lower case (mixed case).

6. Mention steps to reproduce the bug compulsorily.

Defect Management Software defects are expensive.

Moreover, the cost of finding and correcting defects represents one of the

most expensive software

development activities. For the

foreseeable future, it will not be

possible to eliminate defects. While

defects may be inevitable, we can

minimize their number and impact

on our projects. To do this

development teams need to

implement a defect management

process that focuses on preventing defects, catching defects as early in the

process as possible, and minimizing the impact of defects. A little investment

in this process can yield significant returns.

Mosaic, Inc. served as the project manager for a Quality Assurance Institute(QAI) research project on defect management. The purpose of the researchproject was to develop guidance for software managers in the area of defect



management. The results of the project were published in the QAI researchreport number 8, Establishing A Software Defect Management Process. Whileworking on the project, Mosaic, Inc. developed a framework for the defectmanagement process in the form of a defect management model.

This defect management model is not intended to be a standard, but rather astarting point for the development of a customized defect managementprocess within an organization. Companies using the model can reducedefects and their impacts during their software development projects. Thisweb site summarizes the results of the research project and introduces thedefect management model.

Defect Management Process

Keeping in mind the philosophies and goals developed in QAI research reportnumber 8, Mosaic Inc. developed a multi-step approach to defectmanagement. The major steps involved in the process are:


Defect Prevention -- Implementation of techniques, methodology and standardprocesses to reduce the risk of defects.

Deliverable Baseline -- Establishment of milestones where deliverables will beconsidered complete and ready for further development work. When adeliverable is baselined, any further changes are controlled. Errors in adeliverable are not considered defects until after the deliverable is baselined.

http://www.defectmanagement.com/defectmanagement/modelmain.htm


http://www.mosaicinc.com/defectmanagement/index_philosophies.htm



http://www.mosaicinc.com/defectmanagement/dprevention.htm


http://www.mosaicinc.com/defectmanagement/delbaselining.htm




















Defect Discovery -- Identification and reporting of defects for development teamacknowledgment. A defect is only termed discovered when it has beendocumented and acknowledged as a valid defect by the development teammember(s) responsible for the component(s) in error.

Defect Resolution -- Work by the development team to prioritize, schedule andfix a defect, and document the resolution. This also includes notification backto the tester to ensure that the resolution is verified.

Process Improvement -- Identification and analysis of the process in which adefect originated to identify ways to improve the process to prevent futureoccurrences of similar defects. Also the validation process that should haveidentified the defect earlier is analyzed to determine ways to strengthen thatprocess.

Management Reporting -- Analysis and reporting of defect information to assistmanagement with risk management, process improvement and projectmanagement.

Defect Prevention


Without a doubt, the best approach to defects is to eliminate them altogether.While that would be ideal, it is virtually impossible given current technology.In the meantime, developers need strategies to find defects quickly andminimize their impact. Identifying and implementing the best defectprevention techniques (which is a large part of identifying the best software

http://www.mosaicinc.com/defectmanagement/defdiscovery.htm


http://www.mosaicinc.com/defectmanagement/defresolution.htm


http://www.mosaicinc.com/defectmanagement/procimprove.htm


http://www.mosaicinc.com/defectmanagement/mreporting.htm




































development processes) should be a high priority activity in any defectmanagement program.

Defect prevention should begin with an assessment of the critical risksassociated with the system. Getting the critical risks defined allows people toknow the types of defects that are most likely to occur and the ones that canhave the greatest system impact. Strategies can then be developed to preventthem. The major steps for defect prevention are as follows:

Defect Prevention Process

Click on the following links to read more about these steps:

Identify Critical Risks -- Identify the critical risks facing the project or system.These are the types of defects that could jeopardize the successfulconstruction, delivery and/or operation of the system.

Estimate Expected Impact -- For each critical risk, make an assessment of thefinancial impact if the risk becomes a problem.

Minimize Expected Impact -- Once the most important risks are identified try toeliminate each risk. For risks that cannot be eliminated, reduce theprobability that the risk will become a problem and the financial impactshould that happen.

Deliverable Baseline


http://www.mosaicinc.com/defectmanagement/critrisks.htm


http://www.mosaicinc.com/defectmanagement/estimpact.htm


http://www.mosaicinc.com/defectmanagement/minimpact.htm




























A deliverable (e.g. work product) is baselined when it reaches a predefinedmilestone in its development. This milestone involves transferring theproduct from one stage of development to the next. As a work product movesfrom one milestone to the next, defects in the deliverable have a much larger

impact on the rest of the system, and making changes becomes much moreexpensive. A deliverable is subject to configuration management (e.g., changecontrol) once it is "baselined."

For purposes of this model, a defect is defined as an instance of one or morebaselined product components not satisfying their given set of requirements.Thus errors caught before a deliverable is baselined would not be considereddefects. For example, if a programmer had responsibility for both theprogramming and the unit testing of a module, the program would notbecome baselined until after the program was unit tested. Therefore a bugdiscovered during unit testing would not be considered a defect. If, on theother hand, an organization decided to separate the coding and unit testing, itmight decide to baseline the program after it was coded, but before it was unittested. In this case, a bug discovered during unit testing would be considereda defect (See Figure below).



Even for organizations that do not recognize this concept, a deliverable is, forpractical purposes, baselined when the deliverable passes to the next stage ofdevelopment. For example, developers should consider a program

specification baselined when a programmer uses it as the basis to code aprogram. A program should be considered baselined when developers pass iton for integration testing. Finally, developers should consider a requirementsspecification baselined if it is being used as the basis for a technical design.

The concept of baselining is important because it requires an organization todecide both the level of formality that is appropriate, and the point in theprocess when the formality takes effect. In general, a deliverable should bebaselined when changes to the deliverable, or defects in the deliverable, canhave an impact on deliverables other people are working on.

Deliverable baselining involves the following activities:

Identify Key Deliverables: Select those deliverables that will be baselined andthe point within the development process where the deliverable will bebaselined.

Define Standards for Each Deliverable: Set the requirements for each deliverableand the criteria that must be met before the deliverable can be baselined.

Defect Discovery


If technology can not guarantee that defects will not be created, then defectsshould be found quickly before the cost-to-fix becomes expensive. For



purposes of this model, a defect has been discovered when the defect has beenformally brought to the attention of the developers, and the developersacknowledge that the defect is valid. A defect has not necessarily beendiscovered when the user simply finds a problem with the software. The user

must also report the defect and the developers must acknowledge that thedefect is valid. Levinson and Turner provide an example where usersreported problems for years before the developers of the software admittedthere was a defect [LEV93]. Since it is important to minimize the timebetween defect origination and defect discovery, strategies need to beimplemented that uncover the defect, and facilitate the reporting andacknowledge of the defect.

To make it easier to recognize defects, organizations should predefine defectsby category. This is a one-time event, or an event that could be performedannually. It would involve the knowledgeable, respected individuals from allmajor areas of the IS organization. The group should be run by a facilitator.The objective is to identify the errors/problems that occur most frequently inthe IS organization and then get agreement that they are, in fact, defects. Aname should be attached to each category of defect. The objective of thisactivity is to minimize conflicts over the validity of defects. For example,developers may not want to acknowledge that a missing requirement is adefect, but if it has been previously defined as a defect category then thatconflict can be avoided.

The steps involved in defect discovery are as follows:

Defect Discovery Process

Click on the following links to read more about these steps:

Find Defect -- Discover defects before they become major problems.

Report Defect -- Report defects to developers so that they can be resolved.

Acknowledge Defect -- Obtain development acknowledgement that the defectis valid and should be addressed.

http://www.mosaicinc.com/defectmanagement/references_lev93.htm



http://www.mosaicinc.com/defectmanagement/finddefect.htm


http://www.mosaicinc.com/defectmanagement/reportdefect.htm


http://www.mosaicinc.com/defectmanagement/ackdefect.htm

























Defect Resolution


Once the developers have acknowledged a valid defect, the resolution processbegins. The steps involved in defect resolution are as follows:

Defect Resolution Process

Click on the following links to read more about these steps: Prioritize Risk -- Developers determine the importance of fixing a particular

defect.

Schedule Fix and Fix Defect -- Developers schedule when to fix a defect. Thendevelopers should fix defects in order of importance.

Report Resolution -- Developers notify all relevant parties how and when thedefect was repaired.

Process Improvement


http://www.mosaicinc.com/defectmanagement/pririsk.htm


http://www.mosaicinc.com/defectmanagement/schedfix.htm


http://www.mosaicinc.com/defectmanagement/represolution.htm



































This is perhaps the activity that is most ignored by organizations today, butoffers one of the greatest areas of payback. NASA emphasizes the point thatany defect represents a weakness in the process. Seemingly unimportantdefects are, from a process perspective, no different than critical defects. It is

only the developer's good luck that prevents a defect from causing a majorfailure. Even minor defects therefore represent an opportunity to learn howto improve the process and prevent potentially major failures. While thedefect itself may not be a big deal, the fact that there was a defect is a big deal.

Based on the study's findings, participants should go back to the process thatoriginated the defect to understand what caused the defect. Then they shouldgo back to the validation process that should have caught the defect earlier inthe process. Not only can valuable insight be gained as to how to strengthenthe review process, this step serves to make everyone involved in theseactivities take them more seriously. This human factors dimension alone,according to some of the people the research team interviewed, can have avery large impact on the effectiveness of the review process.

NASA, takes an additional step of asking the question: If this defect couldhave gotten this far into the process before it was captured, what other defectsmay be present that have not been discovered. Thus not only is the processstrengthened to prevent defects, it is strengthened to find defects that havebeen created, but not yet discovered. This aggressiveness should be

mandatory on life critical systems. The well-known "Thearc-25" case of aradiation machine that kept issuing "Malfunction 25" messages is one examplewhere problems might have been caught earlier if this step had been pursued[LEV93].

Management Reporting







It is important that the defect information, which is a natural by-product ofthe defect management process, be analyzed and communicated to bothproject management and senior management. This could take the form of

defect rates, defect trends, types of defects, failure costs, etc. From a tacticalperspective, defect arrival rate (rate at which new defects are beingdiscovered) is a very useful metric that provides insight into a project'slikelihood of making its target date objectives. Defect removal efficiency isalso considered to be one of the most useful metrics, however it can not becalculated until the system is installed. Defect removal efficiency is the ratioof defects found prior to product operation divided by the total number ofdefects found in the application.

Information collected during the defect management process has a number ofpurposes:

To report on the status of individual defects.

To provide tactical information and metrics to help project management makemore informed decisions -- e.g., redesign of error prone modules, the need formore testing, etc.

To provide strategic information and metrics to senior management -- defecttrends, problem systems, etc.

To provide insight into areas where the process could be improved to eitherprevent defects or minimize their impact.



To provide insight into the likelihood that target dates and cost estimates will beachieved.

Management reporting is a necessary and critically important aspect of the

defect management process, but it is also important to avoid overkill andensure that the reports that are produced have a purpose and advance thedefect management process.

The basis for management reporting should be the information collected onindividual defects by the project teams. Thus the information collectedduring the defect management process and the classification of individualdefects needs to be considered by each organization.

what is a defect or bug

Documents