This is a guest post by Dee Ann Pizzica.
In software development, the sooner you find problems, the cheaper and easier it is to fix them.
I first started to notice this while working on large-scale waterfall projects that employed a traditional V model for requirements, design, implementation, and testing. But even in small organizations, it was easy to fall into the trap of over-designing without getting early feedback.
Later, agile methodologies took over the industry, and teams sought to shorten the feedback loop. This would improve the development experience with a focus on building the right solutions.
Shifting testing left is the next step. This is a change that can be applied to any project management process and can work with both waterfall and agile methods. Let’s look at why shifting testing left is valuable and, most importantly, where you can make adjustments for your team to maximize these practices.
What is shift left?
When looking at traditional models for the software cycle, a project begins and ends in a linear and mostly predictable manner. This is often illustrated with steps moving from left to right:
Identify the problem >> discuss possible solutions >> design the solution >> implement the solution >> test the solution
Testing as the last step in the project makes logical sense; after all, how do you know if the solution solves the problem until you can actually try it out? However, on the other side of that logic, what if you hold off testing until the very end and the team missed the mark? Now it will take months to rewrite a new solution and get the project back on track.
Shift left is the idea that you can move testing earlier in the process. Embedding testing into the early phases of the project shifts the mindset of your teams away from assumptions and turns them all into testers.
The sooner you test, the better your chances of uncovering unknowns and getting it right the first time. Rather than only testing finished deliverable features, as you would in Scrum, you test every aspect of the project.
Why should you shift left?
It is expensive, demoralizing for the team, and a huge risk for your stakeholders to get to the end of a project only to discover you’ve made an egregious error and there’s no easy way to save it.
It’s counterintuitive, but sometimes you have to slow down to go fast. It’s expensive to get all your stakeholders together and to stop and get feedback from multiple sources throughout a project, but it’s far more costly to get it wrong.
Where do you shift left?
When you shift left, you’re changing your mindset to test throughout the project. You need to examine every phase of your process and determine where a tester — or any team member with a tester mindset — can improve your current process. Look for every opportunity to engage in whole-team testing.
Test planning
At the onset of a project, the team is spending time discussing the problem and potential solutions. If you’re not already creating documentation as part of this process, I’d strongly recommend you do so. Even in a successful Scrum organization, user stories are often not enough to get the full picture of a complex project.
As you begin documenting the plans and the notes from these discussions, take the time to test your ideas and assumptions. Incorporate time for team members to not only brainstorm but reread and reflect on the proposed solutions.
Ask detailed questions about how the solution will work:
- Who are all the vital stakeholders for this project?
- What other solutions have we considered, and why would we choose to go in a different direction?
- What are the risks of this solution?
- Are there other tools or products we should evaluate, use, or compare functionality against?
- Are there areas that we don’t fully understand? What is our plan to reduce the risks around unknowns?
While these questions may not feel like testing in a traditional sense, they do push on concepts that are valuable for testers and get your team thinking together about building the right solution.
Kickoff meeting
Before the project begins in earnest, it can be incredibly valuable to gather all of the relevant stakeholders to set expectations for the project. It is important to reiterate goals, timelines, and roles as part of this discussion.
This meeting also presents an opportunity to test what you’ve learned so far. Be prepared to walk through all the current project documentation and ideas. This may seem like an overly time-consuming and wasteful step, but remember that any issues with your solution or unknowns that you can identify now reduce the risk and cost of unearthing them later.
Ensure that the team has time to think through and discuss any questions at this time. Document any follow-ups or action items that may be necessary. These conversations are like early bug reports, and they deserve time and attention. Most of all, dedicate focus to this process. The team should be engaged and fully participating in the discussion.
One caveat: Be sure that team members have time and a process after the kickoff meeting but before code is being written to reflect and question anything in the documentation. This is an important step because not everyone is able to do their best thinking in a crowded room. Make space for your quieter teammates to participate in this process and have their ideas considered.
Developer testing
Embrace approaches to test-driven development when writing user stories to encourage planning for testing as an integral part of the process. Members of the testing and development teams should collaborate to document the tests that will need to be executed as part of completing any piece of work.
The development team should include unit tests as part of the build process to increase code coverage. They can also incorporate automated integration tests as part of the build process in order to catch errors before they make it out of the development team’s hands. Any chance to find errors before they make it into a build will improve your chances of a speedy resolution.
Demos of early prototypes
Another way to shift testing left is to conduct early demos of functionality for various stakeholders to provide feedback. This can happen on several occasions during the process.
The first demo could be of a wireframe. Later, this could be a demo of small, functional pieces that may or may not have a finished UI. Eventually, these demos could be of close to finished features or QA builds of the product.
At each interval, the team can revisit the initial questions for the project: Does the solution solve the proposed project? Is the user going to have a positive experience with this product? Does the solution meet the documented requirements? Feedback at these early intervals will validate that the project is on course to meet goals and objectives.
When should you shift left?
Any opportunity your team takes to shift left is a chance to identify deficiencies sooner. Teams that lead with testing in mind and approach quality as the responsibility of every team member stand a far better chance of developing the right solution to the problem at hand.
Get the right stakeholders in the proper mindset to ask questions early and throughout the project, and your team will be set up for success.
