A few weeks ago, the Ministry of Testing brought together community members for 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 Jitesh Gosai and Parveen Khan on the panel, for a cosmic discussion about the limitations of shift-left and existing practices. I greatly enjoyed this discussion, and its one I highly recommend giving a listen.

In this blogpost, I will build on some of the limitations I highlighted in the discussion, to make a case for why software testers should expand their approach beyond shift-left, and embrace a more centred testing strategy. .

But, what is shift-left anyway?

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

In this context, activities on “the left” can include, albeit not limited to – testing product ideas, requirements and design specifications 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 a 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 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 may ask, what exactly is the issue with shift-left? To which I would say, read on to find out my thoughts …

The limitations of shift-left

There are several limitations to the shift-left approach, many of which were highlighted on the aforementioned testing planet episode. In this blogpost, I will discuss 5 notable limitations that supports the case I make for why software testers should embrace a centred testing strategy, and they are:

1. Concept clarity: a problem of understanding

Given the nature of diversity in ideas, structures, and context differences you will find in software development, it happens ever so often, that when people talk about concepts like shift-left, it can be unclear what they exactly mean, how it fits in the development process, and how we should implement it.

For some, shift-left, is about shifting testing activities to the left. Yet, for those adhering to this line of reasoning, they may not be clear enough or explicit about what exact testing activities a team should perform on the left to ensure appropriate risk 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 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, I believe, 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 in the first place.

2. Project context dependency: a suitability problem

The idea that context matters is not new, and this also applies to the adoption of shift-left in software development.

In my experience, I have seen that the shift-left approach (for better or worse) can work very well in certain project context. But, not so much in others. It can, therefore, becoming challenging when a team attempt to implement the shift-left approach in an unsuitable context.

Take for example, 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 not yield optimal results. In such context, the shift-left approach may be valuable in helping to clarify the requirements. However, it may not necessarily be enough to respond 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, overtly focusing on the left may take a teams’ attention away from analysing a product’s performance in the hands of the users.

Therefore, to determine the suitability of the shift-left approach in your context, it is crucial to understand your project structure, your team set-up and how responsibilities are defined in your team throughout your entire product lifecycle.

3. Potential bias: a one-sidedness problem

One of the things testing attempt to help with in software development is the 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 testing, 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, responding to error alerts and investigating production issues etc.). Yet, these are valuable feedback mechanisms to gather information about a product. Information that could be vital to a 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 software product delivery is, having confidence that the product will provide the expected value to clients. Thus, 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 or integrate with other systems in its real (live) environment, and how some clients will exactly use the product etc. Some of these 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 that, applying different levels of testing, types of testing and continuous risk analysis is crucial in building confidence in the quality of a product.

That said, to build confidence in the quality of any software product is not that easy. However, effectively evaluating your product through testing, 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 about their product, resolve issues, and adapt quicker, not just on the left, but at every stage of the product lifecycle.

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 can help them gain useful product insights and contribute to quality related discussions very early on. Despite its value, this approach also have the potential to strain and stretch resources in a team.

Think about, for example, a software tester 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 software development, it can end up creating an overload for some people. Especially in teams that are already quite stretched in their staffing resources measured against their workload etc.

To this end, teams adopting the shift-left approach may find it difficult to find a balance between the time demand and the resources available to them for effective implementation of shift-left. Finding that balance can may be crucial to the effectiveness and productivity of the team.

The shift towards alternative practices

From the discussion thus far, 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 inspiration for alternative practices

The Testing Planet Episode Seven: The Community’s Guide to Continuous Quality, could hardly have come at a better time. It appeared to suggest, an awareness of the potential limitations of shift-left by the Ministry of Testings, prompted it 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 these discussions that fosters continuous development in the testing community.

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

It is also, 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 lifecycle with his work on “Quality Engineering“.

All of these sources offers great insights on alternative approaches to shift-left, 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 approaches advocated for by the cited sources can provide a good starting point on how to build and maintain quality, throughout the product lifecycle.

But, what if your approach to shift-left is, or has specifically been about shifting testing to the left? how might these approaches inform your testing strategy? and what rationale might you have to embrace an alternative practice?

The rationale for a centred strategy

To anyone who understands shift-left as a testing focused practice, the centred testing strategy provides a response to the above questions, and that is why I would often say that:

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 software development spectrum, depending on what, and where your attention will best serve your team or product goal, at any given time, throughout the product lifecycle. 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 activities highlighted on each alignment spectrum need to be performed one at a time. Chances are, you will at some point, be performing one or two, or all of them at the same time. A reason why software testing is challenging, whilst concurrently engaging. Because, the goal is to “fight the quality battle at every stage of development”, almost at all times, depending on your context.

This is where the concept of centre alignment in testing comes in, and it is what the centred testing strategy is about.

Centred testing strategy defined

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 continual 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 over shifting-left or right, 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, and similar limitations that may be attributed to a right alignment focused approach.

The centred testing strategy can, among other things, help:

1. Promote ongoing collaboration between developers, testers, and other stakeholders to foster joint approach to product quality.
2. Contribute to Agile and DevOps practices such as continuous integration and continuous deployment, enhancing a teams confidence in their code quality and deployment.
3. Encourage effective use of test automation for quick feedback on the quality of the codebase, allowing teams to detect and address issues promptly.
4. Foster communication and coordination among team members, ensuring everyone is aligned and informed about the test progress throughout the entire development cycle.
5. Incorporate the principles of shift-left, and shift-right into a single consolidated strategy, to create a more balanced approach to testing and quality engineering in general.
6. Distribute testing efforts more evenly across the development lifecycle, thereby helping to avoid bottlenecks, whilst reducing the pressure on testers.
7. Promote a more holistic approach to testing, covering all aspects of the application, including functionality, performance, accessibility, security, and usability etc.
8. Reduce 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. Align testing goals with business objectives, by aligning testing efforts to measurable KPI’s at every stage of the development cycle.
10. Encourage testers to drive quality initiatives, by empowering them to continuously engage and improve on processes across the entire development cycle.

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.

Steps to embrace a centred testing strategy

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 your team, to ensure everyone is on the same page.
4. Experiment: experiment with the centred approach on a small scale, whilst documenting learnings along the way for evidence of progress, before rolling it out to a wider team
5. Inspect and adapt: analyse the feedback from the experimentation, make necessary adjustments, iterate and refine your approach accordingly.

What each of these steps will entail may vary according to your context, but they provide practical actions anyone can take to make a change from a current way of working (i.e. shift-left or shift right) to an alternative approach (i.e. a more centred testing strategy).

Final thoughts!

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

I argued that software 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, such as improved collaboration, enhanced flexibility, balanced workloads, and comprehensive test coverage among others. Consequently, contributing to the delivery of a more reliable and robust software.

Meanwhile, to effectively transition to a centred strategy, I highlighted that assessing the current state, developing a plan, communicating the plan, experimenting, inspecting and adapting the plan are valuable steps testers can take.

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