Quality Assurance: A Misunderstood Discipline

It's beyond "Testing"

“Can QA verify this real quick?”

“Has QA approved the release?”

“We need more QA people because we have lots of bugs.”

Every time I hear such phrases, something feels off. To me, they imply that quality is the responsibility of a single person/role or a separate team, as if one function can safeguard the entire product quality while everyone else focuses only on delivery. They also suggest a transactional relationship—developers create, QA checks—that divides ownership rather than unifying.

Quality assurance has long been misunderstood. Many people associate it with a job title, a testing phase, or the act of finding defects at the end of development. In my understanding, I see its purpose is far broader and far more essential.

Quality assurance is a guardrail—an intentional system of practices, principles, and feedback mechanisms that ensures software meets the expected level of quality for every stakeholder: the business that invests in it, the customers who depend on it, and the teams who build and evolve it.

Thinking this way moves QA beyond organizational structure. It becomes less about “who does quality” and more about how quality is enabled, protected, and sustained across the entire software lifecycle. Instead of being a checkpoint, QA becomes the guiding principles with which teams can innovate confidently because quality guardrails prevent unnecessary risk, misalignment, or wasted effort.

Quality can be interpreted differently by different stakeholders, influenced by the way they experience the software.

In his book Code Complete 2, Steve McConnell, describes Software quality in two viewpoints of Internal (Development view) and External (User view) quality with a comprehensive list of characteristics for each.

Apart from these two, which are primarily focused on Software construction, the overall software development and management lifecycle, can be viewed through additional viewpoints like Operational quality and Flow quality.

Here, I explain some key characteristics of these four viewpoints on Quality Assurance to build and sustain software products.

1. User and Customer Perspective(External) is what end users directly see and feel. It represents the observable behaviour and experience of interacting with the product.
   Some characteristics that represent customer perspective include:

   1. Correctness: Does the software behave as intended?

   2. Usability: Is it easy and intuitive for users?

   3. Performance: Does it feel fast and responsive during use?

   4. Security: Does software effectively protects data and prevents unauthorised access?

   These characteristics determines customer satisfaction, trust, and the perceived value of the product.

2. Engineering perspective (Internal) refers to the characteristics of the software architecture, design and code that engineers develop and experience daily—qualities invisible to users but critical for sustainability. It includes characteristics like

   1. Scalability: How easily the system can handle increased load or grow in capacity?

   2. Security: How well the system protects its internal components and data from vulnerabilities or unauthorised access?

   3. Maintainability: How easily the codebase can be understood, modified, and extended over time?

   4. Testability: How efficiently the system’s components can be verified through automated or manual tests?

   5. Reusability: How effectively parts of the system can be used in other features, modules, or projects?

      These characteristics are hidden from users, highly visible to engineers, crucial for long-term cost, speed, and stability.

3. Operational perspective describes how the system behaves in real-world environments once deployed. It reflects resilience, stability, scalability, and readiness for real traffic. It includes characteristics like

   1. Availability: How consistently the system remains accessible and functioning when users need it?

   2. Observability: How easily the system’s internal state can be understood through logs, metrics, and traces?

   3. Deployment stability: How reliably the system can be deployed or updated without causing failures or disruptions?

   4. Fault tolerance: How well the system continues operating despite component failures or unexpected errors?

   5. Recovery: How quickly and effectively the system can detect issues and return to normal operation after a failure?

      It’s a crucial quality perspective, since a product may have great internal and external quality but fail under load or behave poorly in production. A feature that works in development but collapses in production diminishes trust and increases operational burden.

4. Flow perspective describes how effective the team’s workflow is. High flow quality prevents defects before they happen and reduces unnecessary rework. Some characteristics include

   1. Requirement clarity: How well the team understands what needs to be built, why it matters, and how it will be validated?

   2. Flow efficiency: How smoothly work moves from idea to completion without bottlenecks, delays, or excessive handoffs?

   3. Communication quality: How effectively team members exchange information, feedback, and context to keep work progressing without misunderstandings?

   High software quality is hard to sustain without a quality-focused team and practices. High external quality is unpredictable and unsustainable without reliable delivery methods. Good working discipline reduces the likelihood of defects, miscommunication, and delivery surprises. They enable teams to work with stability and confidence.

Viewing quality through these multiple perspectives, QA becomes a comprehensive guardrail—an ecosystem that prevents defects, promotes clarity, and supports repeatable excellence across the entire product lifecycle. It enables teams to think beyond testing and beyond roles. It places quality where it belongs: in the shared habits, conversations, good engineering practices, and decisions that shape the product every day.

Quality assurance provides the guardrails, expectations, and preventive mindset that guide a team toward delivering a reliable, sustainable, and valuable product. But guardrails alone are not enough. To make quality repeatable, scalable, and consistently measurable, we also need Quality Engineering (QE), which brings the automation, tooling, CI/CD checks, observability, and engineering practices that reinforce those guardrails continuously.

Together, Quality Assurance (QA) guardrails and Quality Engineering (QE) practices create an environment where teams can move fast—not by cutting corners, but by building with confidence.