Model Based Testing (Testing using flow Diagrams)

What is Model Based Testing
Few days back, my dearest teacher and good friend of mine Zahid Irfan, replied to my post and asked me about my view on model based testing, his questions inclined me to read some more material about model based testing, so that I can answer his question, After studying lot of material I am summarizing my views about model based testing.

Models are used to understand, specify and develop systems in many disciplines. , models are used to establish understanding and provide a reusable framework for product development. In the software engineering process, models are now accepted as part of a modern object oriented analysis and design approach by all of the major OO methodologies. Model based testing has given a innovative way of test case designing, in most of the software development projects, test cases are derived from RS (Requirement specification) or FS (functional specification).

Designing test cases by using model of the software helps the tester in finding and exploring different paths or scenarios for the end user, modeling technique also helps in determining the correct output at given path

Problems in Textual Description
The traditional means of specifying the correct system behavior is with English prose in the form of a Requirement Specification or Functional specification. The specification, , is often incomplete - only the typical or ideal use of the feature(s) is defined, not all of the possible actions or use scenarios. This incomplete description forces the test engineer to wait until the system is delivered so that the entire context of the feature is known. When the complete context is understood, tests can be developed that will verify all of the possible remaining scenarios. Another problem with textual descriptions is that they are ambiguous, (i.e., “if an invalid digit is entered, it shall be handled appropriately.”) The ‘appropriate’ action is never defined; rather, it is left to the reader’s interpretation. For example, you think we should allow the user to retry the entry, but I think we should abort the command. If you wrote the code and I wrote the tests, they would fail and we will waste time resolving an issue that could have been done before we even started. At a recent Requirements Engineering Conference, papers and presentations described the root cause of 60-80% of all defects as incorrect requirements specifications.

Advantages of Model Based Testing
Modeling is a very economical means of capturing knowledge about a system and then reusing this knowledge as the system grows. For a testing team, this information is gold; what percentage of a test engineer's task is spent trying to understand what the System under Test (SUT) should be doing? Once this information is understood, how is it preserved for the next engineer, the next release, or change order? If you are lucky it is in the test plan, but more typically buried in a test script or just lost, waiting to be rediscovered. By constructing a model of a system that defines the systems
Desired behavior for specified inputs to it, a team now has a mechanism for a structured analysis of the system.
Scenarios are described as a sequence of actions to the system [as it is defined in the model], with the correct responses of the system also being specified.
The largest benefit is in reuse; all of this work is not lost. The next test cycle can start where this one left off. If the product has new features, they can be incrementally added to the model;
if the quality must be improved, the model can be improved and the tests expanded; if there are new people on the team, they can quickly come up to speed by reviewing the model.

It is just a brief description; I would like to continue to post some more material about model based testing.

Articles from Larry Apfelbaum and John Doyle helped me a lot in writing this post.