Best Practice for Software Testing: Just Enough Tests

Whenever I think about a best practice for software testing, I ask:

How many automated tests should we write?

You could declare that your team tests everything. Or nothing at all. Both are simple approaches. I think there’s a better approach.

To me, the right amount of automated tests to write is Just Enough.

Disclosure: This article includes affiliate links to any books I reference. I may receive compensation when you click on links to these products.

What is the “Just Enough Testing” Best Practice for Software Testing?

Just Enough Testing is a practical best practice for software testing. The goal is for teams to do enough testing to confidently release a feature. No more. No less.

Understanding your team’s context is critical to decide what “just enough” means. Much like my feelings on meetings, I want to balance shipping features and the need for quality.

So how can you decide what Just Enough Testing means for your team? I have my teams discuss the following questions:

  • What phase of life is our product in? Is testing worth doing at this phase?
  • What will the impact of bugs have on our users?
  • How easy is it to release a bug fix?

Answering these questions helps my teams decide how much time to spend on testing. Every project will require a different amount of testing. Understanding the impact of the decision is important for success.

Some results I’ve experienced from these questions are:

  • Changing a workflow that affects all users should have more testing before release. The goal is stability for customers.
  • Features that explore new use cases with few users need fewer tests. The goal is to learn quickly — too much testing slows this down. We don’t want to over-engineer the feature.

How can you put this approach into practice?

How do I follow the Just Enough Testing Best Practice for Software Testing?

Writing automated tests can become a timesink that affects project estimates. Most tests are easy to write, but it’s tough to quantify the value of the time investment.

To strike a balance, I use these approaches to follow the Just Enough Testing best practice for software testing:

  • New Code: Write enough to make it easy to add new tests.
  • Existing Code: Only test the code that you changed.
  • Bug Fixes: Write enough tests to prevent the bug from occurring again.

These guidelines balance the short-term need to ship with the long-term goal of quality. Bugs are inevitable. Spending too much time on testing is just as risky – especially if you miss project deadlines. 

Instead, I want teams to make it easy to add tests in the future. Existing tests remove the friction of adding new ones. As new tests get added, test coverage increases over time.

Conclusion

Software engineering is a job of tradeoffs. The time we invest in testing comes at the cost of shipping. 

Instead of declaring a test coverage target, I challenge you to take a more practical approach. Look at the context of your teams and ask:

How can we do Just Enough Testing to confidently ship and maintain this feature?

What are your expectations when it comes to testing? How do you balance the trade-offs of shipping versus polish? Let me know on LinkedIn or Twitter.

Further Reading

Before you go

Build the Stage is about teaching YOU how to be a successful leader. 
If you learned something new from this essay, I’d appreciate it if you’d complete one of the following actions:

  • Share this essay: By sharing, you help others grow their skills. Save a click with the buttons below.
  • Tip a Coffee: Your support shows I’m helping you grow as a leader.
  • Give Feedback: Candid feedback is the most effective way to develop one’s skills. Send me an email to let me know how to improve Build the Stage.
  • Subscribe! If you’re not a part of the Build the Stage community, it’s never too late.