These probably aren't going to come every day, but here's the first. Well, technically, it's the third, since I already posted three buzzwords earlier. In any case, a binary search is a useful method to find the source of a problem. It's similar to a traditional binary search algorithm, but is used in QA and other technical troubleshooting scenarios.
Basically, you look at the variables that could be causing or contributing to the problem you're experiencing, then eliminate or change 1/2 of them. If the problem goes away, you know it was one of the variables you changed. If not, it wasn't. You keep repeating until you narrow it down to the actual cause of the problem.
A realistic use would be discovering a new bug and trying to figure out when it was introduced. If you have a build every week and have 20 builds, you'd go back 10 weeks. If the problem is gone, you go back 5 weeks. If it's not, you go back 15. Using this method, you'd quickly find the build that introduced the problem.
Another use would be if you had a document that was causing a printer driver crash. Eliminate 1/2 the objects on the page and print. If it crashes, one of those objects is causing the crash. If it doesn't crash, it was one of the objects you removed. You'd then have a document with 1/2 the objects that still crashes. Then, take half of those objects away and print. It won't take long until you have a document with a single object on it that causes a crash. Add that document (and the original) to your bug report, and you'll keep your developers happy.
Saturday, February 21, 2009
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment