2. =Test management
Testing is a complex activity.
Testing is often a distinct sub-project
within the larger software development,
maintenance, or integration project.
Testing usually accounts for a
substantial proportion of the overall
project budget. Therefore, we must
understand how we should manage the
testing we do.
4. A. TEST ORGANIZATION
Independent and integrated testing
When thinking about how independent the test team is, recognize that inde-
pendence is not an either/or condition, but a continuum. At one end of the continuum
lies the absence of independence, where the programmer performs testing within the
programming team.
Moving toward independence, you find an integrated tester or group of
testers working alongside the programmers, but still within and reporting to the
development manager. You might find a team of testers who are independ- ent and
outside the development team, but reporting to project management.
5. Working as a test leader
We have seen that the
location of a test team within a project
organization can vary widely.
Similarly there is wide variation in the
roles that people within the test team
play. Some of these roles occur
frequently, some infrequently.
Two roles that are found
within many test teams are those of
the test leader and the tester, though
the same people may play both roles
at various points during the project.
Let's take a look at the work done in
these roles, starting with the test
leader.
6. Working as a tester
As with test leaders, projects should include
testers at the outset, though it is often the case that
project doesn't need a full complement of testers until the
test execution period. In the planning and preparation
phases of the testing, testers should review and contribute
to test plans, as well as analyzing, review- ing and
assessing requirements and design specifications.
They may be involved in or even be the
primary people identifying test conditions and cre- ating
test designs, test cases, test procedure specifications and
test data, and may automate or help to automate the tests.
They often set up the test envi- ronments or assist system
administration and network management staff in doing
so.
7. Defining the skills test staff need
People involved in testing need basic professional and social
qualifications such as literacy, the ability to prepare and deliver written and verbal
reports, the ability to communicate effectively, and so on. Going beyond that, when
we think of the skills that testers need, three main areas come to mind:
Application or business domain: A tester must understand the
intended behavior, the problem the system will solve, the process it
will automate and so forth, in order to spot improper behavior while
testing and recognize the 'must work' functions and features.
Technology: A tester must be aware of issues, limitations and
capabilities of the chosen implementation technology, in order to
effectively and effi ciently locate problems and recognize the 'likely
to fail' functions and features.
Testing: A tester must know the testing topics discussed in this book
- and often more advanced testing topics - in order to effectively
and efficiently carry out the test tasks assigned
8. B. TEST PLANS , ESTIMATES AND
STRATEGIES
Plans, estimates and strategies depend
on a number of factors, including the level,
targets and objectives of the testing we're
setting out to do. Writing a plan, preparing an
estimate and selecting test strategies tend to
happen concurrently and ideally during the
planning period for the overall project, though
we must ready to revise them as the project
proceeds and we gain more information.
9. The purpose and substance of test plans
While people tend to have different
definitions of what goes in a test plan, for us a test
plan is the project plan for the testing work to be
done. It is not a test design specification, a
collection of test cases or a set of test procedures;
in fact, most of our test plans do not address that
level of detail.
Why do we write test plans? We have three main
reasons.
10. What to do with your brain while planning tests?
1. In terms of the overall organizational needs, this purpose is referred to vari- ously
as the test team's mission or the organization's testing policy. In terms of the specific
project, understanding the purpose of testing means knowing the answers to questions
such as:
1. What is in scope and what is out of scope for this testing effort?
2. What are the test objectives?
3. What are the important project and product risks? (more on risks in
Section 5.5).
4. What constraints affect testing (e.g., budget limitations, hard deadlines,
etc.)?
5. What is most critical for this product and project?
6. Which aspects of the product are more (or less) testable?
7. What should be the overall test execution schedule and how should we
decide the order in which to run specific tests? (Product and planning
risks, discussed later in this chapter, will influence the answers to these
questions.)
11. Estimating what testing will involve and what it will cost
The testing work to be done can often be seen as a
subproject within the larger project. So, we can adapt fundamental
techniques of estimation for testing. We could start with a work-
breakdown structure that identifies the stages, activities and tasks.
Starting at the highest level, we can break down a testing
project into phases using the fundamental test process identified in
the ISTQB Syllabus: planning and control; analysis and design;
implementation and execution; evaluating exit criteria and
reporting; and test closure. Within each phase we identify activities
and within each activity we identify tasks and perhaps subtasks. To
identify the activities and tasks, we work both forward and
backward. When we say we work forward, we mean that we start
with the planning activities and then move forward in time step by
step, asking, 'Now, what comes next?'
