Professional 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.

Some 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).

The 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.

System 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?

These 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)

Part 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.

Part 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.

The 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.

As 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 either.