QA Issue 4

Why QA Testing Matters More Than Ever

In an era where software powers everything from financial transactions and healthcare records to daily entertainment and critical infrastructure, Quality Assurance (QA) testing/engineering is no longer a nice-to-have—it's essential for survival. Poor quality can lead to massive financial losses, reputational damage, security breaches, and even real-world harm. A single major bug in production can cost companies millions in downtime, lost customers, and legal liabilities. Strong QA practices catch defects early, ensure reliability, enhance user experience, reduce long-term costs, and build customer trust. As applications grow more complex with microservices, cloud architectures, and AI components, robust testing has become the backbone of successful software delivery.

A Brief History of QA Testing

Software testing has evolved dramatically alongside the technology it supports.

In the early days of personal computing, software was primarily distributed as shrink-wrapped packages installed locally on desktops or laptops. Testing was largely manual, conducted late in the development cycle by dedicated QA teams. Bugs were often discovered only after release, leading to costly patches and service packs. The focus was on functionality in controlled, predictable environments.

The shift to cloud-based software and Software-as-a-Service (SaaS) in the 2000s and 2010s changed everything. Applications became dynamic, always-on platforms accessed via browsers and mobile devices. This introduced new challenges: scalability under real user loads, frequent updates via continuous integration/continuous deployment (CI/CD), diverse devices and networks, and the need for rapid iteration. Testing had to become faster, more automated, and integrated throughout the development lifecycle, giving rise to practices like Agile development methodology (with spin off such as Scrum and Kanban), DevOps, Shift Left, and Shift Right testing.

Today, we've entered the era of agentic AI in QA. AI agents go beyond traditional automation or predictive analytics—they can autonomously reason, generate test requirements, generate test cases from requirements, self-heal broken scripts, explore applications, adapt to changes, and even make decisions to optimize testing strategies. This represents a leap from rigid, scripted tests to intelligent, goal-oriented systems that dramatically accelerate coverage while reducing manual effort.

These advancements have set the stage for sophisticated methodologies like Shift Left and Shift Right testing, which help teams deliver high-quality software at the speed modern businesses demand.

Shift Left vs. Shift Right Testing: Strategies for Modern Software Quality

In today's fast-paced software development world, quality assurance isn't just about finding bugs—it's about building better products faster and more reliably. Two key methodologies have emerged to address this: Shift Left and Shift Right testing. These approaches represent different philosophies on when and how to test, but they often work best together.

What is Shift Left Testing?

Shift Left testing moves testing activities earlier in the software development lifecycle (SDLC)—ideally starting during requirements gathering, design, and coding phases rather than waiting until after development is complete.

Instead of a separate QA team testing at the end, developers, testers, and other stakeholders collaborate from the start. This includes unit testing, integration testing, static code analysis, and automated tests run in CI/CD pipelines.

Real-life example: A fintech startup integrates automated unit and API tests into every code commit. Bugs that once surfaced weeks later during final QA are caught within hours, allowing rapid iterations.

Developers are now using things like Puppeteer and Playwright to test code with agents who can simulate a lot of QA testing during the development process to get an idea of how well their code works before it gets assigned to a QA tester.

My Experience

Although it's not in my title (Customer Stewardship Specialist), I also have done QA testing for over three years now as well as specialize in handling the integrations tickets and integration onboarding training. I know from the customer end what they expect in an integration, layout and functionality wise. I also know from troubleshooting 100's of tickets what a customer support person needs in order to troubleshoot effectively. When I've been able to share and do QA testing early on in the development process for a new integration or the redesign of an existing one, the final output has resulted in a better experience for the customer learning and understanding the product. It has also lead to the support person being able to effectively solve the ticket faster or report the issue to the development team more quickly.

An example would be when I was brought into the process to update the UX and UI for existing HVAC integrations between my company's software and different HVAC controls. Before the work was planned out on a Monday board and tasks were assigned to a developer, my product manager met with me to ask my opinion on what customers liked and didn't like about the integrations. Not only did I share my categorized list, I also shared with him the list of request that I had on behalf of my team so that we could have the tools and access that we needed in the UI to better troubleshoot when issues arise. While many people can see the need to improve the product for the end customer, there is also a need to improve the product for the one who supports the software or product. Building out the better functionality for the customer and the better access and data points for the support person early on in the project makes the finished product that much more valuable for everyone as soon as it's released.

However, testing early on with others involved not only allows for refinement to happen early on, but for the whole development process to happen for efficiently. During the development phase, I worked with a developer as a QA engineer to test each part of the new build. Literally as the build would finish, I'd test each new feature or design in the UI. If it failed, I was able to give that feedback to the developer in real time over Slack message or a Slack huddle. The back and forth to build and then test each part happened super quickly as we worked in real time to hash it out. Because I was able to work with him early on in the development phase, I was also able to give feedback and make suggestions that I knew would help the customer and my team. Improvements are more easily implemented when things are still under construction, but one the building is built, it's a lot more effort and time to go back and tear out and put something else in.

Pros of Shift Left Testing

• Early defect detection: Bugs cost significantly less to fix when you fix them early on. IBM research shows fixing defects in requirements or design can be up to 100x cheaper than post-release.
• Cost savings and faster time-to-market: Fewer rework cycles which accelerates releases. Fewer release, then pull back, redo, and then re-release.
• Improved collaboration: Developers take ownership of quality, fostering better team dynamics. When QA testers and feedback from customer service are brought in early to collaborate, subpar behavior or "things that just won't make sense to the customer" are caught when the car is still in the shop so they can be reworked and improved quicker and more easily.
• Higher code quality and better test coverage: Build it the best way possible right off that bat. Whether you do this manually or with agentic AI, design and write the code for the feature or bug fix as clean as possible upfront and test all outcomes to make sure it works the way you intend it to and the way that the customer expects. Adding testing in the early phase creates help push for more efficient code, which makes for a better and easier to support product down the road.
• Enhanced security: By testing early, vulnerabilities are addressed before they compound.

Cons of Shift Left Testing

• Skill gaps: Developers may need training in testing and automation.
• Initial setup effort: Requires investment in tools, CI/CD infrastructure, and cultural change.
• Limited real-world validation: It may miss performance issues, environmental factors, or unexpected user behaviors that only appear in production.
• Potential over-testing: Automating everything early can create maintenance overhead if not managed well.

What is Shift Right Testing?

Shift Right testing extends quality activities into the production environment or later stages (post-deployment). It involves monitoring live applications, gathering real user feedback, A/B testing, canary releases, chaos engineering, and observability.

The goal is to validate software under real-world conditions with actual users, traffic, and environments.

Real-life example: An e-commerce platform rolls out a new checkout feature to 1% of users via canary release. Monitoring reveals higher abandonment rates on mobile devices due to a subtle UI issue. The team quickly iterates based on real data before full rollout.

Agentic AI is also helping in this realm as well, with automating testing in production after the update or bug fix has been released. However, automated testing with manually testing is still valuable, such as giving the new feature or product to a small group of customers who can use it in the real world with real usage stress.

My Experience

Especially when it comes to integrations, the need to test in "real life" and thoroughly test out everything becomes even greater. With integrations, not only are they relying on your software to work, customers are relying on your software to effectively control another product or software that they rely on. Without your software working properly, they're either handicapped in the other product or force to use it manually. This defeats the whole purpose of the integrations. The stakes are higher with an integration. If in the end, you can't prove that it works the way that customers will expect it to work or the way that you meant, then it's not worth launching to the masses. Companies can't promise that their product will integrate and take work off the customer's plate, when it actually doesn't or causes more manual work.

An example would be when my company was planning on making a new integration available. Integrations are so complex and compatibility is a big issue, integrations basically live or die based on compatibility. The hard part is making an integration compatible with all the products that another company has. While you may have an integration with that company, they don't make all their products the same. In the end, testing the integration after it's been built in, in the real world, with real customers is the best way to confidently say "yes, we have an integration with that company, these are the products of theirs we are compatible with, and this is how it works".

