It All Starts With User Features: The Logical Functional Model
Even a small application such as Microsoft Notepad has a plethora of features that must be tested. While the occasional feature is simple enough that a single test case is sufficient to test it thoroughly, it is more likely that multiple test cases are required to verify a feature works as expected. Furthermore, the individual actions that together form a test case are likely to be used in other test cases as well. While this common code is sometimes duplicated across test cases, more often it is factored out to helper methods. Organizing these methods into a logical, unified, scalable, easily navigated, and maintainable model is of paramount concern.
We have solved this problem by using the application’s features as the organizing principle of our libraries. We wrap test case execution helper methods into a Logical Functional Model, or LFM, that is a user-centric view of our application. We ask, “What can the user do?” and ”What features does the user see?” As you might expect, answers to these questions tend to line up with the features our specifications define.
Organizing our LFM around product features eliminates navigation problems because methods for interacting with a feature are in an area named for that feature. It is also clear how new features fit into the system, so scaling problems are avoided as well. The test cases themselves become nothing more than a list of the actions the user will take to do something. Our test cases are easy to read and easy to understand.
