How "Testing for Knowledge" Benefits the Testing Profession
The change in our conversation will have positive impacts on perceptions about our contribution. Today, the testing function is perceived as driving the cost of the testing phase. Once we change the conversation, the business becomes responsible for deciding what costs to incur for each defect. Their perceptions about the cost of testing will change as they continually confront the fact that a major cost driver in the test phase is development rework. There is a big difference in the way most people react to the statement "it failed" versus "it doesn't match." The change in our conversation removes any hint of an adversarial relationship with either development or the business. We simply report the facts and function as a knowledge broker. And, perhaps most importantly and without ever having to ask it out loud, we make visible the important question of all. When the business decides that a requirement isn't important enough to spend the money to rework and retest the related code, it begs the question, "Why did we spend the money to have the code developed and tested in the first place? Why didn't we firm up requirements before we started coding?" Over time, if we keep a record and make it publicly available, these cost metrics will drive the transformation of the software development process to everyone's benefit.
The change in what we do has positive impacts, both direct and indirect, on our value to the business. Testing for knowledge allows us to reduce the amount and cost of testing we do. It improves our productivity on the current project and decreases costs in both test planning and test execution on future projects involving the same system. Those benefits have a direct and positive impact on our value to the business. "Testing for knowledge" can increase the productivity of the development organization in the testing phase by providing knowledge that helps them debug problems. It can also increase their productivity in the analysis and design phases of future projects by providing knowledge of how the system currently works. These benefits increase our value to the development organization and, through them, to the business again.
Finally, testing for knowledge produces a tangible asset. That's important. As the business begins to recognize that both the testing and development groups are utilizing the knowledge base to improve productivity and decrease costs, this knowledge partnership will prove its own value. This testing approach will be tied at a primary level to the final product. We will know we've arrived when the conversation ends not with "Did the software pass?" but with "Has the knowledge base been updated?"
Testing for knowledge extends the current "test to fail" objective to focus on the true source of productivity in software development: knowledge. Testing, beyond process improvement, can deliver the knowledge we need to demonstrate the initial successes the business requires. Business is business, and in this, there is no real difference between hardware and software. Investments start small and get bigger, based on successes where the return can be tied directly, in a cause-and-effect relationship, to the investment. The difference between software and hardware is which quality function can deliver those successes. In hardware manufacturing, it was quality assurance implementing process improvements. In software development, it will be quality control "testing for knowledge."