How QA Can Influence Product Development Strategies

QA testing…can be a company culture?

Yep. Article done. Next topic!

Okay, perhaps an explanation might be of more use. I think, live, and breathe QA, much to my wife’s chagrin! Every life situation that comes up is thoroughly assessed for potential risks and outcomes, possible remediations should certain outcomes happen, and then building strategies to ensure that all potential risks are exposed. Yes, I do have a very patient wife indeed.

What I am talking about here, though, is the culture of QA. The very core of my being is to think critically and to assess risk. While that might be crazy-making for my wife, in a QA company it is pure gold.

Great, but why should I care?

If you are reading this, I imagine you are involved in software development in some way. The culture that I live and breathe is a culture I try to instill in companies.

A company that thinks quality assurance at its heart simply produces better products. It really is that simple. Unfortunately, in many software development life cycles, QA is an afterthought or add-on component. This is particularly true for small to medium-sized startups that have grown quickly.

This state of affairs is entirely logical. Someone has a brilliant idea and the goal is to bring that into reality as fast as possible. It is like building a racing car, as the goal is to make it go as fast as possible, and safety is somewhat of a secondary concern.

But the problem with that approach is that products and development have to mature, particularly as teams grow. This is the critical point where software quality assurance has to become a part of the company culture, or the end users of the software are going to become increasingly dissatisfied with product rollbacks, hotfixes, and persistent bugs and regressions.

Risk averse?

Two great examples I have been thinking about are the situations that evolved in mid-2024 with CrowdStrike and Sonos. CrowdStrike didn’t fully test a software update and the resulting crash of their software cost companies billions of dollars. Sonos released a major redesign that removed many relied upon features and introduced multiple bugs into the company’s app. Both companies have historically enjoyed excellent reputations, but both are now dealing with fallout because of these quality assurance issues.

In many cases, these companies are suffering financial and reputational impacts and will be on a long road to recovery. In the case of Sonos, they managed to not only disenfranchise assistive technology users who have loved the accessible experience of Sonos but also impacted the average users of these solutions. There was even a public movement to try and have Sonos roll back to the app that came out before their May 2024 app redesign.

The situation with CrowdStrike was even more notable as the reach of that issue was incredible and will likely be litigated for many years by the companies who allege direct financial and operational impact due to the outage. The estimate is that the financial damage was at least US $5 billion, with other estimates suggesting in $15 billion dollars of losses.

I have no direct knowledge of the root cause, but the end results were poor quality products being released. I have to wonder if the companies either did not embrace a culture of quality or simply lost sight of their target when these issues happened.

What can my organization do?

How about getting QA so deeply into the company culture that everyone thinks about it, from the CEO down? I can suggest several strategies to start on this journey.

Let’s get the obvious one out there first, as you are here on a QA company site!

• Buy versus build. If you want a fast solution to building quality assurance into your culture, you can take the easiest route by having experts come in and help you set everything up. That is what my team and I do, including everything from getting that culture into a real state to the practical aspects of testing the product. I think this solution is the fastest way to make your aspirations real.

For practical advice to organizations that want to get this going, here are some concepts that are going to serve well:

• QA isn’t just the job of QA: QA professionals can’t be the tail that tries to wag the dog. QA has to be embraced by product teams, software development teams, as well as the QA team members themselves. People have to see the big picture and it takes coordination and communication between the three groups to get everyone on the same page.
• Behavior / Test Driven Development: This might serve a company well, but it takes the entire company being of one mind. We’re talking about settling on standardized language to communicate ideas between disparate groups. We are talking about the QA team being able to translate ideas into tests and those tests guiding developers. Business Analysts and Product Managers have to buy in. I’ve seen this work, and I’ve seen it fail. When it fails, it fails for the same reason every time. One or more groups don’t buy into the process, and it dies on the vine!
• Risk assessment: You have to get people to imagine the risks and then take steps to prevent them before they happen. Even if a risk is seen and the decision is made to go live anyway, it has happened with a conscious choice. That is very different from reacting to something unexpected, as contingencies can be in place.
• Process: Quality cannot exist without process. If your company has no process, then it is time to structure one. From how the QA works with the development team to the role that QA plays with Product Managers, the processes must be known by all stakeholders and receive buy-in.
• Communication: Look at the relationships between the groups and eliminate or remediate friction. Developers and Product should never be adversarial to QA, and vice versa. This happens frequently, so for quality to become cultural, and if the goal is to release excellent software, there is no room for that negative culture to persist.
• QA first: QA testing doesn’t happen when the code drops in a quality-focused organization. QA happens when the idea for a feature and product is imagined, and you utilize the minds programmed to find risks and expose them before they get to the developer.

There is more that an organization can do, but I’ve given some core concepts that I think might help. Any company producing software needs critical thinking, and we’re here to help with that if your organization needs guidance or assistance.

Need help with QA? Let’s talk.