forth. Because of the focus on how the system works, behavioral tests can cover many of the important usage profiles and quality risks. While you can perform behavioral testing of discrete components—and some programming methodologies promote doing so—most behavioral testing focuses on large portions of the system or fully integrated systems. As the system comes together, the system's behaviors start to become most visible. Testers can then gain insight into the user's experience of quality.
Behavioral testing is supported by a variety of automated tools . For example, performance, load, and reliability testing require that testers deliver preciselycalibrated streams of data, transactions, and user inputs to the system under test. In addition, we often must gather statistics about how the system responded to these streams. In most situations, an automated tool does such testing best. For client/server and browser-based applications, you can find a variety of commercial tools for this purpose. Similarly, commercial tools exist to perform functional testing of many platforms.
Test experts classify these behavioral testing tools as intrusive or non-intrusive. An intrusive test tool runs on the system under test; for a client/server or browser-based application, the test tools typically runs on the client. A nonintrusive test tools runs on a separate system and interacts with the system under test in ways that are, ideally, indistinguishable from one or more real users operating the system.
Manually testing is an important—and, in many teams, primary—behavioral testing approach, too. Manual behavioral testing generally involves insightful planning, careful design, and meticulous result checking. A good manual tester also applies on-the-spot judgment to observed results that an automated tool can't. Skilled manual testers know how to follow a trail of bugs—or blaze a new trail as they go. Elisabeth Hendrickson's bug hunting technique, explained at www.qualitytree.com, and James Bach's charted exploratory testing, which he discusses at www.satisfice.com, are two examples. You can blend traditional scripted testing techniques with the exploratory styles, too.
Another important type of manual behavioral testing—almost a flavor of testing on its own—is what I call live testing . In live testing, testers—or users—subject the system to real data, user workflows, field configurations, and other true-to-life conditions. Acceptance testing is one form of live testing common in IT development projects. For market-driven systems, beta testing is a common live test technique. One of my clients produces a complex geological software package. A key part of their behavioral testing is what they call guest testing , where their customers send their most proficient users of the system to my client’s offices to participate in the final stages of behavioral testing.
Good behavioral testing, logically enough, requires some amount of understanding of the proper behavior of the system. In other words, the test team needs a certain degree of insight into the business or application domain of the system. This is especially true for complex systems like the geological package I mentioned, medical systems, and so forth. However, people with backgrounds only in the application domain—and without any understanding of testing—often fail to understand how quickly an experienced, seasoned tester can come up to speed on the application domain. I once had a banking client whose users expressed surprise at how effective testers without a banking background were at finding bugs in the system.
Testers are flexible like this in part because test professionals often get to be generalists, rather than having to specialize. Testing allows us to see the whole picture, which is why some people choose to be testers rather than programmers. In addition, beyond business domain skills, true test professionals have testing skills. We know