Skip to content

From Traditional to a Modern Software Quality Assurance

Author: Enrique De Coss

Last updated: May 29, 2024

traditional to modern qa
Table of Contents

When referring to the crucial functions of any organization to create a culture robust such as diffusion of quality philosophy, quality mindset, and group cohesion, we realize the obstacles in making such a culture.

How can we move from traditional software quality assurance to a modern quality-oriented way?


Defining a Quality Assurance Culture

I recall, some years ago, an Engineer Manager mentioned during a meeting that a strong focus on quality could adversely affect the development of innovative new products. I was starting my career in software quality assurance, but those words made me think about how we can change that paradigm.

Before talking about quality culture, we need to understand where we are as a company; it’s imperative to make a self-assessment to recognize the need for change, otherwise introducing a new set of norms, values, and beliefs won’t take the expected result. People need to be convinced about the move, having a clear vision and expectations rather than coerced to change.

I always mention that quality culture is not only a set of processes and instructions, “Quality” is a way of life, so the quality culture should be a set of practices and behaviors applicable to all levels in our organizations.

In all organizations with a quality culture, quality is virtually in every aspect of the organization, including talent acquisition, promotion, employee orientation, ongoing training, compensation, management style, decision making, organizational structure, and work processes.

As mentioned above, quality must be everywhere; for practical purposes, I would focus on the software process segment; remember, quality is considered a moving target; this is a never-ending journey to improve the quality of our products and services continuously. 

In a quality culture, we should accomplish close cooperation between managers, employees, and departments. Teamwork is crucial as it creates a sense of ownership and commitment.



From Traditional Software Quality Assurance to Quality Ambassador

We need to remove our bias regarding that an organization’s culture cannot change; otherwise, we could be in a dangerous political game with directors and senior manager levels about why the new model lacks high-quality.

I want to share my vision of the modern quality way and empower our teams about high-quality software. The same as any transformation, it requires much effort to convince positively and provide results. As QA Ambassadors, we must facilitate this transformation, and we can take advantage of the following key points.


1. Educate About Quality 


All team members can test thoroughly, as long as they know how to do it correctly (Everyone can learn how to test appropriately, instead of the simplistic one of everyone can test). As software quality assurance ambassadors, our responsibility is to train them in specific testing activities, embrace a QA mindset, and increase their product knowledge to make them better testers.

The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.

Bill Gates

Testing training is not only about automation; test automation can help us; still, we must encourage other testing practices.

We should be focusing on the add value part of testing and customer perspective scenarios; we must offer ad-hoc advice related to quality and make recommendations to meet project needs.

“What matters is a product or service delivered with high-quality and valued by your customers.”


2. Inspiring and Incentive Quality

Consider the following, tedious testing activities, repetitive steps, and low value; it looks like we are doing something wrong; this is not very inspiring to someone trying to embrace testing. Instead, we need to encourage the whole team about learning and seeing quality as a valuable, challenging, and necessary activity.

The whole team needs to be aware of testing activities, understand high-quality standards. We must help them to define testing activities, organize testing sessions, and facilitate the right testing tools and correct test data they need to test efficiently.

We need to be very careful about how we incentive quality in our team, and understand what incentives your team finds motivating. It could be something simple like fun activities such as testathons or bug bounty programs and choosing the right rewards; these external rewards can motivate your team to do things like embrace quality.

An exciting part about incentive quality is related to fun rewards such as cool swags, gift cards, and testing badges. The value of an incentive can change over time and in different situations.


3. Implementing & Experimenting Quality


“Ideas are easy. Implementation is hard.”

Guy Kawasaki

The teams must write features, test those features, and deliver them to production by themselves. We must not rely on one single role to certify their work, as this role may act as bottlenecks.

Implementing a new quality process will require time and effort for the whole team to be responsible for the quality of the group instead of relying on one specific role. If team members believe that only testers should be catching the bugs, the model will never work.

The whole team must have sufficient training to know how to test effectively (educating about the quality mentioned above is a key in our model). If the developers are the only ones testing a user story, then a lack of training could not help deliver high-quality.

I recommend the following steps to create a clean implementation; these can change to adapt your current implementation process:

  1. Set clear expectations about quality activities
  2. Implementation must be gradual.
  3. Identify possible gaps and risks during implementation.
  4. Evaluate and adjust in case of any change

Be open to experimenting with changes in the testing process; sometimes people are reluctant to change, so let’s try those changes as experiments, and be prepared to drop the change if it doesn’t provide the benefits as expected.

But, on the other hand, if the process change shows a tiny improvement, we can consider it a permanent practice that should be an easy sell and a great win to our quality implementation.

Each team has its context and is expected to do experiments and adapt the quality process to validate the results of those experiments.


4. Reinforcing Quality Assurance

Simply saying that “Now the whole team is doing the testing” will increase the risk of quality problems if we do not verify and adapt in case of any glitch. There are several ways to mitigate this; we can help the team get into the swing of things. Still, the whole team should not rely on us indefinitely to test their work or implement a testing tool since our role is to guide them and provide advice related to quality.

Finally, as QA Ambassadors, we should encourage the team to focus on prevention rather than detection.


Final Thoughts

Quality orientation does not affect product innovation in cross‐functional teams. However, motivation given to cross‐functional teams to take risks leads to more innovative products. While a quality orientation improves product correctness, this is a never-ending journey, and we need to continue learning, growing, and calibrating our process and QA mindset.

The QA Ambassador role can be a big challenge for traditional Testers; this role does not own the quality of the team; instead, the QA Ambassador becomes the quality facilitator, evolving to a quality-oriented approach. This quality model is an entirely different approach from shift left movement and more closely to the whole team process.

Perhaps this model of QA ambassador may reduce the need for a dedicated testing team; I can not guarantee your experience will match mine with this model; still, we can try as an experiment to change from a traditional model. It will be a journey and probably not accessible; nevertheless, you will have to change and adapt if you want to grow in the QA area.

Never be afraid to try new things because life gets boring when you stay within the limits of what you already know.

Happy Bug Hunting!

Enrique De Coss

Enrique A. Decoss is a Quality Strategist with a focus on automation testing teams. A certified Scrum Master, Tricentis Tosca Certified Automation Architect, and Pythoneer, he focuses on web programming, implementing API testing strategies, as well as different methodologies and frameworks. Enrique is currently at FICO but can be found sharing his knowledge on LinkedIn and Twitter.