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…