BFT - Stream Testing

Good afternoon, Hobrechiteli!

In my heading IT (Interesting Testing) I will try to tell you about various interesting approaches to testing and useful tools that make the process of finding errors fascinating.
Today I will tell you about:

• BFT - Business Flow Testing, what is it?
• I will show you how to use it with simple examples.
• What are the advantages of this approach?
• Where it can be applied
• And what will happen next

Stream Testing (BFT - BusinessFlowTesting)

BFT is an approach to testing, where you look at a product not from the point of view of specific cases, but from the point of view of the behavior of the system at each of its points.
The approach is a combination of concepts such as Data Driven Testing and Behaviour Driven Testing, applied to business models that are well described by data movement graphs.
You do not test individual test cases, but test the performance of the system, test cases are obtained by themselves
Figuratively speaking, you have:

• A set of diverse input business data
• The system is broken down into important for testing the state of business entities that need to be checked.
• State transition rules

You have no test cases. Test cases are generated based on the input data themselves.
No more arguing about how to name test cases correctly. The name of the test case is the set of inputs that define it and the path they follow. The name turns out long, but completely describing this test. And besides, you do not spend a second on it - it is created by itself.

BFT Framework

How does the BFT framework work and how to make it yourself? Consider a simple example.
Suppose your application is a store selling goods. The main Acceptance tests will be tests on how the user purchases this product and what may happen next.
')
Business entities:

• User (name, payment type (bank card, cash, electronic money, etc.), discount card, purchase history, promotional code, etc.)
• Commodity (name, number, initial price, final price, quantity, shares in which it participates, etc.)
• Purchase-Basket (List of goods, basket price, final purchase price, purchase status)

Order states:

• Created
• Approved (Registered)
• Paid
• Delivered
• Delivered (Delivered)
• Delivering Rejected
• In the Archive (In Archive)

Product transfer graph



You have a chart that is most likely provided by the business. If not, then you can make it yourself, which will bring a lot of benefit in itself.
To test this Chart, the tester describes each state.
To describe the state you need to specify:

• Checks. What to check in this state
• Transitions. Where and how to go from this state

PS Both Checks and Transitions are a function of Context, i.e. dataset and path traveled (optional)

Each test is a linear path in this graph, which is characterized by input data.



Input data can be of several types:

• Business data (user, product, basket, etc.)
  • Affect state checks
  • May affect the path in the graph (for example, the Registered User skips the identification and moves immediately to Paid)
• Control data (for example, to make a return after payment or return an order from the archive)

Writing tests

Basic simple test

We have a business model graph. For this graph, we create a test code that describes, already in a programming language, what needs to be checked in each state and where to go next.
Bottom line: we have a test graph described (the graph does not have to be fully described at first, for example, only the positive scenario is described at first, all other states and transitions can be added as needed).



The first test is usually the main positive test that passes from the beginning of the business flow to the end without errors.
We form the input data for a positive test.

The test itself will look something like this:

var SimpleScenario = BusinessGraph.GetScenario(CorrectSimpleData, DefaultControllData);BFTFramework.Run(SimpleScenario, CorrectSimpleData);

BusinessGraph on input data CorrectSimpleData will build a linear script path (by default DefaultControllData) in the output graph we get SimpleScenario.
BFTFramework will execute this script with CorrectSimpleData input data.

The rest of the tests

Now, if we want to check a lot of different positive data, then we simply transfer other sets of CorrectOtherData.

If we need to add, let's say, negative tests (for example, the return of the purchase):

• We add a new Rejected Delivering Status in the BusinessGraph (checks that need to be made when switching to this state, and possible paths from it, if needed)
  
  
  
  
• Add transition paths to this new state from other states (in our case, this is Delivering arrow -> Rejected Delivering)
• We pass to our test a set of incorrect data. DeliveringRejectedData

And so on, gradually increasing our graph with new paths, and tests with new data sets.
If you decide to make a new check at any step, you do not need to think in which tests it occurs. You simply add it to the appropriate State, and all the tests that pass through it will be corrected.
A new state has emerged, through which our product must pass, simply add it to the graph, and all the tests that affect it will be redirected along a new path.
You edit the test code locally, only where it is needed.

Total:

• We get the separation of the test code into: data, “application test interface” (state of the graph and Checks) and data movement paths (arcs of the Transistions graph)
• New tests do not need to write every time from scratch. We add only what is really new, reusing as much as possible what has already been written and avoiding code duplication.
• Since all of our tests move along the graph, we can use metrics to cover the functionality of the tests. For example, “each path is passed at least once,” or “each state is visited at least once,” or more complex — like visiting cycles in a column at least twice, and so on.
• We receive additional complete system documentation at the level of specific important checks.
  Often, even if at the beginning of the project there is a business graph, with the addition of new UserStory, it loses its relevance. Tests are always relevant. In addition, the business description does not include an understanding of what is specifically important in these states, or this information is scattered across different UserStory. Looking at the BFT graph, you can always say what is checked at this step, where you can go from it and in what way
• Testing with the help of BFT can be combined with any other tests that are not very easy to fit into the scheme or heavily clutter up. Think what and what you use
• With the correct writing of the BFT Framework at any given time in the test, you can find out the entire scenario (States and transitions) and at what step you are now. This script can be easily logged in case of an error or transferred to the developer when he asks you, “what does this SimpleTest do at all?”
• Since you know the entire script, you can log the transition to each new state automatically, at no additional cost to the tester (and usually in such cases, logging is simply ignored due to lack of time)
• When moving in a graph, we use a test context that contains all the information about the test:
  • All input
  • Current script
  • Current step
  • Additional variables that we saved during the test
• We can easily output all this data to the log if the test fails or transfer it to the developer without running the test in a new debug.

Application area

Before you use something, think about whether this tool is right for you.
This approach is applicable to projects where you can easily identify business entities and the states in which they live.
It can be:

• All kinds of shops. Selling real goods, content, services, etc.
• Delivery service
• Banking projects, payments, transfers and other projects with transactions
• Interface Testing (UI). You can represent the User as a Business entity, the page as a state, and user actions in the form of state transitions.

In one of the departments of i-Free, we successfully applied this approach, I hope that it will also help you to make beautiful, easily supported, logged and visual tests.
What's next?

In the following articles:

• I'll tell you about the generation of input data sets, the construction of intersections and exceptions to create only important tests
• I will tell you more about metrics and how to build a testing process with BFT
• I will dwell in detail, with examples of "pseudo-code", on the description of states, checks and transitions
• I will talk about the pitfalls and problems that may arise when you first met with the BFT
• I will try to highlight the questions that I hope will arise in the comments