Quality is more than testing

Business, technology, and quality—the three forces of successful companies

The forces of thriving companies can be divided into three categories—business, technology, and quality. Organizations tend to follow money, thus having a natural focus on business. Budgets are created, goals are set, and metrics are in place. Technology is usually at the heart of the organization, as it is seen as a solution and necessity for success.

Out of the three forces, quality is often left in the shadow of the other two and is seen as a “necessary evil.” While quality might exist on paper, e.g., ISO certifications, it must still be built and acted upon. It is not uncommon that quality is the first to suffer when, for example, cost savings are needed. This often results in a situation where the focus and attention of management is mainly on business and technology at the expense of quality.

Suppose quality ever does become a focus of management. In that case, it’s because the situation has become so bad that there’s a “quality crisis,” for example, a scandal causing share price drops, a loss of subscribers to competitors, or problems in development that impact cash flow.

Quality is not the same as quality assurance or testing

When the need arises, I’m often asked to help with emerging quality problems. For our customers, this means improving the testing process or building support functions for testing. Both are really important parts of quality, but often, I run into a situation where problems are not fixed by improving quality assurance (QA) or testing. So why is that?

The biggest obstacle is that quality is not understood within software companies. It is often seen as something that’s achieved at the side of the development process, or it can, in many cases, mean that quality is the same as quality assurance or testing.

To truly improve quality, your organization needs to understand that quality, quality assurance, and testing are related, but they are not the same thing, and each one of them needs to be invested in instead of expecting them to just happen.

Often, the faulty thought pattern is that quality is the responsibility of the QA department, and no one else in the organization needs to care about it or support development in the building of it.

Another sign is asking who is responsible for testing in the face of a big failure and not searching for problems anywhere else in the development process.

The restaurant example

To give a better understanding of quality, I always start by stating that it’s an abstract concept that cannot be said to be only one thing. Quality is something important to someone important. I like to use an example from the restaurant world to give perspective.

In this example, there are two restaurants making and selling food to customers. At face value, they are not that different. But when we bring the business model in and start to understand it, we can also see the different quality requirements of the restaurants.

Let’s say that one of them has a three-star Michelin rating, and the other specializes in fast food. The Michelin restaurant aims for a sophisticated experience,  while the other focuses on price, ease of experience, and speed of service.

Imagine being a customer at said Michelin restaurant and getting your meal in two minutes. How would you feel? Would you feel like you were getting your money’s worth? Would it feel like good quality? Probably not. You’d likely tolerate a half-hour wait without a problem. Now imagine waiting for your six-euro hamburger at a drive-thru of a fast food place for half an hour. Would your expectations match the service? Would that feel like good quality?

If we think about the above examples and compare them to the thought pattern that quality is the same as quality assurance and testing, we can see the absurdity. In the restaurant example, the equivalent thinking would be that quality is making sure the restaurant's food is served at a suitable time. But we miss so much if we think this way. In reality, testing is only a part of quality.

Quality is much more than testing

When thinking about quality, we should broaden our view because it really is a concept that covers everything in a company.

When we make plans and decisions concerning business and technology, we shouldn’t forget quality but build it in a similar way. We should think about what quality means for our company and what we want to achieve with it. 

Quality is something that touches everything, not just the product. For example:

• How do you lead the company? 
• What and how do you communicate? 
• What do you buy (outsource), and what do you build in-house? 
• How do you develop your product? 
• How do you release your product? 
• How do you deliver your product? 
• How are end customers using your product?
• How is the support handled?

Quality is such a multifaceted concept that it’s challenging to master, but it's also what makes it so beautiful.

Quality is never the same for two companies or for two individuals, for that matter. But from a company's perspective, it can be something that raises your business to new heights or sinks it to oblivion. Building a good quality product and getting that message across to customers can lead to long-lasting benefits.  

Where to start?

My advice is to review the quality improvement process in the entire organization. What does quality mean in the grand scheme of things? What do we have in place already? Where do we want to go? How can we achieve defined goals? Then, start to divide those into responsibilities and roles that drive quality within the company.

If you only focus on quality assurance or testing, you will not get very far. To improve quality, we need to understand the concept and commitment behind it.

The saying goes that DevOps is 70% culture and 30% technology. Transformations can't happen if the culture in an organization doesn't change, regardless of whether new tools or practices are introduced. Learn more in our podcast episode on culture workshops.