Introduction

In today’s fast-paced software development world, delivering high-quality software quickly is necessary. Traditional testing approaches often detect defects too late, increasing the cost of fixing them.

According to research done by IBM, a bug found in production will cost 6 times more to fix now than if you’d caught it during design.

The following graph from NIST demonstrates how the effort to identify and resolve defects increases substantially as software advances through the five main stages of development.

This is the origin of the Shift Left testing approach. By moving testing earlier in the development cycle, shift left testing helps teams catch defects sooner, improve collaboration, and reduce deployment risks.

In this blog, we will explore what Shift Left Testing is, its benefits, how to implement it, and the challenges you may face along the way.

What is the shift left Testing?

The term “Shift Left” means shifting testing activities earlier (left) in the software development lifecycle (SDLC). Traditionally, testing was performed at the end of development, but in Shift Left, QA and testing started from the initial stages, such as requirement gathering and design.

Traditional vs. Shift Left Approach

 Benefits of Shift Left Testing

• Early Bug Detection: The earlier a bug is caught, the faster and cheaper it is to fix.

• Faster Time to Market: Fixing issues early to speed up releases.

• Cost Reduction: Fixing bugs in development is much cheaper than in production.

• Better Collaboration – Developers and QA work closely from the start. This leads to improved test coverage, earlier consideration of edge cases, and security tests.

About PayPay

Before moving further, let’s understand some details about PayPay and PayPay QA Processes

• PayPay is one of Japan’s leading payment solutions, trusted by over 70 million users.

• We serve more than 10 million transactions every day, ensuring seamless and reliable service.

• At PayPay, speed and quality are paramount to maintaining the trust of our users and delivering exceptional experiences.

Testing Process in PayPay

PayPay previously used an agile approach, but the QA and Dev teams did not work very closely. Each feature was delivered to QA when it was ready end-to-end. Therefore, QA had to wait until the development of both the backend and front end had been completed, along with dev integration testing. This process was slow in delivering the projects and added many issues.

PayPay follows a microservices architecture, which made our existing testing process less suitable. We primarily relied on end-to-end and UI testing, leaving backend API testing insufficiently covered. Therefore, we aim to refine our testing strategy to ensure comprehensive test coverage across all aspects.

Our SDLC process has many phases, from requirements gathering to PRD, then tech documentation, development and integration testing. So the QA team has to wait until all these phases are completed to start work on the project.

SDLC process at PayPay

QA could not begin the testing process until the development phase started. Although high-level test plans and scenarios were being drafted, QA had to wait for the full delivery to initiate test execution and automation script development. Automation scripts were often completed only after the feature sign-off, increasing the effort required for regression testing. Moreover, if bugs were discovered during the feature sign-off process, QA had to put in additional manual effort to resolve them.

The QA process in PayPay starts with PRD analysis, Test Planning, Test Execution, and automation, then QA sign-off.

QA Process at PayPay

Challenges that we were facing:

• Slow Feature Delivery.

• The cost of delivery was high.

• More bugs were caught in later stages, and quality issues occurred.

• More end-to-end UI test cases, so execution time and cost were high

Why Shift Left

For PayPay, both speed and quality matter, and we don’t want to break the trust that Japanese people have shown on PayPay. So to deliver the latest features to our users, we have to increase our pace of delivery without compromising quality.

That’s why we thought of trying the shift left approach in our QA process and starting to work on this part.

How we introduced shift left

For PayPay, implementing a Shift-Left approach in QA was a new process. Additionally, our QA teams were primarily focused on UI test cases, leading to a gap between QA and development teams. As an initial step, bridging this gap became our priority.

To address this, we emphasised backend testing, covering microservice-level and end-to-end testing. We established a backend testing framework for multiple projects and began testing individual microservices. Our focus shifted from verifying the UI to testing microservices, leading us to test individual APIS and specific features.

Building on this progress, we took a step further by adopting a more Shift-Left approach. In one project, we started writing automated test cases as soon as the development team finalised the API schema. This marked a significant milestone in our Shift-Left journey, enabling us to fully automate backend services and test all flows within just two weeks.

The Proof of Concept Stage

Our Shift Left journey began with the PayPay Points (Limited Time Offer), which required developing new backend services under tight deadlines.

So we started discussing the testing process for the project with the technical program manager, the product manager and the engineering manager and suggested the idea of shift left.

New Approach with shift left:

Early Involvement:

• QA actively participated in the requirement gathering and kickoff phase.

• Engaged in discussions during each sprint and throughout the SDLC.

Parallel Processes:

• The QA team started working on test planning and designing alongside development.

• Automation script development began as soon as the API schemas were finalised.

• QA verified APIs and flows in real-time as the development team progressed.

• Focus on the negative side of testing in parallel with development, which includes timeout testing

Improved Collaboration:

• Regular interaction with developers made understanding the project easier.

• This led to faster bug identification and resolution.

Our shift left cycle

Key Benefits of PayPay’s Shift Left Approach:

Implementing the Shift Left approach has delivered substantial advantages for both PayPay and the QA team, including:

Delivery Timeline Improvement

On the rough side, we estimated that we were saving 30 to 40%  of the time with this approach while delivering the project in the shift-left approach.

Most of the time, savings were achieved during the test planning and design phases. By being involved early in the development process, the QA team gained a clear understanding of the requirements, making it significantly easier and faster to create comprehensive test plans and designs.

Additionally, we were able to start writing our automated scripts much earlier in the development cycle, as soon as the schema was finalised. This early start contributed to faster test execution and improved overall efficiency.

Automation Coverage Improvement

