The SQA2 Blog: BBT - Behavioral Based Testing
Guiding Principles – BBT. As you may know, BBT is an amalgam of BDD and cause and effect graphing. In order to leverage the true power of BBT, the QA professional needs to make a paradigm shift. The tendency is to graph the entire test case as you would a flow (like a Visio chart). However, to get the most out of BBT, you need to graph the behaviors (hence, behavior based testing). As we make this paradigm shift, there are five principles that will guide you to help keep you on the right path.
- Determine the Outcome and its variants first.
- Determine the requirements to achieve the Outcome. These requirements are the only contexts that should be graphed.
- Only Positive Outcomes should be graphed. Negative or error conditions should be asserted positively.
- KISS – The old adage still applies. However, we have applied a little twist to this. Keep it stupid simple. As simple as possible. Don’t get complex.
- A tester should be able to execute the test cases generated from the graph.
In this article we’ll go over these in more detail and how they will help keep you on track.
Determine the Outcome and its variants first.
This is the overarching principle and highest principle. The reason for this is that it forces you to think from a behavior stand point by determining what the expectation is. Too often as QA professionals we are used to identifying and realizing test cases so we are thinking of all the intermediate steps to get to the result. That is not a bad thing, however to graph a BBT flow, we need to change our point of view so that we can leverage its power. So start with your target. What is your expected behavior? Then determine if there are variants of it. From this you can determine what essential pieces (contexts) are needed in order to reach the outcome (or a variant of it). This leads us to our second principle.
Determine the requirements to achieve the Outcome (Establishing the context(s) without considering the steps to get there). ONLY these requirements will be your contexts.
Following from the Outcome and its variants, we identify only the requirements needed for the outcome to be true. Again, this goes back to eliminating flow. In an example of a system login, the expected behavior is a successful login. What is needed to login successfully is the question that needs to be asked. The answer could be “a valid username and a valid password”. These would in turn be your contexts. In more complex scenarios, this is a very important principle because you will limit the contexts to the critical information for the expected behavior. This eliminates flow and sets you up with a successful foundation for BBT.
Only positive outcomes should be graphed. Negative or error states that need to be tested explicitly should be asserted positively.
One of the benefits of BBT is the ability to increase your test coverage. Based on the contexts (all your requirements) needed to be true to reach an outcome, you can derive or use the BBT tool to generate the test cases. Since both positive and negative test cases are created, the failed conditions are tested automatically. Only in cases where you have explicit negative outcomes will you test for these certain conditions. These should then have their own outcome and associated contexts.
KISS – Keep it stupid simple
In this principle we purposely changed the order of the S’s. The old adage focuses on the person. We wanted you to focus on the output. So by changing the order, you focus on your graph. Overall, simplicity is the order of the day. The more focused your graph is to the outcome (behavior you are graphing), the better the BBT tool works for you. It allows for better re-use; and automation is made more efficient.
A tester should be able to execute the test cases generated from the graph
This focuses on how you write your contexts and outcomes. As you generate your test cases from the graph, it should be readable as a test case so that any tester can execute it when it comes time to run it. If you can’t understand it when it is done, then you should think about how the context or outcome is formatted. In this principle, we aren’t necessarily talking about domain knowledge as much as how to ensure the test cases are readable when generated.
