BlogShift-Left Testing: A Requirements Approach

There is no failure. Only feedback.

Robert Allen

I tend to agree with Alan Richardson (video) that the term shift-left is consultant-speak. It’s an umbrella for the concept of testing as early as possible at various stages within the software development process, which is generally accepted as a good idea.

“Do these pants make my butt look big?” “Does my breath smell?” “Do you think I’m stubborn?” Whatever the motivation, these types of questions are asked to solicit feedback. Feedback is the response to a test that we want to validate as true or false. In engineering, feedback closes the loop so a system can self-correct (see closed-loop systems). In other words, testing enables self-correction.

Testing always comes at a cost. Writing tests, running them, and making changes based on the results all take extra time and effort. Worse yet, if no problems or defects ever surface, it was a wasted effort. But if you’ve ever developed software, you know that problems are always discovered. It’s not a matter of IF, but WHEN. The cost to test is vastly outweighed by the cost of not testing.

The earlier, the better

So back to, “Do these pants make my butt look big?” Is it better to have the answer to that question while still in your closet, or at the dinner party? Likely, the sooner you know, the better able you are to correct the predicament.

In product development, correcting problems early generally incurs the least cost. There is always a cost to correct, but it’s much less costly to resolve it earlier. That’s because early work tends to establish a foundation for later work. If you realize that you need extra outlets in the living room of your new house, is it less costly to identify that during framing, or after the home is finished?

Note that the costs of finding and resolving problems later are usually not incremental, but orders of magnitude greater. When I worked in the semiconductor industry, the rule of thumb was that at every major stage in the process, letting a defect slip through costs 10X to correct relative to the previous stage. In software, think about all the employee-hours spent designing, building, and deploying features that may need to be reworked entirely. The 10X multiplier may not be far off. Catch problems early to avoid huge costs later.

Shift-Left to Testing Requirements

(Yes, I said that shift-left was consultant speak, but let’s just roll with it.)

You want to build a new software application to solve a problem, or modernize existing software. Can be for internal use in your business, or sold externally for your customers. What feedback can you gather to self-correct? How early can you test your product requirements? It turns out, you can test quite a bit during requirements-gathering.

Feedback from User Research

The field of User Research focuses on gathering feedback directly from those who will engage with your product. The goal is to ensure the resulting solution will indeed address their needs and solve their problems. These individuals can be the end-users themselves, or influencers, decision-makers, or others who are in orbit around your product. Through a host of research methods, the result will provide direct, contextual insight into the features and language that your product constituents want to experience as they evaluate and use your product.

For instance, one of our clients approached us because their current web application sorely needed a modernized user experience. We conducted live, one-to-one video call interview sessions with users of the existing app, and discovered some users didn’t even know certain features existed, while others only needed a few additional features to make their work lives measurably better. Moving forward with this feedback meant the product requirements and designs were molded to meet the needs of the people using it.

Experience Before Development: Design Prototyping

What if your users could experience your software before it’s developed? Interactive design prototypes enable you to receive feedback via a high-fidelity experience of your application, without any coding. They allow for some of the earliest testing possible, with hands-on feedback from actual users.

Design prototypes work best for modeling key features of your application that you specifically want to test, instead of the entire application. For instance, prototype workflows that are important for your users, or features that differentiate you from your competitors. From a users point of view, nothing beats interacting with the application in hand to see what they say, and how they react. This feedback is directly applicable to your requirements, and even if some redesign is necessary, it’s much better to have it now than after sinking time and money into developing those features.

Wrapping up

The spirit of Robert Allen’s quote at the top of the article is right. However, if your stakeholders define failure as hyperextension of your software project’s timeline and/or budget, it’s worth considering how early testing can save you from their…feedback.