I’ve long had a side-interest in project management. Once I even read through the entire Project Management Body of Knowledge. The more I learn about project management, the more I realize that a tester should quickly become a project manager’s best friend. The project manager potentially has the greatest impact on software quality of all the participants in a software product. If a good tester provides information about the product, a good project manager takes that information and applies it. He makes it active and useful. This is the point where technical observation meets business sense and the product begins to really take shape. In fact, I would even go so far as to say that the title of “quality assurance” is actually earned by the project manager, and that those of us who test really aren’t in a position to “assure” anything.

I learned the value of good project management in a previous job, where my test group focused on throwing the various software products our company made together into a mixed environment, to evaluate how nicely everything played together. It was a kind of corporate-wide integration test, throwing together products that were developed by different business units and in different development silos. What I quickly learned was that my influence as a tester was extremely limited outside the sphere of my primary product’s development team. If I was assigned to serve as a part of Product A’s development team and I found a problem with Product B that was causing us grief, it was sometimes difficult to get the developer of Product B to give the bug the attention it merited. After all, his code was doing exactly what it was designed to, within the context of his product, and thus, of his worldview. Product B’s customers were happy (as long as they weren’t also running Product A) and there was no way a Product B developer engineering manager could justify devoting their engineering time and expertise to fixing a problem for Product A.

Now, most developers were good “corporate citizens” and were willing to do what was needed for the larger good of the company and its customers, but my point is that there were many occasions when choosing to fix a bug required an evaluation on a business level, as opposed to a technical evaluation (“Does the current functionality make sense?” “Does it satisfy our customer’s requirements?”). It was at this point that a project manager became indispensable. When Product A’s project manager met with Product B’s project manager and explained the impact of the problem, more often than not, the bug was fixed. In most instances, a two-way learning process took place and both teams benefited from the sharing of information. More importantly, going forward, future bugs were avoided because the project manager of both products had a good understanding of how to avoid the problems they had seen in the past. (Not to say that new bugs weren’t introduced!)
Of course, I feel like the relationship between project management and testing is symbiotic.

Of the many sources of information that project management can draw from, testing is (hopefully) one of the deepest and most meaningful. A tester’s (or a test team’s) illumination on how a product measures up to expectations is a critical piece of the information managers need in order to inform a good business decision on when the product is ready to ship to customers.