Forem: Michalina Graczyk

Shift Left Done Right: QA in the Modern SDLC

Michalina Graczyk — Fri, 11 Apr 2025 20:51:56 +0000

Introduction

Someone recently told me this could make for a solid tech talk 🤔. But before I think about that, let me start with the article first.

“Shift Left” is a proactive approach to quality assurance that embeds testing and quality checks early in the software development lifecycle (SDLC). Instead of testing after the fact, the goal is to build quality from the ground up - during planning, design, and development phases.

If you’re wondering how to actually do that across a team or an organization, you’re in the right place. This article breaks down the process, what’s involved, and how you can start shifting left in your own context.

Why Shift Left?

In many companies, QA is treated as a final checkpoint, the last step before release. This leads to bugs being discovered late, expensive fixes, rushed patches, and a general lack of confidence in production quality.

Shifting Left solves this by moving quality ownership to the beginning of the SDLC. It creates space for collaboration, predictability, and shared responsibility, long before the first line of code is written.

Here are some of the benefits:

Catch issues early and reduce post-release bugs
Boost developer confidence in releases
Speed up CI/CD pipelines by removing late-stage bottlenecks
Shift the mindset - quality is everyone’s responsibility

How to Introduce Shift Left in an Organization

Here’s a high-level guide to designing a Shift Left approach that works beyond just your QA team.

1. Map Your Current SDLC and Find the Gaps

Start by mapping how your current development process looks from ideation to release. Where do bugs typically show up? When is QA brought into the picture? How are changes verified?

Look for indicators like:

Testing concentrated only at the end
Manual verification of business flows
Lack of API or integration test coverage
Missing metrics for bugs, flaky tests, or regressions
Refinements without proper edge case consideration

This will help you uncover bottlenecks and missed opportunities for earlier quality gates.

2. Define a Shift Left Version of Your SDLC

Once you know what’s missing, redesign your SDLC by shifting quality checkpoints at each phase:

🧩 Planning & Refinement Phase

QA joins the requirement and design reviews
Define what questions must be asked during the business refinement
Early identification of UI/UX risks
Define acceptance criteria
Define test scope, test cases, and edge cases before development
Propose early metrics for observability
Capture everything in documentation before implementation begins

👩🏽‍💻 Development Phase

Developers start from well-defined requirements
Code reviews include quality and testability checks
Unit tests are written alongside code
CI runs automated tests on every PR
Docs are updated continuously

🧪 Testing Phase

Automated regression and integration tests execute reliably
Manual testing only where needed (complex UX or edge cases)

⚒️ Deployment & Maintenance Phase

Release testing confirms production readiness
Monitoring is set up for performance and usage metrics
Post-release issues inform the feedback loop

As you can see, most of the real quality work happens before the testing phase. That’s the essence of shifting left.

3. Overhaul Your Test Strategy

You can’t Shift Left without rethinking how and where you test. That often includes:

Moving from end-to-end UI tests to API or UI-integration tests with mocked data
Tracking flakiness
Mapping release flows to spot CI issues
Defining clear ownership for test cases and post-release metrics

Test automation should enable your team, not slow it down. You want fast feedback loops, reliable signals, and minimal overhead.

What Success Can Look Like

When done well, Shift Left can radically change how your teams work:

Better Refinements - guided by quality-focused questions, not just deadlines
Docs Before Code - developers know what to build before they start
Early Visibility - teams measure what matters and address risks up front
Faster Releases - less testing at the end means more predictable deployments
Empowered QA - no longer a bottleneck, QA becomes an enabler of quality at every stage

And the biggest win? A shared understanding that quality isn’t owned by QA - it’s owned by the entire team.

Final Thoughts

Implementing Shift Left wasn’t about adding extra process, it was about changing how teams think about quality.

It’s about shifting critical conversations earlier, embedding quality into planning, and treating it as a shared responsibility from day one. It's about thinking from the user’s perspective before a single line of code is written. About building integration-ready, testable software and spotting potential risks early instead of firefighting later.

This approach enables teams to move faster and with more confidence. It reduces waste, clarifies expectations, and creates a culture where quality is designed, not just tested.

Because at the end of the day, quality is everyone’s responsibility 🎀

If you’re thinking about driving a Shift Left transformation in your organization, I’d be happy to talk.

Let’s connect 👇

From Cypress to Playwright - Saleor’s Voyage

Michalina Graczyk — Fri, 29 Nov 2024 11:05:23 +0000

This is the story of our path from our early days of automated testing, to adapting to new tools, and finally to where we stand today with a more robust and efficient testing framework.

Saleor recently migrated our end-to-end test suite from Cypress to Playwright. In this article we share our journey, the challenges we encountered, and how the transition unfolded.

The decision to make the switch from one tool to another is never taken lightly. It needs to be carefully weighed up as it can impact the entire workflow and stability of our projects.

