Beyond Shift-Left: 5 Key Reasons Software Testers Should Embrace a Centred Strategy

A few weeks ago, the Ministry of Testing brought together community members on The Testing Planet Episode Seven, to discuss the trend towards “Continuous Quality,” and the limitations of the shift-left approach.

The episode was hosted by the amazing Gwen Diagram, and I had the pleasure of joining the panel, together with Jitesh Gosai and Parveen Khan, for a cosmic discussion about the limitations of shift-left and existing practices. I greatly enjoyed this discussion, and its one I would recommend for anyone who hasn’t already seen it.

Nonetheless, in this article, I will build on some of the key points I made in the discussion, to make a case for why software testers should expand their approach beyond shift-left. Specifically, I will present 5 key limitations of the shift-left approach, which I believe testers can avert by embracing a centred testing strategy.

But, what is shift-left anyway?

Within software testing, shift-left is commonly understood as an approach that encourages teams to include testing and engage testers earlier in the development cycle. In essence, moving testing or other quality focused activities towards the left of the development cycle.

In this context, activities on “the left” can include, albeit not limited to – testing product ideas, requirements and designs etc. While activities on “the right” can include, albeit not limited to – monitoring, evaluating, or testing a product’s performance in a live environment etc.

In nutshell, the shift-left approach comes with a great promise. It can help teams discover defects earlier, which could help reduce the cost of fixing them, as opposed to defects being found much later (the right) in the development cycle.

However, as software delivery becomes increasingly complex with the growth of practices such as Agile and DevOps, there seem to be a growing feeling in the testing community that the shift-left approach is not (none has it really been) enough, to build-in quality or foster a continuous quality mindset in modern software development.

At this point, you are wondering what exactly the issues with the shift-left approach are? To which I would say, read on to find out my thoughts …

The limitations of the shift-left approach

There are several limitations to the shift left approach, many of which were clearly highlighted on the aforementioned testing planet episode. For the purpose of this article, I will discuss 5 notable limitations that supports the case for embracing a centred testing strategy, and they are:

1. Concept clarity: a problem of understanding

Given the nature of diversity in ideas, structures, and context you will find in software development, it is perhaps, not so surprising that when people talk about trending concepts such as shift-left, they may do so in very different terms.

It happens ever so often that when people talk about shift-left, it can be unclear what they exactly mean, how it may fit in our development process, and how we should implement it?

When some talk about shift-left, they refer to shifting testing activities to the left. Yet, it may not be clear or explicit what exact testing activities a team should perform on the left to ensure appropriate risk analysis and test coverage for a given product.

Meanwhile for others, shift-left is about shifting quality related practices (testing being just one of them, including for example design reviews, amigo sections, or peer reviews etc.) to the left, a point Jitesh Gosai clearly highlighted in the aforementioned discussion. This later view may work really well in some cases, for example, in teams where quality is already considered everyone’s business. However, it may not do so well in others.

For this reason, it is important for teams to be clear, explicit and communicative about what shift-left means in their context and what activities in their development processes will help achieve the pre-defined goals for adopting a shift-left approach.

2. Project context dependency: a problem of suitability

The idea that context matters is not new in testing, and this is a point that also applies to the adoption of shift-left. In my experience, I have seen that the shift-left approach (for better or worse) can work very well for certain project context. And, not so much in others, which can create challenges when a team attempt to implement it in an unsuitable context.

In a fast moving environment where requirements and features are constantly changing, earlier contributions from testers to an ambiguous requirement that is bound to change may yield differing results. For example, the shift-left approach may be valuable in such context to help clarify the requirements. However, it may not necessarily be enough to respond quickly and adapt to user needs if focusing on clarifying ambiguous requirements becomes the preoccupation of testers and other quality interested people in the team.

In this sense, a stern focus on the left may take the teams’ attention away from analysing a product’s performance in the hands of the users. To this end, it is crucial to analyse your project context, your team set-up and how responsibility is defined for the various aspects of your development lifecycle when deciding on the suitability of the shift-left approach in your context.

3. Potential bias: a problem of one-sidedness

One of the things testing attempt to help with in software development is aversion of bias in cognitive and product thinking, and I will add – process thinking. However, with the shift-left approach, a teams attention can increasingly become biased to the left, when it focuses solely on performing quality or testing related activities on the left, with little attention to the right.

With the shift left approach, teams may target activities such as code reviews, unit and integration testing very early on. However, some may neglect other types of testing such as functional, performance, accessibility, security, etc. that may be best executed at later stages of development.

