Why Software Quality Assurance Should be a Shared Responsibility

Two coworkers conducting quality testing at their computers

by Lynda Mendiola –

“Software quality isn’t my job. It’s their job.”

The “their” in that statement, of course, is the QA team. And the “my job” refers to any other team member involved in the software development process.

In my experience, the statement above reflects the prevailing attitude in most organizations. People might not say it outright, but that’s what they think and believe. Their actions prove so.

No Pressure, No Responsibility for Quality

As a QA professional for most of my career, I’ve had the opportunity to interface with stakeholders involved in all phases of the software development lifecycle. And, quite bluntly, I’ve observed that most do not feel pressure to meet the quality standards set for the phases in which they work. They don’t feel that quality assurance is their responsibility.

They simply feel that QA should and will ensure that all quality standards are met. So if a quality issue isn’t caught in their phase of development — no big deal; QA will catch it.

To a degree, this attitude is understandable. Everybody is working on tight schedules, and it’s just human nature to focus upon what they feel is their primary responsibility. So the can gets kicked down the road to QA.

But if only we could change that attitude, the benefits would be massive.

Baby Problems Can Grow into Catastrophes

Software quality problems might be likened to cancerous tumors. The longer they remain undiscovered, the more they’re likely to grow and metastasize, with their impact becoming all the more widespread and damaging. And the more they grow, the more difficult and dangerous the removal process. The earlier they are found and excised, the better the patient’s prognosis.

Similarly, it’s quite routine for QA testing to reveal problems that require considerable expenditures of time and effort to fix. But if those problems had been found earlier — long before they get to QA — fixing them would have been much easier. The impact upon both schedule and budget would have been minimized.

And the worst-case scenario is when problems make it past QA, and are found by end users. The repercussions then go far beyond busted schedules and budgets, and might entail brand-damaging consequences that echo for years.

Quite simply, quality assurance is too important to rely upon one team to shoulder the entire responsibility; it shouldn’t be just a job performed by the QA department. It should be a mindset that’s entrenched in all phases of a project, reaching all the way back to the requirements gathering process.

And that would be a paradigm shift at most organizations.

QA Can Take the Lead

The paradigm shift of making QA a shared responsibility is difficult, but doable. That paradigm shift can happen. I’ve been a part of it; I’ve seen it happen. And at a very large company (with revenues in excess of $1 billion).

I should tell you that the experience I’m about to relate occurred within a single development team, and not organization wide. But every paradigm shift must have a starting point.

In this case, the paradigm shift began with the QA department. We pushed for change. We insisted that each team share in the responsibility for quality. If developers sent us product, for example, without performing unit testing and code reviews, we pushed back. Other teams pushed back against our push-back, of course. They initially felt that we were impeding progress and threatening deadlines. But we had management support, and that was critical.

Paradigm shifts don’t happen suddenly and instantaneously. Instead, they’re likely built upon a foundation of small, incremental changes. Here are some small changes you can implement at your organization to begin that paradigm shift:

Make certain that existing responsibilities are met: It’s really not by design that QA bears all the responsibility for quality. At most organizations, each team within a development project is supposed to be performing some level of QA, such as developers that are supposed to perform unit testing. So most likely, standards are already in place to make QA a shared responsibility at your organization — you just have to get each team to comply with their responsibilities.

Get QA involved earlier: Routinely, a semi-finished product is just dumped upon the QA team near the end of the development lifecycle. But it’s better if QA can be more involved with all phases of the development lifecycle, going all the way back to requirements gathering. After all, the QA team often has a unique, comprehensive, user-focused perspective that can be invaluable in heading off problems before they even occur.

Management support is crucial: Initiating a paradigm shift certainly involves change, and people tend to be uncomfortable with change. That’s why it’s critical to have management support from the very beginning. If management buys-in to the benefits of making QA a shared responsibility, they can quell the pushback that’s almost certain to occur as teams are asked to carry more of the QA load.

Better for Everybody

Making quality a shared responsibility will ultimately benefit everybody in the organization. Development costs can be reduced, and development schedule busts will occur less frequently. And ultimately, users of the product will also benefit from a better product.

QA as a shared responsibility is a paradigm shift, and it’s not easy to get there. But making the effort to change is certainly worthwhile. Every little bit of progress toward the broad goal will offer some of the benefits of making quality a shared responsibility.

And that sure beats an organizational mindset that quality is a hot potato belonging only in the hands of QA. Because that attitude results in lots of dropped potatoes.

To Learn more:

Read more about our QA & Testing services

#IdeasRealized