Test Planning - Software Testing: Testing Across the Entire Software Development Life Cycle - page 81

Occasionally, a particular function or feature of an application is identifi ed as
being very expensive to test but poses only a low business risk to fail. So, that
function or feature can be declared out of scope and not tested.
Sources of business expertise for test planning and execution —testers are
usually not expected to be experts in the business to be supported by the appli-
cation or system. So somebody in the “business side of the house” needs to be
earmarked as a business expert who can assist the testing team with design-
ing, executing, and interpreting tests in the correct business context.
Sources of development expertise for test planning and execution —the
development team may design the new application or system with languages,
databases, or support software unfamiliar to the testing team. So, somebody
in the “technology side of the house” needs to be earmarked as a technology
expert who can assist the testing team with building and executing tests cor-
rectly in the target technology environment.
Sources of test data —the testers will need test data as close to “real” data
(production data) as possible. It is helpful from an overall project planning
perspective to identify the sources and the amount of effort necessary to ac-
quire data for the testing environment. Many times, it is both most effective
from a testing perspective and easiest from a data preparation perspective to
use copies of production fi les and databases.
Test environments and their management —after the code is written and
tested by the developer (white box testing), that code needs to be migrated
into a separate testing environment for independent testing by the test team
(black box testing and performance testing). This separate testing environ-
ment needs to be a mirror image of the intended production environment for
the test results to be credible. This separate testing environment also needs
to be under the sole control and management of the test team so that tests can
be run and rerun as needed without any restrictions or confl icts with develop-
ment runs or production runs. One of the most challenging aspects of manag-
ing this testing environment is the coordination of multiple runs and reruns
of test cases. Test cases that are successful must be rerun to prove repeatabil-
ity of results. Test cases that are unsuccessful must be rerun to validate the
subsequent software correction for the defect that caused the test case to be
unsuccessful in the fi rst place.
Testing strategy (chess board) —this is the testing strategy chess board
defi ned for the application under test and all the software support layers as
described in Chapter 4.
<Repeated> Testing details for each development phase —this list of items
is repeated for each development phase. The content for each repeat is dif-
ferent because different kinds of testings are appropriate at each subsequent
development phase. The intent is to tie each development phase's testing ac-
tivities back to the overall test plan to ensure that the testing activities for
each phase support the overall test plan objectives. It is so easy to become

4.

5.

6.

7.

8.

9.