What Is Bug Chaining?
Originating in the security testing community, bug chaining is the idea of combining different bugs of low severity to create a defect of high severity. I believe the term was coined by Mark Piper at the 2009 New Zealand OWASP Day where he discussed bug chaining in this OWASP Day podcast. In the end, bug chaining is an innovative software test design tool that can find really bad bugs in software.
Here's an example of how bug chaining works: Suppose you have a web application with an admin directory full of maintenance scripts. These scripts do non-destructive things like run backups, garbage-collect the database, and so forth. And suppose that the application doesn't properly check access permissions for that directory, so that any user can run a script that's located in it.
This is an alarming bug but one with limited impact. A malicious user might be able to cause a denial-of-service but probably will not even accomplish that so long as the scripts are written correctly.
Now, say that we find a second bug—one that allows users to upload new files to any directory in the application instead of only to the designated “uploads” folder. Again, so long as a user can't overwrite existing files, this second bug alone may have limited impact.
However, with the combination of the first and second software bugs, the application now has a critical security defect: Any user can upload an arbitrary script to the admin directory and then force the server to run it.
Taking this from the world of security into the more general testing context, it's common to see several concurrent bugs that taken individually are quite trivial but taken together are very damaging to the user experience. For instance, an application may have performance problems that make it unresponsive when reports are being run. This is bad enough. But if the UI makes it easy for the user to kick off reports accidentally, things quickly become much worse.
Always keep an eye out for any situation where users will encounter several defects simultaneously (e.g., several different items all being broken for users of a certain locale).
Dealing with groups of bugs is one of the places where conventional bug-tracking systems often fall down. Defects are reported and tracked individually, as though they were completely orthogonal to each other. As testers, one of our biggest value-adds is our ability to give stakeholders the “big picture” and to keep them informed about the tangible impact of all outstanding defects instead of just pointing at numbers in the bug tracker.
Our firsthand knowledge is what helps us ensure that we first address the groups of defects that are most harmful, instead of the ones that merely look worse when judged on their own.
