Quality Is Not My Job
Abstract
Thank you, Henry Ford, for making the assembly line the driving force in business. It was so successful in manufacturing that we have adopted assembly line principles into many other domains, even software development! Although different software organizations split up the jobs in different ways, it is not uncommon (in fact, it is considered to be "best practice") to make a clear division between developers and testers.
Although this division of work makes a lot of sense from both a skills and an objectives point of view, it can lead to some counterproductive attitudes. Its most pernicious effect is the attitude that because the testers focus on quality, other people don't need to. "Our job as developers is to make it work. The Testers' job is to assure Quality!"
How can we combat the attitude that "Quality is not my job"?
Why Do Developers Think This Way?
Do software developers want do produce bad code? Of course not! But when we divide up the software development work as we do, it is quite natural for each player to focus on the part of the work that he or she is responsible for. Indeed, it is this narrow focus that is at the root of the problem.
Our developers are responsible for being expert in certain technologies, and for applying those technologies to the problem at hand. This is a demanding role, and the work is often done under serious time-pressures. When people are placed in the position of having less time than they need to perform intellectually strenuous work, it is natural for them to resist "wasting" their brain-space on other things. After all, they already have their hands full with the things for which they are being held accountable!
And that last word is the key. Accountable. What is it that the developers are accountable for? In most organizations, it is for producing code. And although most managers and executives will affirm that the developers should be producing high-quality code, a look at the status accounting and reward systems that they use tells a different story. In most cases, the developers are expected to produce code -- lots of code, and as quickly as possible. Quality doesn't figure into the equation, only production and speed.
In such an environment, how can we expect our developers to focus on anything else? They have no time to spend outside of their stated responsibilities, and quality is not included in those responsibilities. They aren't bad people. Rather, as rational people they put their effort into the activities for which they are rewarded. It just makes sense.
Testers Don't Assure Quality
As we mentioned earlier, one of the premises for the "Quality is not my job" syndrome is the idea that the testers are responsible for assuring the quality of the product we are building. It turns out that this is not the case. Although the testers' job revolves around quality, it is more about measuring quality that it is about assuring it.
Yes, testers find problems, which get fixed resulting in fewer problems. But do we ever expect the testers to find all of the defects in the product? We shouldn't, because the complexity of our systems makes that an unreasonable expectation. The main value of testing is to demonstrate the degree to which the product can be trusted to satisfy the customers' needs.
There is an important truism that says, "You can't test quality into the product; it must be built in." If quality must be built in, then who should be accountable for the quality of the product? Those who build it are the only people we can look to for a high-quality product. The developers are the source of the quality (or lack there of) that the testers measure.
A Culture of Quality
While it is advisable to integrate product quality into our developers' accountabilities, this will work best within the context of a culture of quality. We need an organization that values the quality of what is done just as surely as it values productivity and speed.
In a quality-oriented organization, every individual is conscious of the quality of the end product and their own contributions to it.
- The developers strive for high-quality designs and code, not just for the sake of technical elegance, but mainly so it will satisfy the customer. Rather than slinging code, they carefully engineer a system.
- The Business Analyst strives not just to document the requirements, but mainly to provide the foundation the developers will need to build the right thing. Rather than merely writing a specification, the BA is the liaison between the customer and the developer, assuring that they understand each other.
- The Project Manager strives not just to build a good plan and manage activities, but mainly to establish the environment in which the team can build the product the customer needs and deliver it when the customer needs it. Rather than giving orders and demanding results, the PM is enabling each team member to do his or her job well.
- The tester strives not just to find defects and point fingers, but mainly to determine the degree to which the product as it was built will actually meet the customer's needs. Rather than telling the developers how bad their code is, the tester is helping the developers to do a better job on this project than they did on prior ones.
In an organization like this, no one will say, "Quality is not my job." Rather, everyone is conscious of the ways in which quality is a part of their jobs.