How it started

Let’s take a trip back to 2020. It’s the beginning of the pandemic and I’m diving into adding the first storefront end-to-end tests written in Cypress. Back then, we didn't have a CI/CD setup - GitHub history shows that our deployment workflow was established in 2021.

Why we decided to use Cypress in 2020

Well, one thing was certain, we needed automation. There weren’t many tools to choose between on the market, so the decision was straightforward. Selenium’s ongoing problems with drivers and debugging made it a no-go for us. Cypress was more user-friendly and was on top at the time - the future seemed bright for end-to-end automation.

As the years passed, our QA team grew and we had more and more tests. Around 2022 we decided to upgrade to the paid version of Cypress to use the dashboard (now Cloud). It was a significant improvement for us, finally we could run tests in parallel!

Test results were visible, we did some automation with Github. We are still using bots that tell us if the release has some failed tests or not.

Playwright was on the horizon

As with every successful tech company, we keep an eye on ‘new-tech’ news. Playwright was gaining some attention and I became intrigued by this new tool. I was also a bit hesitant - with PlayWright being a new tool, the community was only just starting to grow. In comparison, Cypress was more mature and well-documented, the community was more established, and we had experience with it.

Even though we had encountered slowdowns and issues with Cypress, I was wary of making a rushed decision to switch test frameworks. Also, who would find the time to rewrite all our Cypress tests to Playwright?!

Day by day, article by article, it became clear that we would eventually need to make the move. We were running tests so frequently and across so many versions that the cost of Cypress Cloud was becoming prohibitive. We tasked one of our QA team members to experiment with PW in their project. Tests ran faster, and a lot of the issues we experienced with Cypress seemed to vanish.

Cypress vs Playwright

Let’s take a look at a comparison between the two:

Test structures

Let’s compare the test structures in Playwright and Cypress.

At first, you can notice that PW uses test to define the test case and expect from its testing library for assertions.

Cypress uses it to define the test case and Chai (expect) for assertions.

As you can see, the test code looks different. Playwright uses a way of writing code called async/await, which is built into JavaScript. Cypress, on the other hand, has its own method for dealing with tasks that happen at different times, so you don't always need async/await. Assertions with PW uses Jest’s library, whereas Cypress uses its built-in assertion library, powered by Chai.

Additionally, Playwright features a built-in auto-wait strategy. If the anticipated checks fail to materialize within the designated timeout, the action is flagged with a TimeoutError, mitigating flakiness. In contrast, Cypress is engineered to wait automatically for elements to be present in the Document Object Model (DOM) prior to executing actions such as clicking or form submission. However, this can extend the test duration.

One of the advantages of PW is iFrame support, Cypress has problems with that which leads to having to do workarounds.

These examples give you an idea of how Cypress and Playwright differ, but there's much more to explore.

Decision and struggling

So, in the middle of 2023, I began discussing the transition to PW with the QA team. We prioritized rewriting the most critical paths first and then tackled less critical but still important tests. During this refactor, we also cleaned up our tests, reducing the number of end-to-end tests in favor of more integration tests.

As of 2024, we're still grappling with some configuration and workflow issues.

Our first challenge was adding new workflows for running Playwright on the main branch, on pull requests and keeping workflows for Cypress since we still support older versions of Saleor. We want to keep posting test results on Slack and receive concise information about whether tests pass or fail on the release pull request.

Currently each pull request trigger the PlayWright tests in parallel. This ensure us that only the most recent changes are tested.

We also created a workflow for a nightly tests which are running three times per week.

Last but no least, we have possibility of running tests via Github Actions. It is possible to run it on selected branch or tag.

We needed to add a Slack notification. We wanted to receive concise information about whether tests pass or fail on the release pull request.

Therefore, when a release pull request is ready, tests are triggered automatically, and the results are sent to TestMo (the tool for test cases and test results that we are using). In case some tests fail, we receive a Slack notification and comments on the release pull request. If all tests pass, then auto-merge should occur.

There is still some work to be done, and we still support Cypress tests for older versions of Saleor.

Summarizing

Saleor's journey from Cypress to Playwright highlights the evolution of our automated testing framework. Starting with Cypress in 2020, we upgraded to the paid version to support parallel testing. However, rising costs and performance issues led us to explore Playwright, which offered faster execution, broader browser support, and finer control over browser interactions.

Despite initial hesitations, we began switching to Playwright in mid-2023. We faced configuration and workflow challenges but implemented new workflows for parallel testing, nightly tests, and GitHub Actions integration. Especially, developers found it easier to dive into Playwright tests compared to Cypress. While initially challenging for our QA team, our tests are now faster, more stable, and better organized.

As of 2024, we still support Cypress for older versions but continue to refine our Playwright-based testing framework for greater efficiency and stability in our CI/CD pipeline. I'm proud of our team for making the switch!