What’s Shift-Left & How to Really Do It (Part II)

Last time, I’ve gone over how we got to the Shift-Left of today. Developers doing testing, who knew? Well, everybody.

Before we jump into how to do it properly, I want to mention that Shift-Left is not the goal by itself. Beware of confusing the goal with the tool.

Also, the goal is not to reduce the QA budget. Again, some people think that shift-left will directly result in reducing the QA workforce. They may succeed but that’s very risky.

I can see the allure, but let’s define what the real goal is. We want to deliver sustainably. If possible, deliver more sustainably. The sustainable part, is not just about the team – sustainable pace, morale, etc. In terms of quality, that means we want to deliver at the same quality, and hopefully improve it.

As you can see, this immediately clashes with the budget issue. If you cut off all of your testing force, you’re left with developers who don’t know how to test, and usually don’t have the motivation to do so.

Telling developers that it’s their job now to test their code, in most cases is perceived by the devs as more tedious work. In most development, it is already late, the code was written, and is full of bugs. With that, that “extra work” would be pushed to later, sometimes never done. You may get the budget benefits, but quality will suffer.

As we’ve seen, there is benefit, of course, to developers testing their code. When they do, the code the testers get has less bugs, there are less wasteful “it’s not ready yet, fix it” rounds, and with time, that frees tester time to do more exploration, which results in better quality.

Shift-Left in Practice

So how do we bridge this gap?

This calls for a holistic solution. We love those don’t we? It’s the ones that are really hard to implement.

Because it’s not “devs got new tasks to do”. It requires understanding, sponsorship and management at the organization level, at the team level, and the code itself.

• Org level
  • Understanding – This includes investigating the whole end-to-end quality of products that are handed off. Understanding the clarity of requirements and quality expectations.
  • Communication – Making sure that the quality and risk expectations are communicated clearly.
  • Define the important quality processes – code reviews, test reviews, knowledge sharing, and track the process of implementation.
  • Reporting – measure and report the quality metrics at the organization level, and translating them into the team’s level.
  • Motivation – Explain why quality tasks are part of development. That includes testing, refactoring, code reviews – any process that impacts quality and we want to push.
  • Building a community of experts – as teams start to experience the new methodology, they will have questions, and others will have answers. Create the community where examples, patterns and war stories can be shared. Assign places, and reporting mechanisms to make sure this happens consistently.
• Team level
  • Run pilot programs on each of the the items we want to improve. Assign motivated developers to these teams. They will later be the ambassadors for the rest of the organization.
  • Define quality criteria for each feature in the program. Developers need to know what is expected of them. “Write unit tests” is not enough.
  • Collaboration with the test team. If the testers are embedded in the team, even better. Planning together on what is expected at the end of the sprint, what is going to be demoed, and what kind of automation, is better discussed beforehand, and be part of the “definition of done” for the feature.
  • Pairing testers and developers allows transferring the needed skills, like test planning and design. Discussion on division of testing allows for the right people to do their most effective work, while still dispersing knowledge, in both ways.
  • Measure, track and report important metrics. Coverage is nice, but does not give you much to work on. Coverage of new features is better. Case coverage (rather than code coverage) is times more effective (but it is manual, and requires more work).
  • Define design guidance for architecture – where code should be broken to smaller modules, what boundaries we need to keep in tact, and where not to touch.
  • Explain how the metrics relate to quality (if you can’t convince the people, you’ve already lost).
  • Document the learning to support the knowledge sharing process.
• Code
  • Teach the proper skills and tools- unit testing, planning, refactoring, testability, design patterns, clean code etc.
  • Map important areas in the code where testability needs to improve. This can be new feature code, buggy code, central code – everywhere we want to increase quality.
  • Write tests and integrate in CI
  • Review tests and code
  • Refactor for testability.

And that’s all.

Just kidding. That’s just the beginning. It’s an iterative process of experimentation, learning and teaching. And it’s a huge undertaking.

Shift-left is a nice slogan. “Developers writing tests instead of QA” sounds efficient. But it hides a huge change of organizational behavior, if you actually want the changes to stick.

And if you want help with these, let me know. I can help.