1. What’s the difference between QA and testing?

QA is more a preventive
thing, ensuring quality in the company and therefore the product
rather than just testing the product for software bugs?
* TESTING means “quality control”
* QUALITY CONTROL measures the quality of a product
* QUALITY ASSURANCE measures the quality of processes used
to create a quality product.

2. How do I find information about testing object-oriented programs?
There are a vast number of articles about testing OO programs. I
suggest starting with the September 1994 Communications of the ACM,
which is devoted to this topic. Chase references. The February 1996
issue of Object has a piece on system testing with use cases.

Conferences like STAR and Quality Week and Pacific Northwest Software
Quality Conference seem to always have papers on this topic. I
suggest going to a conference and buttonholing people.

Web sites with discussion:
http://www.cs.washington.edu/homes/gmurphy/testSTApp.html
http://www.testing.com/
http://www.toa.com

Courses on testing object-oriented code (one by Robert Binder,
one by Ed Berard) are described in the Testing Courses FAQ. Also,
a new addition is an offering from Software Quality Engineering.

3. What is black box/white box testing?
Black-box and white-box are test design methods. Black-box test design
treats the system as a “black-box”, so it doesn’t explicitly use
knowledge of the internal structure. Black-box test design is usually
described as focusing on testing functional requirements. Synonyms for
black-box include: behavioral, functional, opaque-box, and
closed-box. White-box test design allows one to peek inside the “box”,
and it focuses specifically on using internal knowledge of the software
to guide the selection of test data. Synonyms for white-box include:
structural, glass-box and clear-box.

While black-box and white-box are terms that are still in popular use,
many people prefer the terms “behavioral” and “structural”. Behavioral
test design is slightly different from black-box test design because
the use of internal knowledge isn’t strictly forbidden, but it’s still
discouraged. In practice, it hasn’t proven useful to use a single test
design method. One has to use a mixture of different methods so that
they aren’t hindered by the limitations of a particular one. Some call
this “gray-box” or “translucent-box” test design, but others wish we’d
stop talking about boxes altogether.

It is important to understand that these methods are used during the
test design phase, and their influence is hard to see in the tests once
they’re implemented. Note that any level of testing (unit testing,
system testing, etc.) can use any test design methods. Unit testing is
usually associated with structural test design, but this is because
testers usually don’t have well-defined requirements at the unit level
to validate.

4. What are unit, component and integration testing?
Unit Testing: in unit testing called components (or communicating
components) are replaced with stubs, simulators, or trusted
components. Calling components are replaced with drivers or trusted
super-components. The unit is tested in isolation.

component: a unit is a component. The integration of one or more
components is a component.

component testing: the same as unit testing except that all stubs
and simulators are replaced with the real thing.

Two components (actually one or more) are said to be integrated when:
a. They have been compiled, linked, and loaded together.
b. They have successfully passed the integration tests at the
interface between them.

Thus, components A and B are integrated to create a new, larger,
component (A,B). Note that this does not conflict with the idea of
incremental integration — it just means that A is a big component
and B, the component added, is a small one.

Integration testing: carrying out integration tests.

Integration tests (After Leung and White) for procedural languages.
This is easily generalized for OO languages by using the equivalent
constructs for message passing. In the following, the word “call”
is to be understood in the most general sense of a data flow and is
not restricted to just formal subroutine calls and returns — for
example, passage of data through global data structures and/or the
use of pointers.

5. What’s the difference between load and stress testing ?
One of the most common, but unfortunate misuse of terminology
is treating “load testing” and “stress testing” as synonymous. The
consequence of this ignorant semantic abuse is usually that the system
is neither properly “load tested” nor subjected to a meaningful stress
test.

1. Stress testing is subjecting a system to an unreasonable load
while denying it the resources (e.g., RAM, disc, mips, interrupts,
etc.) needed to process that load. The idea is to stress a system to
the breaking point in order to find bugs that will make that break
potentially harmful. The system is not expected to process the
overload without adequate resources, but to behave (e.g., fail) in a
decent manner (e.g., not corrupting or losing data). Bugs and failure
modes discovered under stress testing may or may not be repaired
depending on the application, the failure mode, consequences, etc.
The load (incoming transaction stream) in stress testing is often
deliberately distorted so as to force the system into resource
depletion.

2. Load testing is subjecting a system to a statistically
representative (usually) load. The two main reasons for using such
loads is in support of software reliability testing and in
performance testing. The term “load testing” by itself is too vague
and imprecise to warrant use. For example, do you mean representative
load,” “overload,” “high load,” etc. In performance testing, load is
varied from a minimum (zero) to the maximum level the system can
sustain without running out of resources or having, transactions
suffer (application-specific) excessive delay.

6. What is the best tester to developer ratio?
Reported tester:developer ratios range from 10:1 to 1:10.