BLOGUE
In many of our projects, we worked in co-development environments, where our teams collaborated with external teams, clients, or different departments within the company. These setups often introduced additional complexities—varying expectations, differences in workflows, and misalignment in quality assurance responsibilities. Many teams faced similar issues: late-stage bug detection, unclear requirements, and costly rework due to last-minute changes.
Through our experiences, we realized that a more structured approach was necessary to prevent these problems from recurring. This is where shift-left emerged as a logical next step. Shift-left helps teams define expectations earlier, collaborate more effectively, and reduce friction throughout the development cycle.
The Problem We Faced
Our team was struggling. Every release felt like a race against time, and more often than not, we were losing. Bugs were slipping through the cracks, and our feedback loops were painfully long. When QA flagged issues, developers had already moved on to other tasks, leading to frustrating rework and delays. It felt like we were always playing catch-up, and the rigid processes we had in place only made things worse. The disconnect between development and QA created unnecessary friction, slowing us down even further.
Our QA process was primarily focused on finding bugs. It felt like we were always chasing problems rather than preventing them, which was frustrating and exhausting. QAs had to test each branch pushed for review, often leading to bottlenecks. We conducted group testing every week to catch even more bugs, which consumed valuable time and effort. Additionally, QAs performed smoke tests in a staging environment before each production release, further delaying the process and increasing the workload.
We realized that something had to change. We needed a better way to collaborate, streamline our workflows, and ensure quality without it becoming a bottleneck. Our goal was clear: break down silos, identify bottlenecks, resolve constraints, and bring quality into the heart of our development process rather than treating it as an afterthought.
Focusing solely on finding bugs will only lead to discovering more bugs. Instead, the real solution is changing the entire team's processes to prevent defects and make them manageable before conception. The shift-left approach is not just about early testing; it’s about ensuring that quality is built into the process from the start, with a strong emphasis on people over process.
What is Shift-Left?
Shift-left in software development is an approach that emphasizes the integration of quality assurance activities earlier in the development lifecycle. Instead of addressing defects late in the process, shift-left encourages proactive measures such as collaboration, test automation, and process improvements to detect and prevent issues as early as possible. This approach not only reduces costs but also enhances overall efficiency and software quality.
See how shifting left can help reduce delays and ship sooner in my colleague's article.
Understanding Quality Assurance vs. Quality Control
To successfully implement shift-left, it's crucial to understand the distinction between Quality Assurance (QA) and Quality Control (QC). While shift-left focuses on integrating quality early in the development cycle, knowing how QA and QC complement each other ensures that the right strategies are applied at the right stages of development.
QA and QC are often used interchangeably, but they have distinct roles in the software development lifecycle. QA focuses on preventing defects by improving processes and ensuring best practices are followed throughout development, while QC is more about identifying and addressing defects in the final product.
Key Differences Between QA and QC:
Focus
- QA is process-oriented, ensuring quality is built into the development lifecycle.
- QC is product-oriented, identifying defects in the final product.
Objective
- QA aims to prevent defects through process improvements.
- QC aims to detect and correct defects before release.
Approach
- QA takes a proactive approach by optimizing workflows and preventing issues.
- QC takes a reactive approach by testing and identifying issues after development.
By emphasizing QA over QC, organizations can shift their mindset from merely finding bugs to preventing them in the first place.
Imagine you work in a sausage factory. You receive customer complaints that your product is defective, let's say it has no salt at all [... ] Now you won’t go into the grocery store and tape a salt packet to each and every package in the store to solve the problem, would you? You will instead find the root cause problem and add processes to prevent those kinds of errors from ever happening in the first place. And that my friend is how you do Quality Assurance.
— Vincent Cartier, Senior QA, formerly at Newforma
How Culture Shapes Quality Assurance Success
Culture plays a critical role in the success of quality assurance efforts. A poor company culture—one that undervalues the contributions of QAs and isolates them from the development process—can have a detrimental effect on overall product quality. When QAs are treated merely as gatekeepers rather than strategic partners, they are left dealing with a flood of defects rather than preventing them from the outset. This leads to frustration, inefficiencies, and a suboptimal product.
On the other hand, a positive culture that empowers QAs and fosters collaboration can transform the role into something much more impactful. When QAs are integrated into the development process early, provided with the right tools, and encouraged to contribute beyond testing, they become enablers of quality rather than just testers. They can focus on refining processes, sharing knowledge, and helping developers avoid defects before they occur.
Managers can play a significant role in supporting QAs by offering incentives highlighting their contributions and value within the team. Incentives such as career growth opportunities, public recognition, and additional responsibilities can help QAs feel more valued and motivated. However, the most effective incentives come organically—when QAs are given more responsibilities, confidence, and benefits, they naturally feel empowered and invested in the team's success.
Empowering QAs means making them equal stakeholders in the development cycle, valuing their input, and ensuring they are part of key discussions from the outset. When organizations adopt this mindset, QAs are more engaged, take ownership of quality, and contribute meaningfully to the team's success.
The best way to help QAs is by helping them, coaching them, teaching them. By fostering connections and engaging with better communication within my team. By giving QAs a purpose higher than just testing for defects.
— Catalin Bunescu, QA at Newforma
Simplifying Our Workflow
Recognizing the challenges we faced with our existing QA processes and the distinction between Quality Assurance and Quality Control, we knew that simplifying our workflow was a crucial next step. We needed to break down silos, enhance collaboration, and streamline our approach to better align with the shift-left philosophy.
One of the most impactful changes we made was simplifying our workflow on the Kanban board. Our previous process was cumbersome, with too many columns, making the workflow overly sequential. Each step required a handoff, leading to delays and inefficiencies. This rigidity often held us back, making it difficult to adapt and respond to changes quickly.
Imagine a scenario where a developer finishes a feature and pushes it for Review before QA gets involved. During the review, another developer suggests a refactor to improve code maintainability, which the original developer implements. The feature then moves to QA, where a tester identifies a major UX issue that wasn’t considered earlier. Now, the developer needs to rework the feature again to address the UX problem, potentially undoing or complicating the refactor they just did.
In this case, following a strict sequential process—first Review, then QA—results in wasted effort. The developer refined the code structure without realizing that the functionality itself might need changes. If QA had been involved earlier, the UX issue could have been caught before the refactor, allowing for a more effective and efficient solution.
By simplifying the workflow and overlapping Review and QA, we ensure critical feedback happens at the right time, avoiding unnecessary rework and improving collaboration across roles.
By streamlining the board, we focused on collaboration rather than rigid process adherence. The old process forced sequential work, creating artificial boundaries between developers and QAs. However, by reducing unnecessary columns, identifying bottlenecks, and focusing on shared responsibilities, we created a more dynamic and cooperative environment that enabled practices such as pair work, which fosters better collaboration.
Instead of moving work from one column to another and waiting for acceptance or rejection, we introduced a Review step where QAs and developers worked together. By collaborating earlier, we could address potential issues faster and improve code quality collectively. Instead of reporting bugs in separate tickets, QAs added comments directly in pull requests, facilitating immediate action and reducing friction.
By simplifying our workflow, we reduced overhead and set the stage for deeper collaboration and teamwork. The changes we made encouraged more fluid interactions between QAs and developers, leading to significant improvements in our processes and outcomes.
This was the first time I saw that kind of workflow in my QA career. It greatly helped. By modeling and merging some of our QA processes with the devs we felt like equals. We were either implicated or kept in the loop.
— Vincent Cartier, Senior QA, formerly at Newforma
How Simplification Fostered Collaboration
By removing many columns that enforced a sequential process, we accidentally created cooperation by encouraging work overlap between QAs and developers. Fewer process barriers meant we could communicate more effectively and catch issues before they became real problems. What used to be a strict handoff process transformed into a collaborative effort.
- Review became a collaborative step: Instead of QAs simply pointing out bugs, they now added constructive comments in pull requests, helping developers address issues immediately.
- Reduced overhead: Instead of moving cards back and forth between columns for acceptance or rejection, QAs simply approved pull requests.
- Fewer defects: Issues were now corrected earlier in the process, during the review phase, rather than closer to deployment.
- Continuous Deployment made final steps obsolete: Our new deployment strategy greatly reduced the need for extended staging and smoke testing phases, enabling faster and more reliable releases.
Empathy and not being afraid to try unorthodox ways of working goes a long way. We need to overthink human factors because we often overthink artificial factors.
— Vincent Cartier, Senior QA, formerly at Newforma
Developers & QAs: A Shared Quality Mission
Building on our efforts to simplify workflows and foster collaboration, we recognized that true quality could only be achieved by sharing responsibilities across the entire team. Simplifying our workflow not only improved efficiency but also highlighted the need for developers and QAs to work more closely together to refine processes and prevent defects earlier in the development cycle.
A crucial aspect of the shift-left transformation is the realization that quality is a shared responsibility. Developers must take ownership of testing and ensuring code quality, while QAs should focus more on real quality assurance—reworking processes prior to conception to make bugs less likely to occur.
By shifting testing responsibilities to developers, QAs can move away from being purely testers and instead act as enablers, guiding teams to build quality into their processes. This shift allows QAs to:
- Analyze and refine workflows to prevent recurring defects.
- Collaborate with product teams earlier to define clear, testable requirements.
- Implement quality strategies that reduce risk before development begins.
Seeing developers take ownership of quality was a game-changer; it made our work as QAs more strategic and valuable. Developers, in turn, become more engaged in testing and quality efforts, leading to better collaboration and a deeper understanding of potential risks.
QA is not your personal tester. If QA is finding a lot of bugs with your code, then you're not checking your own work closely enough.
— Dan Kennedy, Senior Engineering Manager, Full-Stack Tech Leader and Coach
The Fantastic-Four: A Tailored Approach to Collaboration
Building on the concept of shared responsibility, we initially tried the 'Three Amigos' approach, which brought together developers, testers, and product owners to collaborate on defining requirements and acceptance criteria. In my past experience, the Three Amigos were an effective way to encourage early collaboration and alignment. However, we often found that QAs were left out of these critical discussions, leading to gaps in quality planning and missed opportunities for early defect prevention.
While the Three Amigos approach greatly helps in shifting left, it didn’t quite meet our needs. We developed the concept of the Fantastic Four, a tailored approach that better suited our team dynamics and goals. The Fantastic-Four consists of one representative from each of the primary disciplines that make up a development team: Product (Product Owner), Design (Designer), Quality Assurance (QA), and Development (Team Lead, in our context, but any dev will do). This structure ensured that every aspect of the project was considered from the outset, fostering a more robust understanding of both the software and the domain.
We faced the challenge of involving around 15 team members in meetings, which quickly became inefficient. We significantly improved our overall efficiency by reducing the number of participants and making fewer people accountable for key responsibilities. The Fantastic-Four acted as a bridge between different parties and departments, ensuring that communication was centralized and decision-making was streamlined. The designated members served as middlemen, facilitating discussions, taking ownership of certain tasks, and enabling the development team to focus more on feature development without distractions.
The Fantastic Four is highly tailored to our needs but can take multiple configurations based on team structures. For example, the team lead could be a senior developer, and the product owner role could be filled by a project manager. The key takeaway is that the individuals in this group should be those with high stakes in the product. The success of this approach lies in selecting the right people who can bring the most value to the discussions and decision-making processes.
Notably, developers were still involved in refinement and decision-making, but their involvement occurred at a stage when ambiguity was reduced and clarity reached a satisfactory level. This allowed them to work more effectively without the burden of constant rework or unclear requirements.
In most Three Amigos configurations, QAs were often sidelined. By including them as an integral part of the Fantastic Four, we fostered a better culture of collaboration and ownership, setting the stage for deeper integration between quality assurance and development processes.
Better communication improves quality assurance by putting software quality at the center. We should be quality strategists.
— Catalin Bunescu, QA at Newforma
Behavior-Driven Development (BDD)
Given our cultural shift and the improvements brought by initiatives like the Fantastic Four, Behavior-Driven Development (BDD) emerged as the most logical next step in our shift-left transformation. BDD encourages collaboration between developers, QAs, and business stakeholders by focusing on how the system should behave rather than just what needs to be done. By writing test scenarios in a common language understood by all parties, BDD helps prevent misunderstandings and ensures alignment across the team.
For example, a classic user story in BDD might include:
User Story: As a user, I want to reset my password so that I can regain access to my account.
Acceptance Criteria:
- Given I am on the login page, when I click 'Forgot Password', then I should receive an email with a reset link.
- Given I receive the reset email, when I click on the reset link, then I should be directed to the reset password page.
By incorporating BDD, we could ensure everyone, from developers to QAs and stakeholders, had a shared understanding of requirements and expectations. This approach would further build on our cultural improvements by fostering even greater collaboration and a shared sense of ownership over quality.
For example, consider a scenario where the team is refining a feature that allows users to upload profile pictures. Without early QA involvement, developers might assume that any image format is acceptable, only to later discover—during testing—that users frequently try to upload animated GIFs, which aren’t supported. This leads to last-minute discussions and potential rework.
With BDD, since QAs and developers are both involved from the start, they can proactively ask, “What happens if a user tries to upload an unsupported format?” or “Do we need image compression to prevent performance issues?” These questions surface edge cases earlier in refinement, allowing the team to adjust the scope or adapt the design upfront rather than discovering issues late in the process and delaying the release.
To continue pushing the shift-left mentality further, some possibilities include:
- Adopt Kanban with pull policies: Kanban enhances visibility, improves collaboration, and streamlines workflows by enabling continuous feedback, early defect detection, and a focus on delivering smaller, manageable increments that align with quality assurance goals.
- Remove gating: Removing unnecessary approval steps and manual interventions allows for smoother workflow transitions, enabling faster delivery and empowering teams to take ownership of quality while maintaining high standards.
- Stop planning tests, start doing them: Rigid test plans are often inefficient and fail to adapt to evolving project needs. Instead, adopting a more flexible and adaptable testing strategy ensures that quality checks are seamlessly integrated throughout the development cycle, fostering a proactive approach to identifying and addressing issues early.
Shift-Left as a Tailored Initiative
As we tailored our approach to fit our unique team dynamics, we recognized that refining our processes through methodologies such as Behavior-Driven Development (BDD) would be the natural next step. By implementing tailored initiatives, we could further reinforce our commitment to early defect prevention and collaboration across all team roles.
At Nexapp, we approach shift-left initiatives with flexibility, understanding that no single solution fits all projects. As a service and product company, we work with diverse teams, both in-house and co-development teams where we integrate with our clients' existing teams. Each team has its own unique challenges and needs, meaning that the shift-left approach should be a tailored initiative, not a one-size-fits-all solution.
Iterative initiatives and continuous improvement are critical to achieving meaningful change. Identifying and resolving bottlenecks is crucial to fostering collaboration and eliminating constraints hindering efficiency. Some teams at Nexapp do not employ dedicated QAs, relying instead on shared responsibility across all developers for quality assurance and control. In teams without QAs, we found that developers were more proactive about quality, which led to fewer defects in production. This approach works well for us but might not apply to larger organizations with more stringent risk management and Service Level Agreements (SLAs).
Leadership plays a key role in enabling the shift-left transformation. It is important to differentiate between leaders and managers—both are leadership roles with different powers and influences. Leaders inspire and guide teams, fostering collaboration and innovation, while managers focus on structure, processes, and operational efficiency. Both aspects of leadership are necessary to support and empower teams to embrace a culture of shared responsibility and continuous improvement.