test objects design

InfoQ: Book Excerpt and Review: Applying Domain-Driven Design and Patterns with Examples in C# and .NET

Each requirement is first discussed with a combination of written discussion, hand-drawn UML sketch, and a test case expressed as code. Nilsson uses the hand-drawn sketches to emphasize that the test code is “the most important representation of the real model.” The UML is essentially a stepping stone to the real design documentation and not an artifact in and of itself. The author suggests that a basic UI should be examined early in the design phase. In this way the domain design can be tested against its planned use. As the focus is on the domain itself, very little time is spent on the UI itself, which can be sketched out with pencil and paper.

This quote is useful how? – test code is the most important representation of the real model…

From Develop Information Architecture

A wireframe is an abstract diagram illustrating the structural aspects of a page or page template. An explanation of how a section of the page may be used or the rationale for the page structure may complement the wireframe. A wireframe defines the types of information and services (including navigation) available on a page.

My FUNTOM notes:

UseCase Model for TestScope.
Activity Diagram to model usecase
Wireframe (maybe I should call them TestFrame or TestWireframe) to model page where TestObjects play the game. I guess test case execution happens in Frames. You move from Frame to Frame. on each Frame there are test objects to send messages to.

in Ruby

module TestFrame
  class GoogleHomePage
    def self.search
      #put watir implementation here of clicking on the button.
    end
  end
end

#example of TestCase step
TestFrame::GoogleHomePage.search

##
# better solution maybe create light framework. Abstract UI
# TestFrame is now some Wireframe object which can be a page
# or a panel or some grouping that we arrrive at and can exit from.
class TestFrame
end

class Google < TestFrame
end

##
# testcase step
Google.search

This way implementation is in inheritance and not in TestCase step notation.

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…

In the spirit of continuing my FUNTOM research material here are some quotes I will use for presentations. (bold is mine to highlight concepts)
From An introduction to Model Driven Architecture

Models provide abstractions of a physical system that allow engineers to reason about that system by ignoring extraneous details while focusing on relevant ones. All forms of engineering rely on models to understand complex, real-world systems. Models are used in many ways: to predict system qualities, reason about specific properties when aspects of the system are changed, and communicate key system characteristics to various stakeholders. The models may be developed as a precursor to implementing the physical system, or they may be derived from an existing system or a system in development as an aid to understanding its behavior.Because many aspects of a system might be of interest, you can use various modeling concepts and notations to highlight one or more particular perspectives, or views, of that system, depending on what is relevant at any point in time. (..) how enterprise application developers take advantage of modeling. (…) The UML allows development teams to
capture a variety of important characteristics of a system in corresponding models. Transformations among these models are primarily manual. UML modeling tools typically support requirements traceability and dependency relationships
among modeling elements, with supporting documents and complementary consulting offerings providing best practice guidance on how to maintain synchronized models as part of a large-scale development effort.

(…)

Today, a majority of software developers still take a code-only approach (left end of the modeling spectrum, Figure 1) and do not use separately defined models at all. They rely almost entirely on the code they write… Any “modeling” they do is in the form of programming abstractions embedded in the code…

Any separate modeling of architectural designs is informal and intuitive, and lives on whiteboards, in PowerPoint slides, or in the developers’ heads. While this approach may be adequate for individuals and very small teams, it makes it difficult to understand key characteristics of the system among the of the implementation of the business logic. Furthermore, it becomes much more difficult to manage the evolution of these solutions as their scale and complexity increases, as the system evolves over time, or when the original members of the design team are not directly accessible to the team maintaining the system.

An improvement is to provide code visualizations in some appropriate modeling notation.

The question a Tester would ask here is: where do I get the knowledge of what to test? If I haven’t been to the meetings and haven’t taken pictures of drawings on whiteboards and if I don’t possess magic that would allow me to enter developer’s heads and rummage around..? what then? How do I test the system? how do I manage coverage, acceptance criteria? – Perhaps an improvement is to model it not on develpment side but on Test site. Develop TestObject Model, a view, a perspective that highlights Testability of the system. This approach I call FUNTOM. Functional Test Object Model. The key to is not code visualization but functional requirements visualization, behaviour visualization, collaboration of Test Objects visualization.

A model-only approach is at the far-right end of the coding/modeling spectrum shown in Figure 1. In this approach developers use models purely as aids to understanding the business or solution domain, or for analyzing the
architecture of a proposed solution. Models are frequently used as the basis for discussion, communication, and analysis among teams within a single organization, or across multi-organizational projects. These models frequently appear in proposals for new work, or adorn the walls of offices and cubes in software labs as a way to promote understanding of some complex domain of interest, and to establish a shared vocabulary and set of concepts among disparate teams. In practice, the implementation of a system … may be disconnected from the models. An interesting example of this is the growing number of organizations that outsource implementation and maintenance of their systems while maintaining control of the overall enterprise architecture.

