Despite being a critical aspect of objective analysis, many software project teams fail to achieve independence in QA. With software quality more vital than ever, is anything more crucial to a software project’s quality than testers’ independence?
A completely-independent testing team’s responsibility isn’t to schedule constraints, budget overruns, or workplace politics—it’s to the quality of the application under test.
There’s a reason why justice is supposed to be blind. If you want an honest sentence, objectivity is critical—and nothing clouds that like bias.
Just think about it: would you feel comfortable standing trial against someone who has a friend on the jury? Without impartiality, how can you trust the result?
In the software testing world, this is a problem we see all too often (albeit without the ominous courtroom drama). Unfortunately, the truth is that, for a lot of organizations out there, QA rarely achieves a reasonable level of independence.
This can take a lot of different forms, but none of them are particularly good. Imagine an author editing their own book, or an architect analyzing their own blueprints for structural flaws; neither of those are things that you want to see.
Here are a couple common examples:
- Developers Testing Their Own Code
One of the most common examples of a lack of QA/development independence, it’s also one of the riskiest. Just as a writer cannot be reasonably expected to edit their prose with 100 percent accuracy, a developer cannot be expected to catch every error within their code.Here’s another way to put it: imagine asking an architect to analyze a building they designed for structural integrity flaws. Each job requires a different skillset—and even if someone could do both, you wouldn’t want any personal bias diminishing the objectivity of their analysis.
- Testers Reporting to Development Managers
On the surface, this appears to be a step in the right direction. But while professional testers may be removed from the personal bias that plagues developers testing their own code, their independence is still non-existent since they report to a development manager.That might not seem like much of a problem at first glance. But consider this: what happens when the schedule starts getting tight? The development manager might choose to forgo certain tests or reclassify defects to hasten the release instead of pushing for a longer timetable. With a fully-independent organization, that wouldn’t be a problem, as the testers would report to a Testing Manager, who would ensure that all QA decisions are made in the best interests of the application—and not any conflicting motives.
In contrast to those approaches, a completely-independent testing team reports to a separate organization entirely (ideally, a QA organization). As such, their responsibility isn’t to schedule constraints, budget overruns, or workplace politics—it’s to the quality of the application under test. That enables a bias-free environment where testing and QA can proceed to do what it does best: find defects within the application’s code.
Naturally, upper management can still dictate the organization to eschew some tests to ensure the release meets its schedule or budgetary constraints, but the important thing to note here is that Dev and QA are considered equals here. One is not below the other (like testing so often gets pigeonholed).
At Lighthouse, we consider our independence one of our greatest strengths. Our True North Testing Methodology lends us credibility; but it’s our independence that helps us maximize our clients time-to-market, agility, quality, and value. Without it, we wouldn’t be able to stand up to project teams and advocate the best approach to quality software.
Could your QA team use some more independence? Drop us a line for a quick chat with one of our experts. Even if you’re just looking for advice, we’d love to help out!