I usually tell this to my customers at the beginning of an engagement when we discuss product quality. After an initial silence, the response I usually get is, “What do you mean! I am paying you to make sure that my software is built right and just the way I want it. It’s your job to make sure that it works correctly. Why is it my problem!."
I then explain why it is their problem and what they can do about it!
Ensuring software quality has long been seen as the sole responsibility of the product development team - software developers, the QA team, infrastructure and network teams and the project management team. The product development team (whether it is in-house or outsourced) is tasked with understanding the customer’s needs and building a software product to meet these needs.
The challenge however has always been in understanding the customer’s needsand meeting those needs. An exercise that involves getting objective results (meeting those needs) to a subjective problem (understanding customer’s needs) has the odds stacked against it from the beginning. Meanwhile, Qualityas perceived by the customer is often a measure of how well those needs are met.
SDLC processes have been developed and have evolved over decades with the goal to help address this problem. Reducing subjectivity in defining customer needs has been a huge component of the ‘requirements definition’ phase of all SDLCs. Detailed requirements documents, functional and technical specifications, use cases, epics and stories are just a few of the tools that have been used to add objectivity to the customer’s needs. Agile methodologies have gone a step further and included the customer as a key participant in the development process in an effort to improve the understanding of customer’s needs.
While customers are willing to participate in helping with understanding needs, they also must be involved in determining what it means to meet these needs. Establishing Acceptance Criteria and techniques like Behavior Driven Development (BDD) and Test Driven Development (TDD) build rubrics, which can be used to drive tests to assess quality. These help, but don’t solve the problem completely.
The issue here is not with the process, but usually in the unwillingness or inability of the customer (or appropriate business stakeholder) in defining these rubrics with the level of detail that is actually meaningful in assessing quality. Another oft ignored component in this process is the test data. Using the right test data also goes a long way in establishing quality (meeting needs). This is an area where the customer’s participation is critical because they know their data the best. This is especially true for most current software systems where quality depends on a lot more than just source code. It depends on data, configurations, content, rules and usage patterns.
Development teams can do a lot to ensure that the software product they put out is of high quality, but they cannot do it alone. Customer Participation and more importantly Customer Accountability is critical to achieving high quality.
Have you talked to your customer’s about their role in software quality? How have these conversations gone? Would you like to share any of your stories?