Information Technology Reference
In-Depth Information
of a bug. QA teams tend to take the software specifications literally,
weighing all functionality equally. This can lead to differences in opinions
as to how a bug is tagged.
The bug should be communicated and assigned to developers who
can fix it. Often, the test tracking tool itself becomes the mode of
communication. Engineers are expected to read the bug lists, or read
notifications automatically generated from the tool. After the problem is
resolved, the fixes should be retested. Any information relevant to regres-
sion testing should be conveyed from engineering to QA. Such information
gets lost if not properly updated in test cases.
Release Management
A decision to release an application for general use is always fraught with
risk because it is not always possible to test for (or remove) all software
bugs. Naturally the question arises as to whether or not most of the bugs
have been identified. Because this relates only to the QA group, it is
considered QA's responsibility to decide when the software quality is
sufficient. It is important to know that quality is only one of the parameters
in the release equation. Other parameters, and often equally important,
include externally communicated timelines, business goals, competitive
pressures, or legal contracts. Consequently, the decision maker should be
an individual or group that is aware of all such aspects.
Push and Pull: The Equation between Development
and QA
The relationship between engineering and quality assurance (QA) is one
of active tension and cooperation. The tension arises due to the “fault-
finding” mode under which QA, by the very nature of its responsibilities,
operates. The cooperation derives from the shared objective (which may
often be hidden under the tensions) of improving the quality of the
deliverable. It is crucial that organizations understand the push-pull rela-
tionship between the two.
Testing works in cycles; a test cycle consists of running through one
set of predefined tests. This cycle must be taken to completion, if only
to ensure that the quality of that code drop is well understood. Interrupted
test cycles leave that status undefined. Without a reliable status, one cannot
make a call about acceptability. The code drop could be so bad that it
may not be worth the time and effort to complete the cycle. In that case,
the cycle can be formally terminated. Such termination should also be
