Why are there Bugs in Software?

Part:   1  2   3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18 

(Continued from previous part...)

Why are there Bugs?

Since humans design and program hardware and software, mistakes are inevitable. That's what computer and software vendors tell us, and it's partly true. What they don't say is that software is buggier than it has to be. Why? Because time is money, especially in the software industry. This is how bugs are born: a software or hardware company sees a business opportunity and starts building a product to take advantage of that. Long before development is finished, the company announces that the product is on the way. Because the public is (the company hopes) now anxiously awaiting this product, the marketing department fights to get the goods out the door before that deadline, all the while pressuring the software engineers to add more and more features. Shareholders and venture capitalists clamor for quick delivery because that's when the company will see the biggest surge in sales. Meanwhile, the quality-assurance division has to battle for sufficient bug-testing time.

bug

A fault in a program which causes the program to perform in an unintended or unanticipated manner.

Defect:

Anything that does not perform as specified. This could be hardware, software, network, performance, format, or functionality.

Defect risk

The process of identifying the amount of risk the defect could cause. This will assist in determining if the defect can go undetected into implementation.

Defect log:

A log or database of all defects that were uncovered during the testing and maintenance phase of development. It categorizes defects into severity and similarity in an attempt to identify areas requiring special attention.

What is the difference between a bug, a defect, and an error?

an error:
A human action that produces an incorrect result.
Programmatically mistake leads to error.


bug:
An informal word describing any of the above.
Deviation from the expected result.
A software bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working as intended, or produces an incorrect result. Bugs arise from mistakes and errors, made by people, in either a program's source code or its design. It is said that there are bugs in all useful computer programs, but well-written programs contain relatively few bugs, and these bugs typically do not prevent the program from performing its task. A program that contains a large number of bugs, and/or bugs that seriously interfere with its functionality, is said to be buggy. Reports about bugs in a program are referred to as bug reports, also called PRs (problem reports), trouble reports, CRs (change requests), and so forth.

Defect:
Problem in algorithm leads to failure.
A defect is for something that normally works, but it has something out-of-spec.

Bug Impacts

Low impact
This is for Minor problems, such as failures at extreme boundary conditions that are unlikely to occur in normal use, or minor errors in layout/formatting. These problems do not impact use of the product in any substantive way.

Medium impact
This is a problem that a) Effects a more isolated piece of functionality. b) Occurs only at certain boundary conditions. c) Has a workaround (where "don't do that" might be an acceptable answer to the user). d) Occurs only at one or two customers. or e) Is very intermittent

High impact
This should be used for only serious problems, effecting many sites, with no workaround. Frequent or reproducible crashes/core dumps/GPFs would fall in this category, as would major functionality not working.

Urgent impact
This should be reserved for only the most catastrophic of problems. Data corruption, complete inability to use the product at almost any site, etc. For released products, an urgent bug would imply that shipping of the product should stop immediately, until the problem is resolved.

Error rate:

The mean time between errors. This can be a statistical value between any errors or it could be broken down into the rate of occurrence between similar errors. Error rate can also have a perception influence. This is important when identifying the "good-enough" balance of the error. In other words, the mean time between errors is greater than the ultimate user will accept.

Issue log:

A log kept of all issues raised during the development process. This could contain problem uncoverd, impact of changes to specifications or the loss of a key individual. It is anything that must be tracked and monitored.

Priority

Priority is Business.
Priority is a measure of importance of getting the defect fixed as governed by the impact to the application, number of users affected, and company's reputation, and/or loss of money.

Priority levels:

• Now: drop everything and take care of it as soon as you see this (usually for blocking bugs)
• P1: fix before next build to test
• P2: fix before final release
• P3: we probably won’t get to these, but we want to track them anyway

Priority levels

1. Must fix as soon as possible. Bug is blocking further progress in this area.
2. Should fix soon, before product release.
3. Fix if time; somewhat trivial. May be postponed.

Priority levels

• High: This has a major impact on the customer. This must be fixed immediately.
• Medium: This has a major impact on the customer. The problem should be fixed before release of the current version in development, or a patch must be issued if possible.
• Low: This has a minor impact on the customer. The flaw should be fixed if there is time, but it can be deferred until the next release.

Severity

Severity is Technical.
Severity is a measure of the impact of the defect on the overall operation of the application being tested.

Severity level:

The degree of impact the issue or problem has on the project. Severity 1 usually means the highest level requiring immediate attention. Severity 5 usually represents a documentation defect of minimal impact.

Severity is levels:

• Critical: the software will not run
• High: unexpected fatal errors (includes crashes and data corruption)
• Medium: a feature is malfunctioning
• Low: a cosmetic issue

Severity levels

1. Bug causes system crash or data loss.
2. Bug causes major functionality or other severe problems; product crashes in obscure cases.
3. Bug causes minor functionality problems, may affect "fit anf finish".
4. Bug contains typos, unclear wording or error messages in low visibility fields.

Severity levels

• High: A major issue where a large piece of functionality or major system component is completely broken. There is no workaround and testing cannot continue.
• Medium: A major issue where a large piece of functionality or major system component is not working properly. There is a workaround, however, and testing can continue.
• Low: A minor issue that imposes some loss of functionality, but for which there is an acceptable and easily reproducible workaround. Testing can proceed without interruption.

Severity and Priority

Priority is Relative: the priority might change over time. Perhaps a bug initially deemed P1 becomes rated as P2 or even a P3 as the schedule draws closer to the release and as the test team finds even more heinous errors. Priority is a subjective evaluation of how important an issue is, given other tasks in the queue and the current schedule. It’s relative. It shifts over time. And it’s a business decision.

Severity is an absolute: it’s an assessment of the impact of the bug without regard to other work in the queue or the current schedule. The only reason severity should change is if we have new information that causes us to re-evaluate our assessment. If it was a high severity issue when I entered it, it’s still a high severity issue when it’s deferred to the next release. The severity hasn’t changed just because we’ve run out of time. The priority changed.

Severity Levels can be defined as follow:

S1 - Urgent/Showstopper. Like system crash or error message forcing to close the window.
Tester's ability to operate the system either totally (System Down), or almost totally, affected. A major area of the users system is affected by the incident and it is significant to business processes.

S2 - Medium/Workaround. Exist like when a problem is required in the specs but tester can go on with testing. Incident affects an area of functionality but there is a work-around which negates impact to business process. This is a problem that:
a) Affects a more isolated piece of functionality.
b) Occurs only at certain boundary conditions.
c) Has a workaround (where "don't do that" might be an acceptable answer to the user).
d) Occurs only at one or two customers. or is intermittent

S3 - Low. This is for minor problems, such as failures at extreme boundary conditions that are unlikely to occur in normal use, or minor errors in
layout/formatting. Problems do not impact use of the product in any substantive way. These are incidents that are cosmetic in nature and of no or very low impact to business processes.

(Continued on next part...)

Part:   1  2   3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18