Likewise, software testers can become less involved in production related monitoring activities such as reviewing customer feedback, investigating production issues and errors etc., all of which can be a valuable feedback mechanism to gather information about the product they test. Information that could be vital to the team in improving the product’s quality.

For this reason, it is important for testes to remember that in the attempt to help build quality products, while shifting-left is a good place to start, overtly focusing their effort on the left could mean they lose focus on the bigger picture, which could impact their overall contribution to the team.

4. False sense of quality: a confidence fallacy

A huge part of delivering software products, is having confidence that the product will provide the expected value to clients. To this end, software delivery teams test, and put processes in place to help build confidence in the quality of their product. However, with a shift-left approach, teams can develop a false sense of confidence in the quality of their product, when they operate with the assumption that they have built-quality-in, very early on in their cycle (i.e. from the left). With such an assumption, teams may miss out on key insights that can only be gained much later in the development cycle.

Most people in software development would agree that there are some things you may not really be able to learn about your product until later stages of development. For example, how your product will perform in its real (live) environment, or when integrating with other systems in real time, and how some clients will exactly use the product etc. Some of these things you will only get to learn by enacting practices that allows you to evaluate your product at every stages of development.

It is for this reason applying different levels of testing, types of testing and continuous risk analysis is crucial in any attempt to build-in quality throughout the development cycle.

That said, to build confidence in the quality of any software product is not an easy fit. However, effectively testing your product at every level of development is a good starting point. Therefore, it is crucial for testers and teams to implement practices that helps them learn, resolve issues, and adapt quicker, not just on the left, but at every stage of the development cycle.

5. Resource and time demand: a productivity problem

One of the advantages of the shift-left approach, as mentioned earlier, is that, anyone interested in a product’s quality (software testers for example), can contribute very early on by partaking in meetings, and discussions with relevant stakeholders. This helps them gain useful product insights and contribute to quality related decisions very early on.

Despite its value, this approach also have the potential to strain and stretch resources in a team. Think of a tester, for example, working in an Agile team, who is expected to engage in series of feature testing, release testing, writing automated tests, all within a two weeks Agile sprint, whilst participating in all the relevant ceremonies. While this may be the reality of modern day development, it can end up creating an overload for some. Especially in teams that are already quite stretched in their staffing resources measured against their workload etc.

To this end, it is important to find a balance between the time demand and the resources available in a team for effective implementation of the shift-left approach, which may not always be possible for all teams.

—-

Going by the above, it is fair to say that the limitations of solely shifting-left are quite evident. Meanwhile, the testing community has also long believed that any idea to focus quality or testing to the right (i.e. testing in production) is not sufficient.

So, if shifting-right wasn’t enough, and shifting-left isn’t enough now, where do we look then?

You guessed right, but we won’t go there yet. At least not before I share some sources of inspiration for alternative practices.

Some sources of inspiration for alternative practices

The Testing Planet Episode Seven topic: “The Community’s Guide to Continuous Quality” could hardly have come at a better time, as it seems an awareness of the limitations of shift-left, indeed, prompted the Ministry of Testing to instigate the aforesaid community discussion. So, huge credit to the Ministry of Testing for always keeping track on trends in the industry, and for inspiring discussions that fosters continuous development in the community.

As the aforesaid Testing Planet Episode Seven showed, the Continuous Quality idea is currently gaining a lot of attention. A reason why some like Stuart Day, is recently advocating highly for it, and making a case for why we should be “Shifting in ALL Directions” to build quality into products.

It is perhaps, why others like Janet Gregory, and Lisa Crispin are these days talking a lot about “Holistic Testing“, as a valuable approach to weave quality into your product. And why Jitesh Gosai has for some time been driving home his message on the need to build-in quality at every stage of the software development life-cycle with his work on “Quality Engineering“.

All of these sources offers great insights into what the alternative approach to shift-left can be, especially when shift-left is thought of as a quality driven approach. Therefore, for those that takes the whole team approach to quality at heart, the cited resources provides a good starting point on how to build confidence in a product’s quality, throughout the software development cycle.

But what if your approach to shift-left is/ has specifically been about shifting testing to the left? how might these approaches impact your testing strategy?

Well, that is where I would say:

For software testers, instead of focusing on shift-left, or shift-right, it is perhaps, more valuable to “align centre.“

This way, you are able to easily shift to either side of the spectrum, depending on what, and where your attention will best serve your team or product goal, at any given time, throughout your development cycle. For example:

