QA IS NOT A COST CENTER
The WHERE, WHY, WHEN, WHAT, WHO and HOW of QA saving companies money
The WHERE— Where Does the $$$ Go
Its all about the dollar, dollar bills ya’ll. First off, lets understand where company money flows in order to figure how to save more of it.
Money comes into the company through sales. Duh. But, there are so many other ways companies SAVE money.
- Reducing the operational cost. (cost of goods sold)
- Having the best product means you don't have to spend so much on advertising and marketing because the industry natural gravitates to you because of the name of your brand.
- Happy customer also do free marketing for you.
- Investors bring much needed capital to expand operations or advertising so that you can grow into new markets or build new product lines.
- Its kind of redundant at this point, but reducing the cost to obtain new customers saves the company money.
- Reducing the amount of people you need to take support phone calls saves money.
- One bad customer can offset 100 happy customers and 1000 normally satisfied customers. How often do you write a review if everything was completely normal in your transaction with whatever company or service? Now think about a bad experience. That still sticks in your brain, and you are happy to complain to as many people who will listen on that poor experience.
The WHY — Risk
If you distil it down to the core, QA indeed exists to save the company money, but that often times is not readily visible or transparent to the organization. For me, QA exists to identify and discussing RISK to the business. This is something that insurance companies have long understood. If you can manage and understand risk, the longer you can stay on task with mission, vision and goals.
So lets talk risk for a minute. Simply put, risk is someone or something that creates or suggests a hazard. This is a great description that we need to pay attention to. As QA continues down this identifying risk path, we see if we don’t do something about these risks, that's where companies can quickly find out why they should have a robust QA organization.
We all know the best strategy to winning Risk (the game) is take over a continent and protect your boarders. :) Evaluating the risk of products and applications is not too different. Stay in control of what you can (new features coming through the pipelines). Control and monitoring can lead to identifying new risks. Then you must assess and evaluate that risk and take appropriate actions to once again control then monitor. Presenting risk in a way that management and the business can understand will help keep quality high for the organization. Think as if you are driving closely behind a car on the freeway. If they can clearly see the road in front of them they can easily swerve from hazards in the road. Yet since you are following so close behind and unable to identify the hazard soon enough you could have quite a disaster on your hands. This is why we need to categorize risk as well. If it was a stopped semi truck in the road obviously it would be a major catastrophic crash. Yet, if it was just some small bit of tire the severity would be low. We also need to understand the likelihood (probability) of even having something in the middle of the road. A stopped semi truck in the middle of the road would not be very likely. But tire debris would be a frequent occurrence. Based off of that knowledge, we can expose a risk rating and make adjustments to our QA processes and procedures accordingly.
The WHEN — Proper Quality Gates
The above chart speaks very much for itself, but lets dig into a bit. The jest of it is this: A defect (bug, quality issue, functionality loss) found after release of code to production is EXPENSIVE to repair. Across the x axis is more or less time, from initial coding to release and the various gates/tests that commonly exist to try and expose quality issues. Then on the Y axis various items:
— Blue line — Defect Injection (when bugs are introduced into the code)
— Orange line — When those defects are often found
— Red line — Cost to repair the defect
Remember this is not talking about a manufacturing company, this is concerning a software company. Its not like we found the machine that's creating the bad part repair it then simply throw out those bad quality items. There is so much more variety and nuances to the costs associated to releasing software. There are so many different reasons for the exorbitant cost growth after release, but the below chart address a few.
The WHAT — The Costs
I like this chart because it give a glimpse into some of the major cost factors in having to run through a repair to software where bugs are found. As mentioned software and manufacturing are not the same, but there are similarities. Similar to manufacturing a bug fix in the software world could have to traverse the entire “manufacturing line” to get released to production. That process could take weeks. Thus its not only the cost of time, there is a variable headcount and large amount of compute cost LOST because it is should have been counted as the original cost to release the first time.
The WHO — People Problems
I have always said QA is the human point where the code goes from developers to customers. QA must understand the backend technical implementation of the code, but fully understand how customers are consuming the code within the program/application. I really enjoy this flow chart because it points how some “root causes” and the down stream “problems” (costs) throughout the organization.
The HOW — Trust
What is the opposite of Risk? Trust
Funny Enough, when you are able to build trust people are willing to take more RISK. When you gain trust, people are more willing to accept problems and faults. When you gain trust, people are more willing to do business with you. NOT simply because the products you sell, but because the WAY you conduct your business with your values and beliefs.
Its not easy to build trust. So how does QA build trust?
Does stepping on a scale help you lose weight?
Does taking tests make you smarter?
Anecdotally maybe, but the obviously not the act itself. Yet, they are observability indicators that something is on the correct track. It's only when we become aware of the problems, can we then start to address them. Testing helps us to understand the product we’ve got, so we can decide whether it’s the product we want.
If QA can obsess over the customer experience and catch the little things. Those little things adds up to be big things. Customers can tell when products/applications went the extra QA mile to CARE about the customer experience. Often times companies do not actually have a quality problem. It is PERCEPTION of quality problem. Thus having good transparency and visibility into the risks so the business can fully make decisions based on those risks is a large part to improving that perception of quality. Thus having a culture of continual improvement and quality can build that trust with customers. Lastly, it may sound counterintuitive but in order to gain trust you first must question everything. Assumptions lead you down the path of FALSE trust. Especially in the QA world it can lead you to not testing the very thing you absolutely should have.
Conclusion
When QA is identifying risks and building trust, it saves the organization money. Hopefully this helped bring some perspectives to your testing efforts and how it impacts to the organization.