Using Binary Search to find Introduced Bugs |
 |
 |
 |
| Written by Graham Stoney | |||
|
I first came across the idea of using a binary search technique to find newly added bugs when a particularly smart colleague of mine used the technique to find a memory initialization error in a large chunk of embedded system code that he was completely unfamiliar with. He wasn't even familiar with the language it was written in, and he had no particular interest in getting intimate with the code; but he knew there was a problem because sometimes it ran correctly from power-on reset and other times it did not. He was able to pinpoint the location of the uninitialized variable by pre-filling the 64K data space with a pattern that made the code fail, and then with one that made it work correctly; and then split the data space in half and filled one half with the “good” value and the other with the “bad” value to see which half the rogue variable was stored in. He narrowed it down just like the smart contestants do on The Price Is Right when they are trying to guess the exact value of the prize. I've since used the technique many times to find bugs that have popped into the code unintentionally during software development. Provided you are following some of the other advice here, like Using a decent Source Code Management Tool, Committing One Change at a time, Automating Your Builds and Not Breaking The Trunk, you can perform binary searches on your code base by checking out and building snapshots of the trunk which either pass or fail a given regression test to nail down the exact change that injected the problem. You then look at who committed the change, and go around to slap them over the head with a wet fish. The key advantage of this technique is that it requires no understanding of the code in order to find the problem; all you need is a test which demonstrates whether the problem is present, and the ability to rebuild incremental snapshots and run the test reasonably quickly.Note that following poor development practices like allowing developers to “break” the trunk in ways which either don't build or don't run for even short periods of time render powerful techniques like this ineffective. And since this technique has saved my precious butt more than once, it is another reason I don't work with people who do things like that. Social Bookmark this page:         
|