We have seen a number of fundamental shifts in the way software practitioners perceive software-intensive solutions. These moves have changed the mindset of the vast majority of software engineers. Formerly, they concerned themselves
with the low-level details of manipulating bits of data and moving bytes between registers in the CPU; now, increasingly they spend a majority of their time understanding the users’ problem domain in terms of use cases to be supported, and designing solutions that they conceptualize as collaborations of services offering behavior to realize those use cases. This profound shift in thinking has only been possible because it has been supported by effective tools that allow the new concepts to be clearly expressed and shared.

(…) organizations are well-served by creating models of the problem domain and solution domain, and by coordinating these models throughout the life of a software project

So I am strongly recommending that software projects utilize TestObject Model by modeling UseCases behaviour with Activity diagrams. I would use Wireframes instead fo actuall UI screenshots. Wireframes as conceptual schema. TestObjects modeling logical entities in a UseCase and not physical models in a system.

Here is a quick example:
When you send email you can model TestObject EmailMessage. In it you specify attributes like address, body, subject and actions like send, save, discard. All of those messages (I like to use messages instead of methods) change this TestObject state. A zcode (zcode == pseudo-code) could be like this:

## 
# TestObject skeleton
class EmailMessage
  attr :address
  attr :subject
  attr :body

  def send
    #wire behaviour for sending message
  end

end

# TestCase steps as zcode

EmailMessage.address = "president@mycorporation.com"
EmailMessage.subject = "Please Implement FunTom"
EmailMessage.body = "It can save you a ton of money"

# finally behaviour can be like this:
EmailMessage.send

##
# We are not concerned with wiring the messages with code 
# that actually does something. We are modeling behaviour of TestObjects
# So now we can have some test conditions

if @address != :address
if @subject == nil
if @body == nil

# There are 3 TestConditions to explore. 
# Each one of the conditions tests some expectations.

#In Rspec we can do this even better.
require "rspec"

##
# rspec scaffold
# writing specificaitons of a TestObject
context "marekj sends an email message" do
  specify ":address must entered" do end
  specify ":subject should not be empty" do end
  specify ":body should not be empty" do end
end

# we can leave TestObject static and write TestObject specs with rspec
# TestObject can be wired with Watir later for execution

Lean Software principle listed at Poppendieck’s site:

Write executable specifications instead of requirements

Take a look at Rspec – framework for BDD; Behaviour Driven Development in Ruby. in Rspec you define examples of behaviour as expectations in a context; which is defined by a set of known objects in a known state.

The “Cone of Silence” strategy and related project management strategies – AC

In general, I find that Osmotic Communication and Cone of Silence are two strategies that need to be balanced, usually with more of the former and only a little of the latter

I wear earplugs.

My name is marekj (and yes, I am available for Hire especially if you have a failing project with high level of cynicism and resignation).This blog is about experiments in lean, agile, cooperative software production infrastructure building. Since, there are never enough people on the project, never enought time, never enought money in the budget one looks for shortcuts, more shortcuts, better shortcuts. One looks to automate, automate better, automate everything – most of all one looks to automate communication. So, I am interested in building infrastructures to support “Cooperative Games of Invention and Communication” and I think the place to do it in an organization is by building Test Teams. Let me explain with a quote:

“‘Suppose that…’ — we don’t want to say that software development is like something else; (…) “Suppose it was just itself, and you didn’t do any analogies for a moment, what would you see?”

“And so, what I came up with, (…) is that there are people who are inventing and communicating in the face of a problem that keeps changing, a solution that keeps changing, technology that keeps changing, out from under them all the time. They’ve got some end goal, they have to deliver this piece of software, they have to set up for the follow-on project, while all that there is as actions are invention and communication. And so I found it useful to talk about it in a vocabulary of a cooperative game.”

