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

EXAMPLES OF EQUIVALENCE CLASSES

• Ranges of numbers (such as all numbers between 10 and 99, which are of the same two-digit equivalence class)
• Membership in groups (dates, times, country names, ete.)
• Invalid inputs (placing symbols into text-only fields, etc)
• Equivalent output events (variation of inputs that produce the same output)
• Equivalent operating environments
• Repetition of activities
• Number of records in a database (or other equivalent objects)
• Equivalent sums or other arithmetic results
• Equivalent numbers of items entered (such as the number of characters enterd into a field)
• Equivalent space (on a page or on a screen)
• Equivalent amount of memory, disk space, or other resources available to a program.

Boundary values mark the transition points between equivalence clases. They can be limit values that define the line between supported inputs and nonsupported inputs,or they can define the line between supported system requirements and nonsupported system requirements. Applications are more susceptible to errors at the boundaries of equivalence classs, so boundary condition tests can be quite effective at uncovering errors.

Generally, each equivalence class is partitioned by its boundary vakues. Nevertheless, not all equivalence classs have boundaries. For example, given the following four browser equivalent classes(NETSCAPE 4.6.1 and Microsoft Internet Explorer 4.0 and 5.0), thereis no boundary defined among each class.

Each equivalence class represents potential risk. Under the equivalent class approach to developing test cases, at most, nine test cases should be executed against each partition.

Rules for bug level

Rules for bug level will be determined by the project goals and the project stakeholders. For example, a software product's graphical user interface is very important in the market competition, so inconsistencies in the GUI more important than missing functionality

Critical: Error that make the program can't run.

High: Important functional can be completed, but bad output when good data is input.

Medium: Important functional can be completed and good output when good data is input, but bad output when bad data is input.

Low: Function is working, but there is some little bit problem UI problem, like wrong color, wrong text fond

Rules for bug level will be determined by the project goals and the project stakeholders. For example, a software product's graphical user interface is very important in the market competition, so inconsistencies in the GUI more important than missing functionality

Customer impact as the single way to rank a bug because it eliminates different defintions among different folks. Customer impact is customer impact. There isn't an "impact to testing", a "marketing priority", a "customer support" priority. There is merely a customer impact. Since all of us produce software for a customer, that is really the only field needed. It eliminates confusion in our profession as well as within the companies that each of us work for.

(Continued on next part...)

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