test objects design

From UML Pattern Language by Paul Evitts quoting Donald Schon passage from The Reflective Practicioner

A designer makes things. Sometimes he makes the final product; more often, he makes a
representation, plan, program, or image of an artifact to be constructed by others. He
works in particular situations, uses particular materials, and employs a distinctive
medium and language. Typically, his making process is complex. There are more
variables—kinds of possible moves, norms, and interrelationships of these—than can be
represented in a finite model. Because of this complexity, the designer’s moves tend,
happily or unhappily, to produce consequences other than those intended. When this
happens, the designer may take account of the unintended changes be has made in the
situation by forming new appreciations and understandings and by making new moves.
He shapes the situation, in accordance with his initial appreciation of it, the situation
“talks back,” and he responds to the situation’s back-talk.
In a good process of design, this conversation with the situation is reflective. In answer to
the situation’s back-talk, the designer reflects-in-action on the construction of the
problem, the strategies of action, or the model of the phenomena, which have been
implicit in his moves.

JP of confused of calcutta writes about visualization and patterns:

As we see information continue to disaggregate and atomise, and as we see its velocity increase, we are going to need better and better visualisation tools and techniques. While there has been much progress in visualisation over the last decade or so (…), for some reason this has not made its way into business life. We’re still stuck in a world of PowerPoint presentations of scorecards and dashboards and RAG indicators, fed by Excel spreadsheets and simple databases, and with considerable manual intervention. Considerable use of derived data. Considerable throwing away of useful information. Considerable scope for sins of omission and commission when interpreting the derived data.(…)

We have the ability to take the sensed information and move it around so much more quickly. And in this digital age, we have the ability to connect different sources of information more effectively, both by use of semantic tools as well as by heuristic learning methods.

Almost everytime I have to search in Lotus Notes email for something I keep wondering the same thing. Some say ‘Hyperlinks subvert hierarchy’ but Lotus Notes wins because…?
It makes me wonder if Agile Methodology’s emphasis on proximity, people sitting in the same room within an earshot, so barriers to communication are dealt with ’structurally’ and not ‘politically’ is perhaps a type of subversion rather than natural evolution. It seems there are so many barriers to communication in a modern business organization, one of them for example is the fact that in order to have a meeting you have to reserve a room in advance and if you want a projector you have to reserve that too and somebody from facilities office will show up and open a room for you and set up a projector. Infrastructre is not set up for communiction to occur where immediate feedback and self organizing can produce breakthrough conversations on a project. Communication in such infrastructure is all about manually planning the maybeness of some sort of kind of knowledge transfer that might happen, sort of.

What I am saying is that we waste enormous amounts of time and effort using tools that aren’t fit for purpose, and then somehow we manage to convince ourselves that all is well

I stumbled upon Cem Kaner’s notes Examples of Test Oracles

An oracle is a mechanism for determining whether the program has passed or failed a test

A complete oracle would have three capabilities and would carry them out perfectly:

• A generator, to provide predicted or expected results for each test.
• A comparator, to compare predicted and obtained results.
• An evaluator, to determine whether the comparison results are sufficiently close to be a pass.

The ‘generator’ seems to be the source of distinguishing ‘expectations’ and any deltas as defects. One time a manager on a project told us - ‘anything that makes us look bad is a bug’. I guess he was a ‘generator’ in that moment.

Whenever I analyze UseCases or requirements and everything looks ‘ok’ and mainly ‘right’ I usually add a section to my analysis called ‘Risks’ where I list all possible ‘issue’ that may come up as defects to anticipate future user’s interactions with a particular feature. Then in the future when I get a bug report from the ‘customers’ I can compare my Risks section to see if I have ‘predicted’ it for myself. I try to build a ’smell’ generator from those notes.

As I am reading Robert Martin’s old Engineering Notebooks on Iterative and Incremental Development I came across a business argument, perhaps the best non-engineering argument of which I have many; against following Waterfall software methodology. You are welcome to download all his PDF docs from ObjectMentor’s site via this googleq:

The iterative process is producing data about the schedule. The completion times of the slices are giving us unambiguous empirical measurements that help us predict when the project will be complete. There is a wonderful thing that mangers can do with these measurements – with this data managers can… manage. They can stop dictating, stop motivating, stop losing control Don’t let this article mislead you. If you follow the advice above and begin developing projects in an iterative and incremental way, bluebirds will not fill your sky. Schedules will still be missed, there will still be bugs, problems, and mis-aligned expectations. Software is, after all, software; and software is hard. However, what you will be doing is using a process that produces data; whereas waterfall produces none. With that data, managers can try to manage the project. (…)a process that produces data can be managed. A process that does not produce data, cannot be managed.

