Sunday, July 5, 2009

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.


3 comments:

  1. Nice article. Can you please elaborate a bit more with real-world example (or two)? That would be very helpful. Thanks.

    ReplyDelete
  2. Kashif I agree 60-80% defects are due to ambigous RS.
    Who is responsible for modeling the requirements? You mentioned if you are lucky it is in Test Plan, but if we consider real example then it will be hard to create models for 500 requirement points. Big organization always has limited time.

    Kashif what you say, how can we inject in tough engineering process.

    ReplyDelete
  3. Hi ahsan,

    Thanks for your feedback, as model based testing is a technique to design test cases , it helps to accomodate maximum possible scenarios, model helps the test case designer to visulaize system flow. so person who is designing test cases will build model for sure, but your are quite right its always hard to get all the requirements and get clear requirements and we can face a situation where we dont have adequate knowlegde to build software model.
    As far as converting 500 functional points into model , indeed it is quite difficult and complicated task to do, but we can use "divide and conquer " rule by breaking into small modules.

    But in the end its all your choice, if time allows you, so can use this technique.

    again i really appreciate your feedback :)

    ReplyDelete