Dabbagh Bits

So, you want to shift quality left?

Dabbagh Bits -

The term "shift left" has gained steam in the software industry and has started to resonate with many organizations. "Shift left" means moving quality-related activities earlier in the SDLC. Effectively, this should help identify issues earlier, speed up testing, and deliver quality products faster.

Notice how we didn't say "testing activities" but rather "quality-related activities"? That's intentional.

What "Shift Left" Is Not ❌

There is a misunderstanding as to what this term means. We get too excited and make assumptions that are not realistic or productive for the team. Before we dive into what it means, let's understand what it's not.

Shifting left is all about testing

While yes shifting left is often associated with moving testing activities earlier in our process, that's often not enough. Achieving a quality product requires the whole team, which means peeking at our process, people, and technology.

For example, having clear Acceptance Criteria from the beginning will help the team deliver faster and avoid confusion and issues downstream. In this case, we'd be tweaking our requirements-gathering process, how we write story Acceptance Criteria, and our Definition of Ready.

QA is now just automation

While automated testing is essential for Agile delivery, it complements all the other activities required to ensure quality. The benefits of automated testing shine during regression testing. Automation helps with quick feedback and to reduce testing time.

Yes, you'll need automation to shift left. But knowing what to test, how to test it, assessing risk, teaming, and many other activities are also needed. There will always be a human touch to testing and quality in some shape or form.

Testing is done when development is complete

In traditional working methods, all testing was considered and performed after development was completed. This was time-consuming and tedious, and issues were caught too late.

Yes, spreading testing across the SDLC is helpful. Incremental testing is good. But forcefully shifting all activities to the left is incorrect and unrealistic. We must stop assuming a feature/story is ready once development is done. Testing happens as the product is built but also sometimes after. There is a benefit to testing once the code is frozen and validating the finished pieces together.

💡
Shifting left is about spreading quality-related activities throughout the SDLC, Agile delivery, and across roles.

The end of the QA role

Just because quality activities are spread across the SDLC doesn't mean we can eliminate the Quality Assurance role. We still need someone focused primarily on quality and championing it across the team and organization.

There are many benefits to having a QA role on the team, including acting as the glue for the team, having a technical and end-user perspective, and more. You'd be surprised what a great Quality Engineer can do. Read all about it in my post about The Complete Quality Engineer.

An independent initiative

Some organizations try to shift quality left or modernize their quality and testing activities solely through their QA teams or a small group of motivated folks, only to face constant frustration and confusion.

The idea of "shift left" needs to be understood and prioritized, just like tech debt. It usually takes time and effort away from delivering business-specific requirements. It could mean new ways of working, new tools, new responsibilities across the team, and more. The entire organization must be on board across all capabilities (Product, Marketing, etc.).

Let's Shift Left ✅

Right, it's time to put shift-left into practice. The key is understanding it's tightly coupled to our delivery methodology (Agile being the most prevalent) and the SDLC.

These are not all the factors to consider when shifting left, but we highlight the most prevalent and high-impact items from experience.

Embed quality into every step of your delivery methodology and SDLC

This is the key to shifting quality left. Don't worry about the roles and who's doing what. Involve the right folks in the conversation, start combing through your entire delivery and SDLC process, and see where quality and testing fit at each stage.

Having said that, be careful not to over-complicate your processes. As a matter of fact, make sure to remove outdated or inefficient practices where it makes sense. Use this time to your advantage.

Some examples of embedding quality could be:

  • Technical designs are reviewed before sprint planning
  • Unit tests are part of the definition of done for a Developer
  • Automated tests must pass before the code is merged
  • Communication of changes to dependent teams on time
  • UI designs are reviewed before sprint planning
  • Data schema review part of the definition of done
  • Testing a story occurs in the same sprint – stories can't be closed until testing is complete

Make incremental changes

The chances that all changes will be implemented in one go and succeed are slim to none. You'd be doing yourself and your team a disservice by trying this hail-marry. Change is hard, you know that.

Instead, treat it like a project and many mini-experiments. Prioritize all the changes according to impact, team readiness, and effort. Then, implement some changes, wait for a period of time to gauge how it's going, collect feedback, and iterate. Then, only when the team is happy with the changes, and there is some stability for a period of time can we start implementing other changes.

