Shifting Testing Left Bakes In Quality from the Start

“Shift left” is one of the latest buzz terms in software testing. Movements like agile and DevOps recommend that testers shift left, but what does that mean, exactly?

It used to be common to see software development broken down into really clear phases: Analysts would analyze an idea to see if it was viable. Designers would design what it would look like. Developers would build the solution. Then testers would test that it works. Finally, some sort of release engineer would get it out into the wild.

Written down, left to right, it looks like:
Analyze > design > develop > test > release

As you can see, testing is toward the right of the development lifecycle. But modern software development methodologies are shaking up this typical linear construction and asking testing to be done during the analysis, design, and development phases. In other words, testing shifts to the left of where it used to be in the scheme of things.

The theory is that shifting left in this way helps build better software, faster. My own experience brought to light the value of shifting left, almost by accident.

Becoming a Believer in Shifting Left

Our build server had stopped working. It was well and truly dead, and we were told it was going to be out for a week. This meant that none of our developers could deploy any of their work to our staging environment. They could keep coding, but given our process, I couldn’t test anything.

To solve the problem, one of our developers invited me to test the work locally, on his machine. We sat together, and he demonstrated to me the change he’d made. I asked questions about it and requested that he try a few things—exactly as I would if I were testing it in our staging environment.

Guess what? We found a bug!

In our usual situation, this would mean logging a defect, getting the engineer to fix it, redeploying to our staging environment, and starting the process again. But because we were testing locally, we could fix the bug and quickly retest. We didn’t have to go through the ceremony of logging the bug or redeploying to test.

After doing this a few times, we started to realize that this was a much more efficient way to work!

Consequently, even when the build server came back up, we continued the practice of testing locally before we deployed. This caught on, and soon I was doing this with most of the developers on our team.

This is just one example of how testing early is valuable. In this case, pairing up removes a whole lot of additional process. Finding these bugs during development means we take less time to fix them, but in addition to improving the time taken, we also save money, because of course the extra time taken to log a bug and redeploy a fix is a cost to the company.

It’s a great way to work, but it’s not the only way to make shifting left happen.

Testers also can be involved in the other stages of the software development lifecycle, in planning, analysis, and design meetings. By bringing domain knowledge and a critical eye to the table, bugs can be found before any code has even been written.

I was part of a feature launch meeting where, as a team, we looked at a prototype one of our designers had put together. I noticed the layout of the new screen was inconsistent with other similar parts of the product. In my opinion, it was a confusing experience for our users. Being involved at this stage meant I could challenge this design decision early, when it’s much easier (and less time-consuming and costly) to fix.

Michael Bolton has a couple of great blog posts on things testers can do in planning meetings that are worth reading if you’re looking for further inspiration.

Starting the Shift

It’s great to talk about the benefits of shifting left. But it can be difficult to make that shift happen! There are a few things we can do to make this shift easier.

Sometimes testers don’t get included in meetings early in the project. One thing we can do is invite ourselves to things like project kickoffs and design prototyping sessions. It can be scary to invite ourselves to meetings like this—even more so if the meeting is in progress, and we need to knock on the door and ask to join—but the worst thing that will happen is they’ll say no.

However, more than likely, they’ll say yes. Once we’re in, we can start contributing to analysis and design decisions, and our team will start seeing the value of having testers involved at this early stage.

Another valuable tool in the shift-left approach is pair testing with developers. If this is new to an organization, then it requires finding some developers who are open to trying it. If it goes well, hopefully the idea will spread, like it did in my workplace.

One thing that works well when pairing with developers is “rubber ducking,” a technique from The Pragmatic Programmer, by Andrew Hunt and David Thomas. The idea is that a developer explains their code, feature, or suite of tests to a rubber duck (or other inanimate object) sitting at their desk, which requires them to walk through their work step by step. In our case, the tester plays the role of the rubber duck, and the developer talks them through their work. It’s a simple way of breaking the ice whan pair testing.

I do this a lot. Once I start pairing up with a developer a few times, I become accustomed to the way each one works. Then I can start asking questions, prompting, and testing their work. After a while, developers can preempt the things I want to ask them!

It can be really fulfilling when this happens. I sometimes find that I sit down with a developer, they start to show me what they’ve built, and then, without my saying a word, they think of a problem or a case they hadn’t thought of and ask me to come back later!

This leads into one of the key benefits of shifting left: sharing testing skills with other team members.

Shifting Left Benefits Everyone

Testing is a specialist skill. By bringing testing into other areas of the development process, we can demonstrate some of the value of testing, and other roles in our organization can learn how to think like a tester.

When I’m testing changes our front-end developers make, I often ask them about components: “Is this component that you’ve changed used anywhere else in the product?” If the answer is yes, then we need to check that we haven’t regressed that other feature. This kind of thinking spreads!

It’s great when developers take notice. If they’re making changes to a component, they’ll start thinking about its other uses as they’re coding and make the changes more robust as a result. Additionally, once they develop a testing mindset and work this way, it leaves time for the tester in their team to explore more difficult, complicated scenarios.

Shifting testing left is a win for the rest of the team as well as the tester. Bringing testing into the early phases of development makes the whole development process faster and builds a more robust product.

Quality can’t be added to a product late in the game; it needs to be baked in early. It can be hard to accomplish, but by doing things like inviting ourselves to meetings, finding developers to pair with, and sharing our skills with others, we can achieve it—and have much better products as a result.