project relationships are like contracts. Your role in a software project is defined
by an agreement between you and your colleagues, one which requires you to live
up to your end of the bargain if project goals are to be achieved. In order to
establish and maintain such contracts, we need to understand each other's roles.
If I am charged with fulfilling an important project responsibility, I want you
to understand my role so that you will know what to expect from me. Conversely,
if I need something from you to fulfill my role, I want you to have a clear understanding
of my expectations.
In many software
projects, the relationship between developers and testers is clouded by misunderstanding
and disappointment on both sides.
developers believe that the existence of testers on a project relieves them of
some or all of the responsibility for testing their work. This can result in the
developers expecting more from the testers than they wind up getting. On the other
side of the relationship, if the developers are delivering software that they
have not tested to the extent the testers expect, the testers will continually
gripe about the quality of the software that they receive from the developers.
Not only does this tension exist during
the development and testing phases of the software life cycle, it tends to continue
after the software is deployed. In particular, as users report problems with the
software, it is not unusual for project management, the users, and even the developers
to point to the testers and ask the question, "How could you have missed
that problem?" as if to imply that somehow the testers are responsible for
the quality problem. On the other hand, questions of how the problem got there
in the first place and why the developers didn't find it are hardly ever asked
at all (or at least that's how the testers perceive it).
underlying issue in the developer/tester relationship is that most project members
have a vague notion of the role of testers on their projects. This is particularly
true in projects where there is a distinct team charged with system testing. Developers,
project managers, and even the testers themselves tend to have unrealistically
high expectations about the amount of testing that can go on during the system
test, about the level of coverage that can be achieved, and about the types of
problems that can be routinely uncovered. This has the effect of de-emphasizing
the developers' responsibility for software quality and imposing a definition
of success on testers that is impossible to achieve.
Testing with an Attitude is about the role of system testing in a software
project and is written from the point of view of the system-test team. Two main
questions are addressed:
1. How do we
create a clear "contract" between the system-test team and the rest
of the organization?
2. How do we fulfill
the system-testing end of the contract?
two questions are interrelated (and, in fact, this is a key theme of the book).
The relationship can be shown in a formula: System-Testing Success = (Technical
Excellence) + (Nurturing Front-Loaded Quality)
I of the book focuses on the issues that shape the role of system testing. We
need to understand these issues to answer both of the above questions. The technique
that we will use in Part I to get to the underlying issues is based on a series
of workshops that I have run over the years called "Role-Awareness Seminars."
You may decide to use this technique to establish and reach agreement on the role
of system testing in your project as part of addressing the first question. This
book provides everything you will need to run role-awareness seminars for your
project. In Part I, you will be a participant.
II of the book focuses primarily on answering the second question. This includes
both technical advice for fulfilling the system-test contract and procedural advice
that will influence the behavior of others throughout the project.
technical material is intended to increase the practical advice available in the
literature on system testing. Fulfilling the system-test contract requires technical
excellence in the science of system testing.
for the procedural advice, it may be possible to fulfill aspects of the system-test
contract strictly by influencing behavior. However, you won't be totally successful
unless you change attitudes as well. In other words, in order to answer the first
question completely, everyone on the project should "buy in" to the
contract. At the end of Part II, we will put the final touches on the answer to
the first question by describing how to run a role-awareness seminar using the
material from Part I.
So, again, the
underlying theme is that you need to answer both questions in order to answer