Reader response: The downward spiral of manual acceptance testing

Lack of unit testing drives the need for manual testing. Since testing is bunched up, development is as well.

Fellow list reader Jon Drnek responded to my request for challenges with incremental software delivery. He had several responses, but one in particular jumped out at me:

Lack of unit testing drives the need for manual testing. Its easier to batch the testing up and test many changes at once. Since the testing is bunched up, the development tends to be as well.

This is one I see all the time. And it often has the effect of enforcing a negative feedback loop:

  • We don’t have unit tests, so we need to do manual testing.
  • Manual testing takes a long time, so it’s more efficient to batch features and test them together.
  • Large batches means a longer wait for testing to happen, which means we spend more time writing untested code, before it gets tested

It’s a cycle that feeds itself.

Breaking out of the negative feedback cycle of big batches of manual testing can be difficult. But here are some suggestions, if this is where you find your team:

  • Start writing unit tests only for new code changes. Forget about trying to find 6 months (or even a week) to write tests for your existing code. Only write tests for new changes (bug fixes or features).
  • If you’re using GitFlow, or any other branching strategy that has more than a single long-lived branch (usually called master, main, or trunk), make the switch to trunk-based development.
  • Accept the fact that things will likely appear slower at first, when switching from large batches to small batches or flow-based work. It’s really just a change of perspective, as your bottlenecks are now more apparent than before.

Starting this transition from big batches to small batches is also the topic of my free e-mail course, Lean CD, if you’re interested in more suggestions.

Share this