Glossary of Software QA/Testing

Part:   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22   23  24  25  26  27  28  29  30  31  32  33  34 

Boundary value
(1)A data value that corresponds to a minimum or maximum input, internal, or output value specified for a system or component.
(2)A value which lies at, or just inside or just outside a specified range of valid input and output values.

Boundary value analysis
A selection technique in which test data are chosen to lie along "boundaries" of the input domain [or output range] classes, data structures, procedure parameters, etc. Choices often include maximum, minimum, and trivial values or parameters. This technique is often called stress testing.
or
A test data selection technique in which values are chosen to lie along data extremes. Boundary values include maximum, mini-mum, just inside/outside boundaries, typical values, and error values.

Branch coverage
A test coverage criteria which requires that for each decision point each possible branch be executed at least once. Syn: decision coverage. Contrast with condition coverage, multiple condition coverage, path coverage, statement coverage.

Equivalence Partitioning
Input data of a program is divided into different categories so that test cases can be developed for each category of input data. The goal of equivalence partitioning is to come out with test cases so that errors are uncovered and test cases can be carried out more efficiently. The different categories of input data are called Equivalence Classes.

Bug
(1)A fault in a program which causes the program to perform in an unintended or unanticipated manner. See: anomaly, defect, error, exception, fault.
(2)A bug is a glitch in computer software or hardware (where something doesn't do what it is supposed to do). Since computers and computer software are very complicated to design, human beings will make mistakes in the design. Unfortunately, in the rush to market, many of these mistakes are not found until after a product has shipped. This is why fixes (also called patches) are often posted on web sites. When considering the quality of a product, one must consider not only the number of bugs, but also the value of the features of a program, since a feature-rich program is likely to have more bugs than a "plain-vanilla" program. 3)A design flaw that will result in symptoms exhibited by some object (the object under test or some other object) when an object is subjected to an appropriate test.

A bug life cycle
Bug life cycles are similar to software development life cycles. At any time during the software development life cycle errors can be made during the gathering of requirements, requirements analysis, functional design, internal design, documentation planning, document preparation, coding, unit testing, test planning, integration, testing, maintenance, updates, re-testing and phase-out.
Bug life cycle begins when a programmer, software developer, or architect makes a mistake, creates an unintentional software defect, i.e. bug, and ends when the bug is fixed, and the bug is no longer in existence.
What should be done after a bug is found? When a bug is found, it needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested.
Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn't create other problems elsewhere.
If a problem-tracking system is in place, it should encapsulate these determinations. A variety of commercial, problem-tracking, management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea of its severity, reproduce it and fix it.

Top-Down Strategy
Top down integration is basically an approach where modules are developed and tested starting at the top level of the programming hierarchy and continuing with the lower levels.
It is an incremental approach because we proceed one level at a time. It can be done in either "depth" or "breadth" manner.
- Depth means we proceed from the top level all the way down to the lowest level.
- Breadth, on the other hand, means that we start at the top of the hierarchy and then go to the next level. We develop and test all modules at this level before continuing with another level.
Either way, this testing procedure allows us to establish a complete skeleton of the system or product.
The benefits of Top-down integration are that, having the skeleton, we can test major functions early in the development process.
At the same time we can also test any interfaces that we have and thus discover any errors in that area very early on. But the major benefit of this procedure is that we have a partially working model to demonstrate to the clients and the top management. This of course builds everybody's confidence not only in the development team but also in the model itself. We have something that proves our design was correct and we took the correct approach to implement it.
However, there are some drawbacks to this procedure as well:
Using stubs does not permit all the necessary upward data flow. There is simply not enough data in the stubs to feed back to the calling module.
As a result, the top level modules can not be really tested properly and every time the stubs are replaced with the actual modules, the calling modules should be re-tested for integrity again.

Bottom-Up Strategy
Bottom-up approach, as the name suggests, is the opposite of the Top-down method.
This process starts with building and testing the low level modules first, working its way up the hierarchy.
Because the modules at the low levels are very specific, we may need to combine several of them into what is sometimes called a cluster or build in order to test them properly.
Then to test these builds, a test driver has to be written and put in place.
The advantage of Bottom-up integration is that there is no need for program stubs as we start developing and testing with the actual modules.
Starting at the bottom of the hierarchy also means that the critical modules are usually build first and therefore any errors in these modules are discovered early in the process.
As with Top-down integration, there are some drawbacks to this procedure.
In order to test the modules we have to build the test drivers which are more complex than stubs. And in addition to that they themselves have to be tested. So more effort is required.
A major disadvantage to Bottom-up integration is that no working model can be presented or tested until many modules have been built.

Part:   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22   23  24  25  26  27  28  29  30  31  32  33  34