I picked the above quotes from the IT Conversations Interview with Alistair Cockburn (Transcript) as a way to engage you into looking at a role a Software Tester could play in a context of cooperative games programmers play. It all started in 2002 when I stumbled upon an article in SD Magazine by the very same Alistair Cockburn entitled “Games Programmers Play” and I started reasoning about my role as a Software Tester on a Development Team.
In the context of Inventing and Communicating what could I say, is the role of a Software Tester? What could I provide, contribute to make the game work for all? If in this game the moves I make consist entirely of inventing and communicating then how do those moves look like? What is the infrastructure that affords the moves?
In my daily activity there is a lot more going on than writing and executing tests. I spend a lot of my time communicating with various people on the team. With each person I use a different language, different vocabulary. With managers I talk about time, delivery, percentages, results. With DBAs I talk SQL statements, data models. With Java developers I talk methods, exceptions, states. With customers I talk Use Cases, scenarios, happy-paths, colors, font sizes…
At some point I asked myself “What is the context for my activity as a Software Tester?” – If I was just a Tester in a classic waterfall approach I would receive a Functional Specifications document and I would start designing Test Cases that would attempt to validate functional features of a known set of entities but instead I find myself spending time sitting with developers in their cubicles and reasoning with them how a functional design should be and how to implement business requirments, how to specify behaviour. I find myself working with developers looking at the code, having in mind future integration and system testing, taking the big picture into account while looking at classes and SQL calls. I also find myself discussing requirements with Business Analysts, drawing diagrams on a whiteboard and talking on the phone with Customers about new features and helping them articulate their requirements for improving their software. – Are these activities the software tester should be doing? Perhaps. I find myself communicating, distinguishing, synthesizing, abstracting, analogizing. Am I doing Inventing? Not sure – but I’m definitely connecting people and clarifying their ambiguities. My moves are all about communicating, perhaps to make sure that there is communication on the team. So In this context I started looking that perhaps my job as a Tester is to Support the Games. If Software Development could be cast in the context of “A Cooperative Game of Invention and Communication” then how can Software Testers can support the infrastructe of those games? How can Testers support this process of Invention and Communication that makes the game work and worth playing?

Hello. Today is Friday, Sept 9. This is a second day of my looking for a job and I think maybe I can review some things that will be informative about how I see Software Development as a Tester. I will be asked questions by potential recruiters about different skills and views on methodologies so I think I will just ‘spill my guts’ here on this blog.

Here is my resume page, one page, at-a-glance-look summarizing my last 10 years of Software Testing activity. This blog and resources at this domain will give you more info.

So, first question I have already been asked was about project management and processes for improving Software Development. In particualar the agile methodology know as SCRUM: OK, a bit of intro then: at SCRUM website I read that:

Of all software projects initiated in the United States, 94% are eventually restarted. In 1994, a whopping 84% of these projects fail to deliver the value that was desired by their customers, either because they never deliver any software or by the time they deliver the software it is no longer relevant to the business problem; by 2000 this had dropped to only 72% failing to deliver desired value, still no cause for celebration. Successful projects were analyzed to determine the reason for their success. The most important success criteria were user involvement (35.1%) and requirements management (24.1%). Proper planning, a consequence of both, contributed 9.6% to the success of the projects

I can see that the main REASON for success mentioned wasn’t really PLANNING as the centerpiece of almost any other methodology (mainly in Waterfal which is the main SDLC approach). If it was then you could AUTOMATE planning and not worry about it. I think the success was that USERS were involved and REQUIREMENTS were managed and that’s of course planning but foremost it’s about ENGAGEMENT and COMMUNICATION and to say even more it’s about getting CLARITY about what the project really is about, rather than what we think it should be about.

So about this CLARITY: All shareholders need to communicate all that there is to communicate at that particular iteration in a process, at that particular time-frame. Knwoledge is not managed in totality but it is defined by time-frames because each time frame is about context creation. Value in an interation is created in CLARITY of intention for that context. Only upon completion of an iteration you can use it as a base to move on and create a new context. You can’t really do that with planning because you don’t know what’s going to be at the end of an iteration and how the context will be shaped at the end which will give you a new base to move on.

In this way SCRUM is about daily meetings to answer those 3 questions. It’s about CLARITY of NOW. Everyone is on the same page. it gives continuity to Context where project can move with VELOCITY.

What about Self-Organzing teams? – I think they can only self organize when they operate from CLARITY. Self-organization is also a natural outcome of COMMITMENTS and those can only exists as an AGREEMENT to deliver VALUE so you have to get CLARITY of what the intended value is.

Ultimately it’s all about managing ambiguity and swimming in uncertainty but you can make moves in a game when you have a constant feedback mechanism which in SCRUM it’s the daily meetings.

Since we talk SCRUM I want to mention Terry Winograd’s paper called “A Language/Action Perspective on the Design of Cooperative Work” and the work of Fernando Flores who has a blog and whose book “Building Trust” is very relevant to having open communication in teamwork.

Technorati Tags: SCRUM