In an Agile world, teams are being asked to move faster — reducing the length of time to delivery while still continuing to improve the quality of each release. At the same time, they are faced with increased pressure to reduce testing costs.
This Agile approach means that different testers, with vastly different skillsets, are getting involved in the testing process. More specifically, it means that developers are being incorporated into the testing cycle earlier than ever before.
This movement in the testing world is commonly known as “shifting left”.
What Does it Mean to Shift Left?
In the past, where a majority of software teams approached work with a waterfall model, the workflow looked something like this example from Winston Royce's "Managing The Development of Large Software Systems", first published in 1976.
In this model, a typical project may look something like this:
Figure 2. Implementation steps to develop a large computer program for delivery to a customer
The product people disappear and go talk with customers. Eventually they emerge with a specification, requirements, a roadmap, perhaps a few user stories. After that, a short meeting happens where developers talk through the new features, assign tasks, and then everyone is off to work. When testers are mixed into that, it's usually to sit in on planning sessions, or maybe to give estimates for how long they will need to test the new code.
Most projects, even with agile teams, feel like testing is the last step in the process. We happily get development collaborating with product folks early in the process and build the product in smaller bits, but testing early is a struggle. Squeezing testing in at the end creates problems. The biggest problem is that testing becomes somewhat of a bottleneck for teams as they attempt to move faster. That last week isn’t a test week. It is a find problems, spend time researching and reporting, getting new builds (that hopefully worked), and retest week. Testing is only the bottle neck when people ignore everything else that happened at the same time. In most companies, this is just the way things have always been done.
Suggesting that testing shouldn't be held until the last few days before a release is the easiest way of explaining the ideas in the phrase 'shift left'. In some teams, testing is involved from the very start. Testers join design sessions to ask questions about how customers work, which ultimately leads to design changes. Some team members can work closely with back-end developers to ask questions and create test ideas and 'what if' type scenarios. Others sit down with the API developers and stub out tests for new services while they were being developed. And yet others find themselves pairing up with the UI and API developers to test something new on their machine before it hit a build.
Testing may still happen at the end, but it will be smaller and faster because of the problems you are able to find earlier on. Shift left doesn't exactly move testing closer to the beginning of a release cycle. It sprinkles it over each step and each iteration.
Is 'Shift Left' A New Idea?
In the 1950's, programmers knew that it was better to start testing earlier, and did just that. There were no dedicated testers at the time. Questioning and testing happened by the same people that wrote the code, and it happened all through the project. It was an unfortunate misunderstanding of the waterfall model that got us the independent test teams and time lag between dev and test we have today. Even though the idea of making test happen much earlier isn't new, having a phrase has restarted an important conversation.
What does work really look like when we inject testing into all parts of a project?
There tends to be a lot of waiting involved in testing work. In the beginning, people are waiting on requirements, and then on the new builds with new features, and then on development to be 'done' so the test team can start regression testing. A lot of time is either idle, or trying to find ways to avoid looking idle. That changes drastically when testing developers are incorporated earlier in the testing process.
As a member of an integrated team, a tester’s regular cadence looks a lot more like a developer’s day. They can start going to design sessions with developers. Even though someone might not have deep programming skill, and never had familiarity with the product code base, there are places to add testerly value. Imagine a project focused on building a wizard to help build advertising campaigns. Data is grouped together into pages, and a Next button is clicked to get to the next step in the wizard. That Next button is really tricky. There are required fields for each step, validation for other fields, and potential for data loss. Working through a series of questions on how marketing people build ads might lead the team to a much better design before the software even exists.
If there is an API, a tester with at least a little bit of technical leaning could write some basic checks and test ideas very early in the development cycle. On a good day, service tests could be up and running in the build right after that service was ready. Some testers are able to perform most data testing — data length, character types, data format — what is often called domain testing, with tools and a few lines of code. By the time the back end and the service layer are hooked up to a user interface and there is some resemblance a final product, all that is left to do is looking for workflow, layout, and UI problems.
Having a team test earlier helps them to get more comfortable with tooling and technology. Ideally, software is delivered in testable increments. But, those increments aren't always in the shape of something displayed in Google Chrome. Being able to work with API tools, look at processed on a server, or walk through code with some help, becomes a required skill. Without that, testing gets stuck right where we started. At the end.
Daily life for managers can take a sharp curve, too.
People get some weird ideas about managing testing when it gets cut out of the development pie. Managers try to get a gauge on tester performance by measuring things like bug count, and the number of tests run in a day. And the development team somehow starts thinking that running out of documented tests means that we are getting closer to a release. When teams help testing happen earlier, those things just sort of go away.
Start out with a blank page and write production code and tests to run with the build in parallel, or work together on testing and fixing problems in rapid fire. Hopefully, at the end of a pairing session the feature is pretty close to done. It is at least good enough at that point to go through a demo for the team. Parts of the process that needed a manager — especially collecting information about test velocity, triaging bugs, and getting status on features — go away at that point. Who needs bug reports and test cases when you can just do the work? This can be a challenge for the traditional test manager that spends their days reporting status, finding out who is blocked, and collecting metrics. Shifting testing left, might just shift test management out or into new roles.
It's easy to take ideas like this, and tell people "All you need to do is blow up your team structure, recreate them in small groups, shift some people into new roles, start delivering one feature at a time, and presto” But, things are rarely that simple, especially when someone tells you they are.
How to Get Started with Shifting Left
Here's where to start. Pick one small team, and have a tester work with the rest on a feature from the very beginning. This should include everyone from the developer to the product manager and business analyst. That team goes to meetings together, reviews code together, tests together, and decides when that feature is done. Behavior-driven development is a separate methodology that can accelerate your shift left movement. It is a process that facilitates better cross-team collaboraiton by enabling everyone on the same team, from testers to product owners, to work together on an application via a shared and easy-to-read language, Gherkin.
Whether or not you choose to implement a process like BDD, one of the most critical components of your shift left efforts should be the automated testing tool you adpot. Testing earlier and faster is nearly impossible without automation and depending on how far along you are in your DevOps or agile journey, you may already have an entire network of continuous integration and delivery tools like Jenkins, source control management systems like Git or Mercurial, or even defect tracking systems like Jira. If you do, or are starting to build out this product portfolio, it will be important to pick a testing tool with an open architecture that can integrate or work seamlessly with your existing development infrastructure. Your testing tool shouldn't be a bottleneck in your process.
TestLeft is an automated testing tool that enables teams looking to shift left, to run UI tests from within the IDE of their choice, whether it's Visual Studio, Eclipse, or IntelliJ IDEA. This will allow developers to build and run tests quickly and easily from their comfort zone. The tool also supports testing in shifting left by integrating with CI/CD tools, as well as those looking to implement BDD through its integrations with BDD frameworks like Cucumber, SpecFlow and JBehave. With TestLeft, you can translate requirements written in Gherkin into automated test steps in just a matter of clicks.
Once your team has met a few times, you'll have some experiences to talk about and probably a few things you want to change. If things go south, you only had one team slowed down. If it worked great, you have a success story to share.
Shifting left isn't just a cute slogan. It is a way to design teams and organize work to make use of the skill you already have.