Checking Intended Behavior / Testing for Unintended Behavior

In Acceptance Test-Driven Development / Behavior Driven Development, the Triad (customer, developer, tester perspectives) creates descriptions of the required behavior for an application.??These descriptions are typically written as Given/When/Then scenarios that document the shared understanding of all the perspectives.?Each scenario can become a test which checks that executing the application produces what the Then part of the scenario describes.???

The application must pass these tests to demonstrate that it has the intended behaviors.? They also provide a detailed readable description of the behaviors. If the intended behaviors are required, then these tests are the requirements.

These tests could be referred to as checks in the terminology of James Bach and Michael Bolton .?The checks are created prior to implementation.?The tester’s role in the Triad is to help ensure that the checks cover all of the required behavior as can be foreseen.??The checks / tests are typically run automatically, although a few may require manual control.??The developers run these checks/tests as they are implementing the application.?

These checks cover the intended behavior.?They do not test for unintended behavior.?Someone with a tester’s skill, and creativity can uncover these behaviors, aka problems / defects, better than someone focused on delivering the intended behaviors.?These unintended behaviors may hurt people or disappoint customers.??(Paraphrase of Bach / Bolton).??Some of these unintended behaviors may be discovered by testing portions of an application; often the entire application is needed.

If an unintended behavior is required to be eliminated for an application to be released, then passing the test that demonstrates this behavior does not exist is a requirement.?On the other hand, the unintended behavior may be allowed by the customer for a particular release or a series of releases.?It’s a matter of tradeoff between the impact (combined with the probability) of the unintended behavior occurring during execution versus the cost (monetary, reputation, etc.) of eliminating that behavior.??

The customer’s perspective often includes the user’s perspective, the operator’s perspective, and other perspectives that interact with the application as a whole.?The user typically wants an application that is “easy to use”.??Some of the tests / checks for that behavior can be created prior to implementation, but the user really needs to interact with the application to test for usability.???The operator’s perspective concentrates on issues like the ease of installation, both original and ongoing.?

The more tests / checks that can be written prior to implementation, the more information the developers have to implement the application and there will be less misunderstanding of the required behavior.??