Involve Quality Engineers early

When the Product team is gathering and defining requirements, they usually tap Software Engineering, and if a UI is required, the Design team too. It's time to add QE to this group. QA should no longer be at the end of the pipeline if you'd like to shift quality left.

Quality Engineers are usually very knowledgeable about the product and its intricacies (including shortcomings), have a technical and end-user focus, and can provide valuable input during the requirement-gathering phase. They can bridge the gaps between technical and product teams to shape great ACs.

In addition, the earlier quality engineering is involved, the more time they'll have to consider quality, risks, test cases, and automation.

Your ACs are your source of truth

One of the biggest complaints about the old ways of working is the disconnect between Product, Quality Engineers and Software Engineers regarding requirements. The SE is not sure what the QE will test, both have made assumptions about ACs, and Product is busy working on the next set of requirements. Queue debates about AC interpretations, expected functionality, and scope.

To avoid all this, your story Acceptance Criteria must be your team's source of truth. Any disputes or uncertainties should be routed through the Product Manager or Owner and updated in the story (or a new story/defect is created). See why involving QE in requirement gathering is important?

Consider and document risks early

Consider and document risks as early as possible as you think about including quality in each step of your team's delivery and SDCL process. These can be technical, teaming, dependency-related, or anything that could hinder the delivery of work.

When considering risk (and I mean really consider it, as in putting in the effort), you automatically factor in quality and testing activities. You anticipate problems and come up with solutions ahead of time.

No one likes unanticipated problems. While you can't avoid them entirely, you can prepare for them as much as possible. Otherwise, you'll waste time coming up with solutions on the fly and could be in a time crunch. The stress is not worth it. Plus, you could choose the wrong solution because you didn't have time to pivot properly.

Automated testing is key

To shift left, we must test more efficiently and provide feedback quickly. This is where automated testing comes into play.

One misunderstood point is that automated testing will help when testing new features. While it can in some cases, oftentimes, it's not easy. The benefit of automation usually comes from regression testing. Ensuring something we built before is still working as expected today. Another challenge is having too much automation. This can happen, resulting in a lot of time updating, maintaining, and fixing tests. Find the right balance.

While we're on the subject, automated testing without CI/CD is almost useless. Your automation needs to be part of your build and deployment process. It should be triggered automatically at the right time and within the right environment. It should also be gating some deployments or downstream processes.

Reduce test case documentation

This is specific to the QA team, but I lived it and seen it at too many organizations to warrant a shoutout. Writing detailed test cases and explaining every step is not efficient or useful. The team will spend more time updating test cases or writing them than testing the product or focusing on quality. And they will quickly become outdated and hard to manage, guaranteed, unless you have some clever way of turning ACs into test cases (assuming your ACs are perfect).

This relates to the point about ACs being the source of truth. I understand the benefits of having dedicated test cases. Each team and organization is different. But make sure you are solving for the disconnect between ACs and test cases and the current state of the product, and find a balance of what good enough means without being too process-heavy.

Here's a method that worked for me before:

  • Relentlessly focus on making story ACs the source of truth.
  • Once we're done testing the story, move those test cases to our test case management system.
  • When writing the test cases, focus on the title. Only add details to the test case if there are complex setup/execution instructions that are hard to remember.

If you're looking for inspiration, here's a post about the challenges of test cases and how to write easy-to-follow and effective test cases.

I've been part of many backlog refinements, sprint plannings, project proposals and whatnot where testing and quality activities were not considered as part of the estimates. What happens? Surprise Pikachu face when a feature isn't "done on time", or the QE team is pressured to rush ("QE is a bottleneck"), unit tests are skipped, and more shocked faces when quality is low at the end.

You should always estimate quality-related activities. That applies to all roles, not just QA. Unit tests, for example, should be considered when estimating a story. When you have complete estimates, you set expectations, avoid confusion, and promote predictability.

Final Thoughts

Shifting quality left will require effort from multiple fronts. But when done right and with the right people and tools, it can reap massive benefits for any team. The return on investment will be worth it for your productivity, quality, team's happiness, and organization's pocket.