Information Technology Reference
In-Depth Information
that a “good” code drop does not require less QA. In fact, the requirements
are the same, regardless of the test results, because the bugs found are
not corrected on-the-fly. Each time a bug is found, it needs to be docu-
mented in a bug-tracking tool, along with screen shots, as well as the
inputs that caused it, etc. This takes time. Furthermore, a bug may manifest
itself in many places in the software, all of which a tester needs to
document. The quality of the coding and the adherence to standards
during the requirements and specifications phase do have some effect on
the speed of the process, but not as much as many development managers
assume.
If one were to look for guiding principles with regard to estimating
the QA efforts, they would be:
Nature of the application
. The testing effort largely depends on
how the application will be used, rather than on the size and
complexity of the application. For mission-critical applications such
as medical or financial services, not only will there be a need to
test the application thoroughly, but one also needs to test the
application in more dimensions (refer to “Types of Testing” sec-
tion), thus increasing both the duration of the effort and the size
of the team.
Deployed environments
. The diversity of the environment has a
direct impact on the testing effort. Distributed, multi-machine sce-
narios add to the complexity — and heterogeneous, multi-operating
system environments complicate things even further. One must
take special care when third-party applications or components are
used in the system. The QA effort is not necessarily testing them,
but merely verifying all their exposed interfaces. Developers may
have neither the time nor the inclination to understand all the APIs
(application programming interfaces) current, obsolete, or recom-
mended. Documentation of these outside components may also
be inadequate, leading to unexpected error conditions. Because
the testing team is not likely to get much help regarding these
components, they might avoid expending the effort required to
debug or test some foreign code. Even when support is available,
interacting with external parties adds to the lead time.
Acceptance audience
. The nature of the customer has an impact
on the testing effort. Some users try to break the system intention-
ally. It could be a reflection of how quality conscious they are,
although spending a lot of time during user acceptance, in testing
obscure conditions, is often a waste of time. Sometimes, the same
unexpected conditions are triggered by users who are not computer
or software savvy, and enter “undesirable” inputs, showing that
