In the world of real estate, whether you’re buying a house, apartment, or condo, rigorous inspections are required before you can move in. Inspectors examine the exterior (foundation, roof, siding, windows), interior (walls, ceilings, floors), plumbing (pipes, fixtures, water heaters), electrical systems, heating, ventilation, appliances, and safety features (fireplaces, chimneys, detectors).
In software development, the Quality Assurance (QA) department plays a similarly crucial role by rigorously testing software, including conducting regression tests. The primary responsibilities of the QA team include defining quality standards and metrics, developing test cases, creating detailed plans, managing defects by logging and notifying the development team, testing performance and load capacity, ensuring code and application security, and performing usability testing often with a core group of super users.
Just as a home inspector is vital for ensuring the safety and functionality of a home, the QA department is essential for any software application. In practice, software engineering tasks often take longer than anticipated, which impacts the time available for QA tasks. Delays in engineering tasks typically push back the software release date, but this rarely happens for QA tasks. Consequently, many software releases are accompanied by numerous known issues.
With the rise of Agile methodologies in the mid-2000s, I’ve observed a decrease in QA involvement, particularly at the beginning of projects. In recent years, some companies have eliminated dedicated QA teams, relying on software engineers to handle testing. This is akin to home builders inspecting their own work—would you feel comfortable purchasing a house that hasn’t undergone independent inspections? Probably not.
The absence of a dedicated QA team introduces significant risks. It compromises the software’s reliability, security, and overall user experience. Developers testing their code may overlook issues that an independent QA team would catch, leading to more bugs and increased security vulnerabilities.
For this article, I conducted a poll on Twitter asking who handles QA on projects at work. The results show that the majority rely on the development team for testing, or, alarmingly, don’t conduct any testing at all! This is a significant issue. Over the past decade, I’ve noticed that most teams I work with don’t have a dedicated QA department. Even when they do, QA is often minimally involved, as I will discuss in this article.
Moreover, user satisfaction diminishes when software fails to meet quality standards. Negative experiences can damage a company’s reputation, leading to a loss of trust and revenue. Just as a home’s integrity depends on thorough inspections, software robustness relies on rigorous, independent testing.
At one company where I worked—America’s largest cellphone carrier with stringent security requirements—I repeatedly requested QA involvement from the start of projects. Unfortunately, my requests were ignored. QA only began their work after the project was completed and ready for production, resulting in a two-month delay. The QA team’s limited resources and poor testing effort meant that even basic issues were missed. Their testing, mostly limited to security code analysis, was ineffective.
This experience highlights a critical lesson: software engineers should never replace a QA department. Engineers have inherent biases when testing their own code and are likely to miss issues that an independent QA team would catch. Nonetheless, engineers should create unit tests for their code.
Unit tests are automated tests written by software engineers to ensure code functions as expected. They focus on functions, methods, and classes and are crucial for early bug detection. However, unit tests alone are insufficient. They must be complemented by the comprehensive, unbiased testing provided by a dedicated QA team.
Without a robust QA process, software quality suffers. Inadequate testing impacts not just project timelines but also the overall security, reliability, and user experience of the software. In a security-sensitive industry, neglecting thorough QA processes is particularly risky, leaving software vulnerable to breaches and undermining user trust.
Unit tests are crucial for maintaining code quality. They ensure that new code changes do not disrupt existing functionality, serve as documentation, provide early bug detection, and offer a safety net for refactoring. However, they cannot replace the comprehensive testing performed by a dedicated QA team.
From my experience, many engineers find working with QA challenging. QA’s discovery of issues can be perceived as an attack, leading to tension between teams. Additionally, engineers may view waiting for QA as a bottleneck.
Effective communication and integration of QA from the beginning of the project are essential. If QA understands how the app was built, testing—including automated tests—becomes easier. Comprehensive project and code documentation is also crucial. QA cannot test effectively without proper documentation, especially if they were not involved throughout the project.

I frequently use this chart in my conference sessions, “Rock Your Code: Coding Standards for Microsoft .NET,” which highlights the cost of fixing bugs. This “money slide” shows that fixing issues discovered by engineers is ten times more expensive than catching them during the requirements phase. By the time users report issues after release, the cost can be over 150 times higher, and users may seek alternatives, leading to revenue loss.
Many companies view QA as a resource drain and increasingly rely on engineers for testing. However, QUALITY IS A FEATURE and should be treated as such. It deserves dedicated resources and attention to prevent costly post-release issues and protect user trust.
I have many more stories to share about inadequate QA testing. For instance, the CrowdStrike outage in July 2024 highlighted the severe consequences of poor testing practices. A single line in a file, which appears to have been insufficiently tested or perhaps not tested at all, led to a global disruption of apps and services for nearly a week. This incident has significantly harmed the reputations of CrowdStrike, Microsoft, Delta Airlines, and many other companies. The financial impact of this outage is likely in the billions of dollars. Given the inadequate QA practices I have observed at various companies, it’s likely that we will face similar, if not worse, incidents in the future.
Summary
Independent QA is crucial for ensuring software integrity, just as rigorous inspections are essential for a safe and functional home. QA departments are responsible for defining quality standards, creating test cases, and ensuring performance, security, and usability. Agile methodologies have reduced QA involvement in some cases, leading to unresolved issues and vulnerabilities. While unit tests are vital for early bug detection and code quality, they cannot replace the thorough, unbiased testing provided by a dedicated QA team. Effective QA, combined with strong collaboration and comprehensive documentation, ensures robust, reliable, and user-friendly software. Quality should be a core feature of any product, with focused resources and attention to avoid costly failures and protect user trust.
Pick up any books by David McCarter by going to Amazon.com: http://bit.ly/RockYourCodeBooks
Make a one-time donation
Make a monthly donation
Make a yearly donation
Choose an amount
Or enter a custom amount
Your contribution is appreciated.
Your contribution is appreciated.
Your contribution is appreciated.
DonateDonate monthlyDonate yearlyIf you liked this article, please buy David a cup of Coffee by going here: https://www.buymeacoffee.com/dotnetdave
© The information in this article is copywritten and cannot be preproduced in any way without express permission from David McCarter.
Discover more from dotNetTips.com
Subscribe to get the latest posts sent to your email.