I dig this argument: producing data about the schedule. I can see why in Scrum you should be keeping track of past Sprints and why you should be looking at how many backlog items are “YET TO BE DONE” and not DONE VERSUS PLANNED as happens to be the model in Waterfall. I think this is an important distinction. - In traditional Waterfalll you Plan what will be done with the assumptions that no changes will occur - but what if you can produce data everyday about how many items are yet to be done? how many are planned? you can calculate your running conversion, hence burndown chart, hence velocity as a measure of effectiveness.

I don’t have much experience with Scrum since most of my work has been on Test Design in what I would call Waterfallish type of project, however I must admit that my engineering process for Testing software has been iterative. I devised plans that were based in uncertainty but I never tracked data about my schedule, partly because I never designed it nor have never been on teams that designed it. Since Test Management is about repeatablitlity let me make a strong recommendation to myself and my team now to implement such a measure.

How do you manage means of communication as infrastructure for production of software?
Is this an appropriate question to ask about Means of Production in Software Age?

In the context of Industrial Age Means of Production (MoP. Der Produktionsmittel) was described as:

“combination of the means of labor and the subject of labor used by workers to make products. Means of labor include machines, tools, plant and equipment, infrastructure, and so on: “all those things with the aid of which man [sic]
acts upon the subject of labor, and transforms it.”
The subject of labor includes raw materials and materials directly taken from nature. Means of production by themselves produce nothing — labor is needed for production to take place.”

In the context of Software Age; what is the subject of labor? what are the means of labor? what is the worker? what is transformed? what is raw material?

Means of labor - “all those things with the aid of which man acts upon the subject of labor and transforms it” - Transforms it into what? Usable Code, Working Software that produces values. OK, so what is subject of labor acted upon? Can lines of code be a raw material? But they were invented. Lines of Code don’t exist in the wild that you can fish for, hunt, dig for…

What is a capital asset identified as means of production?

more questions…

Would it be worth for a software development projects to transition from Management-Intensive Process-Heavy style of creating software to Management-Intensive Inventory-heavy style of creating software.
I have been in many meetings where things being discussed are mainly about how things are to be done. Everybody has something to say like “Well, I think they (meaning some team) should be doing it this way” or “I can’t believe they are doing it. Just lust week they were doing it some other way” and so on.

It seems most conversations are management talking about process and how they are following it and how come some others are not following it or should be following it.

In contrast I would like to envision the same style of Management Intensive style of meetings but instead of process I would like to introduce a new conversation about managing inventory: items to be done, impediments to clear or overcome, promises of actions to take, milestones with dates and measurable results. WARNING: when I say measurable results it is results about about inventory, stuff to get rid of, process into something else and add value to it.

Matz comments: Otaku, Cedric’s weblog: Flaws in Ruby

Finally, I am not against “method overloading”, but it very easily leads to optional static typing in the language, which changes the language
very drastically, since you need to specify “type” to overload
arguments. Without well-thought design, it can “destroy” the language
and its culture. I have not yet got that well-thought design of
method overloading

Typography - Hypnerotomachia Poliphili

Scholars find that the greatest artistic merit of the book is neither in typography or woodcuts separately, but in the overall composition of text and image into a harmonious whole, which allows the eye to slip back and forth from textual description and corresponding visual representation with the greatest of ease – a rarity even today

Bret on Watir Mailing List

Actually, the best way to do this is to put test root in your load path.

$LOAD_PATH << File.dirname(__FILE__) + ‘/../’ require ‘lib/variables’ 

The problem with Keith’s solution is that you’ll end up requiring the same file from different tests via different paths. The semantics of require is that it won’t load a library if it has already been loaded, but if you are loading the same file but using a different path in your require statement, require will think it is a different library and load it again.

I am wondering if a better thing would be to unshift the path so it’s first in the stack like this:

$LOAD_PATH.unshift(File.dirname(__FILE__) + '/../')require ‘lib/variables’

Would it be a bit better? Would it cause problems if you are use other require for ‘test/unit’ etc…? Ideas?

from Brian Marick - Everyday Scripting with Ruby

What I tell people on my consulting trips is that every week you spend
at your job should make you worth at least a little more money. Make
a habit of asking yourself whether that has been true of the past week.
Some fraction of scripters fall into the opposite trap: they get so enthralled
with scripting that they build elaborate, gorgeous (to them, at least)
frameworks far in excess of what their job demands. The trick in scripting
is to push yourself beyond the minimum while still regularly producing
results that justify your salary. To do that, you have to grow
your scripts bit by bit, satisfying one real and immediate need after
another, while still keeping the code clean. This book won’t surgically
implant that skill in your skull, but it’s given you some of the tools you
need.(emphasis mine)