test objects design

From IBM article “Business services modeling”:

Qutes (marekj: bold is my emphasis for research on FUNTOM)
“Business analysts often specify the system functional requirements using process models while developers prefer to use object or service modeling to specify implementation models. How these different world views are reconciled and kept in sync as the applications develop in the face of changing business requirements is not well understood and can result in cost overruns and applications that don’t meet customer needs. The problem is that there is no well-defined relationship between process models and object models, reflecting yet again the business/IT gap and resulting in poorly integrated development tools.”

“Any software application has to have a specification of what it does, and an implementation for how it does it. Models can provide a relatively high-level way of describing both. (…) two basic styles of software modeling in common practice today: business process modeling and object modeling”

Business process models appeal to business analysts because they can be relatively simple and focused on specific, identifiable tasks that result in clear business value. We are all very familiar with following a sequence of steps or a recipe to achieve some end result. It is very easy to capture existing or anticipated business processes in process models because these models directly reflect the steps in the business.

Object-oriented technology (OOT) introduces the concepts of identity, encapsulation of state and behavior, inheritance and polymorphism, and communication through messages. OOT greatly reduces the complexity and maintenance costs of software systems, and facilitates reuse.

OOT has been shown to be useful in reducing system complexity, managing change, and facilitating reuse. In some situations, the business processes might benefit from using an object-oriented (OO) implementation. But what is the relationship between the business processes and the business requirements they represent, and OO implementations? Do you transform the business process models into an OO implementation by using them to help discover domain objects that interact in some way to accomplish the same business results?

Commentary:

In a similar manner I call the transition from requirements in documents to working system in code as ‘The Gap’ but recently I am calling it The Cloud Where Magic Happens. I saw a catoon once explaining how scientists work. The missing link was “Magic Happens Here” and unexplained stuff occurs that transforms stuff from the left side to the right side.

So how to make process model and object model work for Software Testing?

ProcessModel: use it for Test Management. TestCase as a unit of tasks. Each step in TestCase is a task.

ObjectModel: use it for Writing test cases. each step in TestCase is a message to an object. Subsequent task step is again a TestObject.message and so on and so on. Those two models can be reconciled easily here.
Functional Specifiations as a Test Object Model that can be wired to executable implementation in automated test tool.

TestScope Model manifested as UseCase Model.

more on this later…