My boss sent round this article written in September 2017 from TechTarget about embracing shift-left testing as “the latest theory”. The reason he sent it around was not because we should look into adopting it, but because we’ve been doing it – and I checked – since 2008. “Sounds familiar” he quipped.
“Shift left”? Bleurgh!
Firstly, let’s address the term “shift left”. I’ve used the term for a while to explain how we test, but recent Twitter noises make it more clear that the term is limited.
It suggests movement in one direction. Put like that, I don’t think that’s what we really mean. We’re not suggesting that, in order to start getting involved earlier in the lifecycle that we stop doing testing at the end, are we? What we’re really doing is expanding the range of activities that testers get involved in.
“Left” leads to “right”, which suggests a one-dimensional reality in which your options are severely limited. Modern organisations are multi-dimensional, so why limit ourselves to a single direction in a single dimension? Are the activities that occur notionally to the left of testing in the software development lifecycle the only things we can usefully get involved with?
“Shift left” is about getting testing involved earlier in the software lifecycle so we can try and stop bugs even being written. Broadly, it’s about adding value sooner rather than later. But, again, why limit ourselves to adding value? Why not look in the other direction – towards operations – and see if we can extract value to make our testing better in the future?
But wait, I hear you cry. If we’re expanding, surely we’re spreading ourselves more thinly, and doing less testing at the end? That may be the case, but the idea is that, by getting involved sooner and identifying problems earlier, an hour spent early in the release should save you many times that late in the day. It’s an investment that you hope pays off as fewer bugs and regressions.
As I typed this, Dan Ashby‘s surely-famous-by-now image popped into my brain. You can test everywhere, not just a bit more to the left.
So instead of “shift left” I’m going to call it “expand outwards”. It doesn’t suggest that you have to give up anything, and it’s direction-agnostic. You can expand in any direction that lets you add or extract value.
What does “expanding outwards” look like?
We’ve been expanding testing outwards ever since we adopted agile-like behaviours. As a company, we embraced Agile methodologies as an R&D operation. Importantly, I had the freedom to come up with a test process from scratch that would allow testers to get involved from the earliest possible point in the release.
Initially, we did just expand in one direction; “left”, i.e into development, design, and requirements. We got involved in design and estimation meetings, we reviewed requirements and user stories, and we got developers to review our test ideas.
Over time, we looked to expand in other directions; firstly to the “right” and Customer Support. As the people who work closely with the customer and who support the products in live usage, they are the role who know the most about real-world customer usage of the products. They are a vital resource to get involved if you can. We “shifted them left” into testing so that they could add value to us.
We also get involved with testing documentation, and tech authors share our test environments where possible.
Those are just some examples. We didn’t stop there, and neither should you. Remove your filters and think about everyone even loosely associated with the product, which probably means everyone in the business, and includes your customers. Think about what value you can give to, or extract from, each / any / all of them.
Let’s step back; what are we trying to do?
When we first looked to adopt Agile, we spoke to a consultant who probably said lots of words, but two have stuck with me ever since;
accelerate failure
Put another way, if you know you’re going to make mistakes – which you will, because you’re a human being – then do everything you can to make them, or identify them, as early as possible so it’s as cheap as possible to fix them.
We need to accelerate not just the failure, but the remediation loop as well. The goal has to be that errors spend as little time in the system as possible, whether they be requirements ambiguities, or code defects, or whatever. The longer an error remains in the system, the more it becomes cemented in, compounded upon, worked around, and expensive to remove.
“You mustn’t be afraid to dream a little bigger”
What we’re really trying to achieve is the acceleration of failure across the entire software development lifecycle, not just testing. We can expand testing outwards to try and find problems sooner, but if the rest of the operation doesn’t follow suit, or inhibits your ability to do testing in different places, then you will encounter a glass bubble beyond which you cannot add or extract value.
Adoption of accelerated failure needs to be systemic, not piecemeal, affecting only a single role. In order to realise all the value of accelerated failure, everyone needs to do it, or at the very least accommodate it.
The hardest part of this whole acceleration of failure business is overcoming any cultural momentum around who does what and when. An agile (in the small, nimble sense) company, with fewer organisational and physical boundaries between roles / projects, will be able to change direction more easily than a larger, distributed, older organisation whose culture is probably more rigid.
Even in a small organisation, it’s not straightforward. From experience, the hardest part can be getting other roles to allow testing to be part of the conversation. This is probably due to perception issues around what testers do more than anything else. Again, from experience, testers working closely with developers quickly erodes those concerns as the value testers add becomes more evident.
How do I Accelerate Failure?
Think about the roles you interact with regularly. They are likely people involved in the software development process. Learn as much as you can about how they operate and what they do. Pair with them, read their process docs if they have them. Figure out what info they have that you can use, and vice versa.
Encourage them to reciprocate and to remove any barriers. There should be no reason for barriers to sharing of information that ultimately benefits the business and the customer. Everyone in the business is there to provide, or support the provision of, products to the customers.
Then expand your focus to other roles, and repeat. Ignore organisational hierarchies and chains of command. Knock on doors, cold-email people. Walk about and have coffee.
You’re a tester; a sponge for knowledge. Absorb it wherever you can find it, and let it moisten the brains of as many others as you can.
Don’t limit that value-add to the person in the seat to your left.
PS. Communicate!
If I come across as smug about having taken this approach for nearly ten years, it’s because I am (a little). However, the important takeaway for us all here is to be aware of your approach and compare it to the approaches that others are using. You might be ahead of the curve. You might be putting a new slant on an old idea. You might be using an old idea whose time has come back around.
Don’t assume that what you’re doing, or how you’re doing it, is normal, nothing special, or that everyone else is doing it (better perhaps). Consider that, just maybe, how you’re doing it is innovative, unique, The Next Big Thing.