How can Model Testing help test low level functions?
It has taken me way to long to respond to this comment from Scott.
re: For Testers: Nihit Kaul Talks Up Model Based Testing
It appears that model based testing forces you to define the various actions your application can take (add, edit, delete, rename, etc.) and when it can take those actions.
But I don't understand how lower level functions are tested in this model. I mean, in your 'add' function has a screen with 80 text boxes that need to be filled in, how is model based testing going to help? I still have to write code to fill each of those boxes, and the code I write is still "static script".
It appears model based testing is a series of static scripts instead of one giant static script. Is that correct?
It's true that Model Based testing may not be best suited for everything. If your low level function doesn't depend on any states you can define, doesn't have any transitions, and just has a lot of parameter arguments then you are probably better off with the application of Pair Wise testing which, with the pairing of argument combinations has the ability to reduce the testing matrix. It's based on the assumption that most bugs in software occur with a combination of one or two inputs. The pair wise combination will then help you reduce the number of scripted tests you might have otherwise tried to generate. If you know something about how the function works (if some pairings aren't valid) you can limit the combinations even further. However, if your low level function depends on some states from classes around it or the system it is running on then you should leverage both techniques.
Depending on the tool used to generate your model tests it could be a set of static scripts that are generated off of a query from the model. The difference is that the scripts are generated by the query of the abstract model (shortest paths, all transitions, etc) rather than trying to enumerate all the correct scripts yourself. For further efficacy you would have a tool that automated your feature straight from the states/actions of your model. Then you can simply “run” the query and not regenerate test code if you make changes to the model (other than the main model code you wrote).