• Left alignment: at the requirement and design stage of a new feature, sprint, or project etc., you may want to focus your attention on learning, and understanding the purpose and objectives of the new feature. So that you can potentially plan, or give early feedback based on your knowledge to those interested in the quality of the product.
• Centre alignment: at the build and feature development stage, you may want to focus your attention on learning about how the feature behaves in the development environment. This way, you can provide performance related feedback to your team as early as possible, especially if there is an observation you consider worth addressing sooner than later.
• Right alignment: at the deployment and delivery stage of the feature, you may want to focus your attention on learning how the feature performs in the hands of those your product serves. Therefore, you monitor, investigate errors, evaluate performance and feedback the information you gather to your team, as quick as possible.

The above is not to say that all those activities need to be done one at a time. Chances are, you will at some point, be doing one or two, or all of them at the same time. A reason why software testing is challenging and engaging. Because, the goal is to “fight the quality battle at every stage of development”, depending on your context. And this is where the concept of centre alignment in testing comes in, and what the centred testing strategy is about.

Towards a centred testing strategy

The Centred testing strategy, is an approach that integrates testing activities throughout the entire software development lifecycle, rather than focusing primarily on the early stages (shift-left) or the later stages (shift-right).

This strategy lends itself to continuous quality by emphasising continuous testing and collaboration among all team members, as a means of increasing the product feedback loop, ensuring quality is built-in and maintained at every step of the development cycle.

There are several benefits to embracing this approach instead of the earlier discussed shift-left, some of which I highlight below.

The benefits of a centred testing strategy

The most notable benefit of a centred testing approach is the potential to help avert the limitations of shift-left discussed above. Because, it can among other things help in:

1. Promoting ongoing collaboration between developers, testers, and other stakeholders to foster joint approach to product quality.
2. Contributing to Agile and DevOps practices such as continuous integration and continuous deployment, enhancing a teams confidence in their code quality and deployment.
3. Encouraging effective use of test automation for quick feedback on the quality of the codebase, allowing teams to detect and address issues promptly.
4. Fostering communication and coordination among team members, ensuring everyone is aligned and informed about the testing progress throughout the entire development cycle.
5. Incorporating the principles of shift-left, and shift-right to create a more balanced approach to testing and quality engineering in general.
6. Distributing testing efforts more evenly across the development lifecycle, thereby helping to avoid bottlenecks and reduces the pressure on testers.
7. Promoting a more holistic approach to testing, covering all aspects of the application, including functionality, performance, security, and usability etc.
8. Reducing the risk of undetected issues, by promoting comprehensive risk analysis and test coverage throughout the development cycle, leading to more reliable and robust software.
9. Aligning testing goals with business objectives, by aligning testing efforts to measurable KPI’s at every stage of the development cycle.
10. Encouraging testers to drive quality initiatives by empowering them to continuously engage and improve processes across the entire development cycle rather than focusing only on test execution

In a nutshell, with the adoption of a centred testing strategy, testers are better placed to help their teams deliver high-quality software, improve processes, and foster collaboration across teams. That said, implementing the approach may not be as simple in real time as one may wish. However, there are some simple steps I believe testers can take to make it happen, which I now turn to.

Embracing a centred strategy: some transition steps

1. Assess: start by assessing your current testing practices, and identifying areas for improvement, especially where testing activities are biased either to the left or to the right.
2. Plan: develop a detailed plan for transitioning to a centred strategy, including timelines, resources, and key milestones that will signal progress.
3. Communicate: provide a detailed explanation to your team on the principles and practices of a centred strategy, why it may be desirable and feasible to implement in the team, to ensure everyone is on the same page.
4. Experiment: experiment with the new centred approach on a small scale before rolling it out to a wider team, whilst documenting learnings along the way.
5. Inspect and adapt: analyse the feedback from the experimentation, make necessary adjustments, and iterate on the process to refine your approach.

What each of these steps will entail may vary according to your context, but they provide practical actions anyone can take to embrace a more centred testing strategy as an alternative to shift-left or shift-right.

Final thoughts!

I have so far shown that while the shift-left approach can significantly improve early defect detection and overall software quality, it comes with limitations.

Consequently, I argued that testers are better served embracing a centred testing strategy. By so doing, they can overcome the limitations of shift-left and achieve even greater benefits. Additionally, a centred approach can help foster improved collaboration, enhanced flexibility, balanced workloads, and comprehensive test coverage among others, leading to more reliable and robust software.

To embrace the centred testing strategy, I outlined key steps testers can take to effectively transition from a shift-left mindset to a centred strategy, ensuring continuous quality and better product quality outcomes.

To conclude, I believe the discussion above provides good reasons for why testers should now think beyond shift-left or shift-right, and embrace a centred testing strategy, as an holistic and more effective approach to software testing.