"la calidad no es mi problema"

Alan Koch escribe en CM Crossroads acerca de los roles en la construcción de software de calidad, apuntando a un problema común: la separación de funciones diluye la responsabilidad en la obtención de un producto de calidad, y en la raíz del problema está el hecho de que ésta no se obtiene a posteriori, sino que se construye con el producto. Por lo tanto, su obtención es responsabilidad del proceso de construcción en sí (y sus actores):

Testers Don’t Assure Quality
(...) 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.” [El subrayado es mío] 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.

¿Cómo se debe manejar la calidad? Como una visión global, una cultura de calidad:

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.

Las afirmaciones de Koch remontan a los conceptos de Calidad Total, y han recorrido un ya largo camino en la industria. A pesar de las opiniones de muchos desarrolladores, contrarios a las ideas de emplear sistemas "fabriles", encontrarían muchas ideas estimulantes en el estudio de la evolución de los métodos de fabricación de los últimos treinta o cuarenta años (Lean Manufacturing, Just in Time)