How do you quickly find the version where a bug was introduced?

MoT Content Discussions
, ,
1

Check out my latest Ministry of Testing article: Finding bugs faster: a smarter way to debug integration failures.

In this article, I share a a practical and efficient technique for identifying the first version of a build in which a bug appeared. It’s especially useful when full integration test suites are run infrequently due to time or resource constraints. It presents a simple search method that speeds up the debugging process using parallel test execution.

What You’ll Learn:

  • How to leverage multiple test environments or devices to reduce debugging time
  • A step-by-step method to find the failing version quickly
  • When this approach works best and where it may fall short

After reading, share your thoughts:

  • As a tester, how do you handle bugs in integration tests that appear intermittently or are caught only during infrequent runs?
  • What strategies have helped you quickly pinpoint where things started breaking?
  • Do you use parallel test execution today, and if so, how do you manage it?
3 Likes
2

We do something similar with git bisect. We usually don’t have as many builds as you’re seeing between test runs, so the parallelization doesn’t typically buy us as much.

I do really like this idea for situations like yours, since it takes advantage of having multiple devices/environments to effectively do multiple bisects at once.

3

My strategy is quite simple I test each previous build of the software until the issue isn’t present.

4

This is kind of long way to get there…
If you have automation it can help reproducing.