Before rolling out this particular integration, I specifically pushed for and asked that my company get customers to do beta testing for us. My product manager and others in leadership agreed. I even suggested that we send out an email campaign asking for volunteers. When we got a few takers, I helped them set up their accounts for the integration, told them what we were specifically testing for, and set the expectation that we needed their honest and real feedback to know if this was something that we could then officially offer. I also had the extra benefit of being the person who did a lot of the initial feedback and QA testing during the development phase and got to compare that to the customer's reaction when I did their onboarding. The results were very positive, they appreciated what we had designed, understood how we were able to make it work, and accepted the limitations.

Pros of Shift Right Testing

• Realistic insights: Captures actual user behavior, performance under load, and edge cases impossible to simulate perfectly in dev/test environments.
• Continuous feedback and improvement: Enables data-driven decisions and rapid post-release fixes.
• Better resilience testing: Techniques like chaos engineering (e.g., Netflix) test system stability in production-like conditions.
• Improved user experience: Directly incorporates customer feedback for iterative enhancements.
• Broader coverage: Validates scalability, reliability, and integrations with live systems.

Cons of Shift Right Testing

• Higher risk: Bugs reach users, potentially impacting reputation or revenue if not mitigated (e.g., via feature flags).
• More expensive fixes: Issues found in production cost more to resolve than early ones.
• Requires robust monitoring: Needs mature observability tools and processes.
• Cultural and compliance challenges: Testing in production may face regulatory hurdles in sensitive industries.

When to Use Shift Left vs. Shift Right

Use Shift Left when:

• You have complex codebases or frequent changes where early prevention saves the most time/money.
• Building new features or in regulated industries needing strong compliance early (e.g., healthcare or finance).
• Teams are adopting Agile/DevOps and want to empower developers.

Example company: Many tech firms like those using Google or Microsoft practices emphasize Shift Left through strong CI/CD and developer testing cultures. IBM promotes it for improved quality and faster delivery.

Use Shift Right when:

• Validating user-centric features or performance in diverse real-world conditions.
• Running continuous delivery where post-release monitoring is essential.
• Mature products needing ongoing optimization based on usage data.

Example company: Netflix famously uses chaos engineering (a Shift Right practice) to test resilience. Many SaaS companies like those on modern platforms use A/B testing and monitoring extensively.

The Power of Using Both: A Balanced Approach

The most effective strategy is often a combination of Shift Left and Shift Right. Shift Left prevents defects and builds quality in from the start, while Shift Right validates real-world performance and gathers insights for continuous improvement.

Key benefits of combining them:

• Comprehensive coverage: Catches both preventable early bugs and unpredictable production issues.
• Faster, safer releases: Early quality + production validation reduces risk in CI/CD.
• Continuous feedback loops: Insights from production inform future development cycles.
• Higher overall quality and user satisfaction: Results in resilient, user-aligned software.
• Defense in depth: Multiple layers of quality assurance across the entire lifecycle.

Practical combined example: A team writes comprehensive automated tests (Shift Left) during development, then deploys via canary releases with full observability (Shift Right). Production data feeds back into the next sprint's testing strategy.

Companies embracing both (often in DevOps transformations) report better velocity, fewer outages, and superior products. Tools like AI-powered automation platforms help bridge the two effectively.

Conclusion: Choose Based on Context, But Aim for Balance

Shift Left and Shift Right aren't competing methodologies—they're complementary tools in a modern quality toolkit. Shift Left is ideal for prevention and efficiency, while Shift Right excels at validation and adaptation. Using both creates a robust, resilient quality process that supports rapid innovation without sacrificing reliability.

As software systems grow more complex with microservices, cloud, and AI, organizations that master this balance will deliver better experiences faster. Whether you're starting a new project or optimizing an existing one, evaluate your team's maturity, risk tolerance, and goals to decide where to shift.

The future of testing isn't left or right—it's holistic. Most importantly, be willing to apply lessons learned from past feature roll outs and updates. Even if the development and QA testing goes really "rocky" once, you can make the process smoother and more beneficial for everyone next time.