As a former member of the U.S. Women’s National Softball Team and a lifelong softball and baseball fanatic, I’ve always been fascinated by the shift. In softball and baseball, the shift refers to when infielders move away from their traditional positions (i.e., spread out evenly across the diamond) and instead bunch together on one side of the field, owing to a batter’s propensity to hit the ball in that direction. In the span of just a few short years, the shift went from a rogue concept implemented by a progressive few to a standard practice backed by indisputable data and used by everyone in the game.
 
Still, its widespread usage notwithstanding, if a fielder isn’t comfortable playing outside her comfort zone or the pitcher makes it too easy for the hitter to exploit the vacated side of the infield, the benefits of the shift go out the window. To execute it properly, everyone has to be on the same page.
 
I often think of shift-left testing in much the same way. (Hey, you can take the woman out of softball, but you can’t take softball out of the woman.) Even just a few years back, shift-left testing was something of a rogue concept, embraced by only the most forward-thinking development teams. Now, the notion of shifting testing left and implementing it earlier in the development process is seen as an industry-standard best practice.
 
Development teams that shift testing left discover bugs earlier, enhance developer productivity, and increase release velocity by avoiding the long and costly delays that occur when bugs are discovered at the end of the development cycle. Shifting left creates faster feedback loops and allows for faster bug remediation. It also enables teams to integrate more types of testing earlier in the pipeline and run a variety of functional, visual, and performance tests. In other words, the case for shift-left is pretty much airtight at this point. 
 
Just as with the shift in softball, however, everyone has to be comfortable and on the same page for shift-left testing to work. The same way the shift in softball won’t work if infielders aren’t comfortable straying from their traditional posts, shift-left testing won’t work unless developers take more ownership for testing and shoulder more responsibility for code quality, especially in the early stages of development.
 
There’s only one problem: most developers have no interest in testing.
 
Developers and Testing
 
Here’s what we know for sure about developers: they’re not testers, and that’s not an accident. Developers want to code, innovate, and build great technology and avoid anything that gets in the way. In the minds of many developers, that includes testing. Despite our collective desire to shift-left, many developers are still hesitant to incorporate more testing into their process. That’s not because they don’t like testing, but rather it’s because they believe it will slow them down— and considering how many organizations still rely on dated, QA-driven, manual testing strategies, it’s hard to fault them for thinking that way.
 
We cannot simply force developers to test. Neither human nature nor software development work that way. Instead, we, as testers, have to take initiative. The responsibility is ours—not theirs. We have to find creative and thoughtful ways to foster increased collaboration. We have to find more and better ways to make it as easy as possible for developers to embrace testing.
 
Here are three great ways to do just that.
 
1. Provide the Tools Developers Want

 
Like anyone else, developers want to work with their preferred tools—the tools with which they’re comfortable and feel they can be most productive. Those tools are often different from the tools traditionally used by testers and QA teams. As testers, if we want developers to more readily embrace testing, it’s time we started meeting them where they are with the tools they want to use.
 
Now, that doesn’t mean we have to suddenly abandon our investments in Selenium, Appium, and WebDriverIO. But it does mean being more open to adopting the native testing frameworks that developers tend to prefer, such as Cypress, TestCafe, Puppeteer, and Playwright. Remember, developers are the ones being asked to take on additional responsibilities. The least we can do is create a comfortable environment within which they can do so.
 
2. Break Down Silos—Including Your Own

 
We can’t expect developers (or anyone else in the organization) to embrace testing unless we can first break down the traditional silos and processes that have essentially kept testers as individuals and testing and QA as a function isolated from the other core teams and components that make up the software development process. We can’t expect developers to embrace testing if we don’t allow them to work alongside testers.
 
That’s not to say we should completely blur the lines between development and testing. Even in the world of DevOps and agile development, those can and still should be separate roles and perhaps even separate functions. But we have to be more integrative in both our thought process and ultimately our actions.
 
We can start by doing away with the dated notion that developers sit over here and write code, and the QA team sits over here and waits until the end of the delivery cycle to test that code. Instead, it’s time for organizations large and small to consider adopting the “squad” approach in which testers are integrated directly into development teams and work right alongside developers from the word go. This enables testers and developers to collaborate, share best practices, and work together to deliver quality customer experiences without stepping on each other’s toes. Instead of focusing on who owns what, this more integrative approach enables teams to focus on unifying all quality signals such that everyone understands the health of the application, regardless of who is doing the testing.
 
3. Create a Culture of Quality

 
Why should developers embrace testing if they ultimately have little say in how the organization defines quality? And why should they care about quality if no one else in the organization does? If we want developers to more readily embrace testing, we have to create a culture of quality and empowerment.
 
In many organizations today, quality is still defined solely by the QA team. Too often, developers have little say in determining what quality looks like. So, here we are asking developers to get more involved with testing while offering them no input into how the organization defines quality—and acting surprised when they show little interest. What are we expecting?
 
If we want developers to embrace testing, then we have to give them a bigger say in defining quality and more input into the steps needed to ensure it. But even that’s not enough. If we want our developers to be truly invested—emotionally—in quality, then we have to ask the same of everyone in the organization. Everyone has to buy-in. Everyone has to take ownership of quality, and for that to happen, we have to create a culture in which everyone in the company, regardless of department, role, seniority, or technical acumen, has agency to speak up and drive improvements to quality if and when the opportunity presents itself.
 
Expect Challenges
 
At the end of the day, we’re collectively trying to spur a paradigm shift—a complete and total reimagining of the way we think about the role of developers and the concept of quality. As with any shift of this nature, fighting resistance and overcoming hurdles is the norm. But if you can overcome them—if you can arm developers with the tools they want, break down the silos that hold them back, and create a culture of quality that everyone can embrace—the rewards are many.