With these changes, our automation coverage has improved significantly. Previously, we relied heavily on UI-based and end-to-end test cases. However, we have shifted our focus toward backend testing, resulting in substantial progress. In some projects, we achieved 100% automation coverage of backend APIs and wrote the test cases for all our APIs, ensuring faster, more reliable, and comprehensive testing.

More Bugs at the Initial Phase of Testing

During the early stages of our project development, we observed a significant advantage in detecting and resolving bugs promptly. As the development and testing proceeded in parallel, structured in phases, we were able to identify and fix critical issues early in the lifecycle. This proactive approach helped improve overall product quality and reduce last-minute firefighting.

Bug Creation Trends: Shift Left vs. Traditional Agile

The graph below contrasts the bug creation patterns between two development methodologies: Shift Left and traditional Agile (or Waterfall-like) approaches.

Graph Interpretation

The graph highlights a key difference in how and when bugs are discovered:

• Shift Left Approach: Bug creation is consistent and evenly distributed throughout the development cycle.

• Traditional Agile Approach: Bug creation shows sudden spikes, particularly near the end of the sprint.

This visualisation emphasises how Shift Left testing enables smoother workflows and early problem identification.

Shift Left Approach

• Consistent Bug Detection: Bugs are identified and reported steadily throughout the development cycle, allowing for smoother progress.

• Incremental Testing: As each feature is delivered to QA in smaller units, bugs are reported in manageable chunks, making it easier to isolate and fix them.

• Reduced Bottlenecks: Early testing prevents a backlog of issues at the end of the sprint.

Traditional Agile (Waterfall-like) Approach

• Late Surge in Bugs: QA often receives a bulk of deliverables near the end of the sprint. This delay results in a sudden spike in bug reporting.

• Testing Bottlenecks: The compression of testing into a shorter window increases pressure on QA teams.

• Rushed Fixes and Higher Stress: The condensed timeline leads to hurried bug fixes, increasing the risk of overlooked issues or regressions.

Strengthened collaboration between development and QA teams

Daily stand-ups between QA and development teams increased collaboration frequencies, reducing communication delays.

Development teams were aware of what the QA team was doing and they were aware of QA Activities. This improved transparency boosted confidence among both the team and management. So developers have a proper idea about

• Types of test cases being covered by the QA team

• Automation coverage percentage improvement

• Overall testing progress

How to implement the shift-left in your team?

This strategic shift has significantly transformed the PayPay QA team’s approach. The team is no longer limited to traditional testing methods but is actively adopting modern tools and techniques to enhance quality assurance.

At PayPay, there is no distinction between manual and automation testers. Every QA engineer is responsible for the end-to-end delivery of projects, covering manual testing, automation, UI verification, and overall test strategy.

To support this approach, PayPay and PayPay India focus on hiring versatile QA engineers with strong automation skills and a deep understanding of QA processes, ensuring comprehensive and efficient testing across all stages of development.

Here are the key strategies to adopt Shift Left Testing in your team:

Involve QA from the Start

• The first step should be to include QA in requirement discussions to identify potential risks early.

• Start including the QA team in the HLD and LLD discussion, so that QA can understand the changes in depth and parallelly start with the Test planning and Test case writing

• Define acceptance criteria before development starts.

Adopt Test-Driven Development (TDD) & Behaviour-Driven Development (BDD)

• In TDD, tests are written before writing actual code, allowing QA to start working on test data generation in parallel using mocks.

• In BDD, tests are written in plain English (Gherkin) to improve collaboration and QA can share those tests with the developer and product manager for review

 Automate Feature and Integration Testing

• Implement API tests using tools like Postman, and RestAssured.

• Automate UI tests with Selenium, Cypress, and Playwright.

Integrate Continuous Testing in CI/CD Pipelines

• Use Jenkins, GitHub Actions, GitLab CI/CD to run tests automatically.

• Ensure every code change is tested before merging.

Future Roadmap

🔄 Onboarding & Adoption

• Identify teams that haven’t fully implemented the shift left approach.

• Onboard and train those teams on shift left practices across all testing phases (frontend, backend, integration, and performance).

• Collaborate with teams to integrate shift left into their development workflows.

🔍 Gap Analysis & Improvements

• Analyse gaps in current processes that lead to delayed defect detection or other issues.

• Implement solutions to close identified gaps, ensuring earlier involvement of QA in the development cycle.

• Reduce post-development issues by enhancing test planning, code reviews, and early-stage validations.

🚀 Comprehensive shift left Implementation

• Expand testing coverage to include all aspects (frontend, backend, API, security, and performance) from the early stages.

• Set milestones and track progress for full shift left adoption across all teams.

• Conduct knowledge-sharing sessions to spread best practices and success stories.

Conclusion

Shift Left Testing is no longer optional—it’s a necessity for high-quality, fast software delivery. By moving testing earlier in the development cycle, teams can reduce costs, improve collaboration, and enhance overall product quality.

Key Takeaways

✔ Start testing early – Include QA in requirement discussions.
✔ Automate tests – Unit, integration, and UI tests should be part of CI/CD.
✔ Use TDD & BDD – Encourage developers to write tests first.

Adopting Shift Left isn’t just about finding bugs earlier—it’s about delivering quality products faster and fostering collaboration. Start today and experience the transformation!

Reference

https://www.researchgate.net/figure/BM-System-Science-Institute-Relative-Cost-of-Fixing-Defects_fig1_255965523

https://deepsource.com/blog/exponential-cost-of-fixing-bugs

Disclaimer

The current data represents only one project, and we are actively gathering additional data from other projects following the shift-left approach.