How Do We Sell the “Test Early” Principle?

Deliver just enough, focus on a minimum viable product, test early, test often, drive testing to the left, build quality in, prevent defects from occurring—these are all sound bites that communicate the need and intention of "building the right thing right." But goals and principles are always easier to articulate than they are to actually implement.

I'm often asked, How do we convince our key stakeholders that testing earlier and at lower levels in the system or application is beneficial? Usually there are three camps in this regard:

1. Organizations that just “get it” and immediately embrace the need for code reviews and unit testing;

2. Teams that are dipping their toe into the water and exploring what's possible—they have a desire, but there is some uncertainty in getting there; and

3. Teams that will never embrace this approach given their organizational culture, belief, or some other regulatory or compliance constraint.

Group 2 is by far the largest group. Many companies are striving to test earlier. This has been the case for decades, but stating it as so does not make it so, as we well know! In many cases this is less of a technical issue and much more an organizational, change management challenge.

Here are a few approaches to testing earlier that have been successful in organizations I've worked with and for:

  • First, someone must pick up the torch and assume accountability for driving the change. It's been my experience that there can be lots of wishful thinking, but with no one appointed to drive the change, nothing happens. If you're passionate about it, own it.
  • Have a plan—in this case, an organizational change management plan. Think about the current state and the vision for where you want to be in some defined time frame.
  • Identify the key stakeholders and educate, mentor, and coach them. Do not assume that what is obvious to you is obvious to the development leads, functional managers, product owners, and so forth. Employ case studies, white papers, and testimonies to communicate the benefits of testing earlier:
    • Project costs are lower because defects found earlier are cheaper to fix and often easier to find
    • Tests are cheaper to automate at the unit and service/API layer
    • Schedules are more predictable, with less probability of slipping because there will be less rework
  • Secure buy-in and commitment from a few people and partner with them on a pilot. Capture your results and communicate them. Word of mouth remains the best marketing tool; when others see something succeeding, they yearn for that success as well.
  • Anticipate objections and have factual lines of defense for each. Some will say developers need to develop. Be prepared to speak to the implications of this in your business context—for example, the quantified cost of rework late in the cycle for your company's projects.

Most importantly, experiment, learn, change, and maintain a healthy sense of optimism. The reward of getting better products to market faster is well worth the challenges during the journey.

Up Next

About the Author

TechWell Insights To Go

(* Required fields)

Get the latest stories delivered to your inbox every month.