Limitations and Caveats of Markovian Behavior During Transaction Flow Testing
We assume that our design is good and decent. It has a hierarchical structure, there is a clear separation between processing data and queue management, with clearly-cut transactions types, an explicit transaction management record, and centralized transaction routing. The better the design, the easier it will be for you to achieve complete coverage by transaction flow testing method.This means that the tester can make well-grounded and practical predictions (by conducting appropriate tests) about the suitability of the program for use. Suppose now that you deal with a bad design. Does this mean that transaction flow testing will be useless? No, it will still be very useful. The tests discussed here will easily break the program with a bad design. What you cannot do without a bad design is to statistically justify its suitability for use.
The only important limitation of this model is modeling the behavior of each node with discrete-time Markov chain. In the case of non-Markovian behavior, you will have no choice but to test every possible path for each possible transaction, because the behavior will depend not only on the data contained in the transaction, but also on its previous history. Such testing is rarely practicable. Any reasonable concept of coverage is useless for non-markovian behavior. If you have this behavior and you carry out a specific set of tests , you will achieve nothing, but erroneous certainty. Non-Markovian behavior can be arbitrarily complex, so whatsoever level of coverage you achieve it will represent only a small part of the possible options. What should you do when facing non-Markovian behavior?
1. Get rid of it by redesigning it. In any case, this is the best choice. In most cases, non-Markovian behavior is not necessary. It occurs when people do not understand the issue well enough.
2. Isolate it. You may need to do this if your model describes a human behavior or the behavior of other, uncontrolled systems. The isolation procedure may consists in imposing restrictions on operations (changing the specification) or combining such behavior in a separate submodel, which you will have to test very carefully before you proceed to testing a higher-level system.
3. Accept the risk. Sometimes this is permissible. What is acceptable for entertainment programs may not be acceptable for crucial software.
Top 10 software testing companies provide the best qa and testing services. Dedicated teams of these companies help businesses of all sizes to save 1000s of dollars on creating and maintaining their own testing teams by offering cost-effective solutions to the development problems, improving quality and functionality of the software apps.
