On Organization by Circumstance


One of the books that influenced my thinking in the past couple of months is The Peter Principle by the Canadian teacher and author Laurence J. Peter. The book is famous for its principle, which goes as follows:

In a hierarchy every employee tends to rise to his level of incompetence given enough time and enough levels in the hierarchy.

And there is Peter’s Corollary to this principle.

In time, every post tends to be occupied by an employee who is incompetent to carry out its duties.

At first glance it appears that the book is an attempt at satire or parody. In many ‘case studies’ Peter humors the way that employees move upward in an organization to their level of incompetence and paints a somewhat melancholic and bleak picture of the employee who is caught at this level, like a rat in a cage.

Once you progress through the book and read about the symptoms and syndromes of ‘final placement’, you start to realize that this is actually happening all around you. The principle is viciously simple and Peter shows over and over again that when you try to explain why the hierarchy of the organization is the way it is, the Peter Principle is the only way to account for that.

Though the principle is a philosophic contemplation rather than a scientific fact, it has made me realize that the hierarchy of an organization is not formed of individuals being placed in these positions because they are the best fit for the job. I know that this, like the realization in my previous post, is a wide open door. And yet it made me look at the organization as an organism; as an entity consisting of people who are organized along other guiding principles than you might expect or suspect.

Especially the fact that you expect people in a certain position in the hierarchy to behave in a way or to show traits that are characteristic of that position, reduces your chances of interacting with the organization in meaningful way. Right now I am looking at the organization as a system in which people move around rather like molecules in a gas, bouncing off other molecules. Thus, the reasons for a person to be in a certain position are circumstantial and should be analyzed through the evolution of his or her environment, rather than from the perspective of organizational intent.

A Systems Perspective on Testing


Lately I’ve been looking at Systems theory (Bertalanffy, 1968) and wondering how much of it has been applied to testing and how much more could still be learned from it.

Three blind spots

I started with the assumption that little, if any, of the concepts in Systems theory have been applied in testing. This assumption proved to be false.  There were a number of blind spots in my assumption. I will list the most prominent of them.

1) Little explicit mention of Systems theory in testing material

The first blind spot arose from the observation that Systems theory is hardly ever explicitly mentioned or referenced in day-to-day testing. By day-to-day testing I mean the insights provided by the text books as used for certification (ISTQB, TMap), the testing standards, blogs on testing, articles on testing as published in the popular testing magazines and the mindset and knowledge of software testers. Although software testing deals, almost exclusively, with systems, there seems to be no explicit connection with Systems theory, or concepts within this field. To account for this, we should consider the possibility that software testing in itself is a subset of computation which is a subset of Systems theory. As such software testing may look inward for more detail, instead of outward for a position in the general picture.

2) Little knowledge of Systems theory among testers

The second blind spot is the knowledge, or common perception, among testers of the field of Systems theory. Within the context-driven school of testing, there are testers that look beyond the traditional views offered by certification institutes or testing standards. So there is a willingness to learn about, among other things, systems theory. Yet as a starting point for Systems theory (or Systems thinking) often the book Thinking in Systems (Meadows, 2008) is mentioned. Meadows wrote about System dynamics (Forrester, 1961), which certainly is a part of Systems theory, but it would be a gross overstatement that Meadows covers the landscape of Systems theory in total. A personal investigation of Systems theory revealed  – to me it was a revelation – that there are at least 18 fields of scientific investigation that are related to Systems theory. System dynamics is only a fragment.

3) The academic-vocational chasm in software testing

The third thing that obscured my perception of Systems theory and testing, is that software testers in the field are largely unaware of the theoretical (scientific, academic) foundations of software testing. I consider this a problem that affects the industry as a whole. There is a curious separation between the work that (academic) researchers in software testing do, and what actually filters down to the work floor. This may be a common phenomenon that is not at all particular to software testing, but it frequently frustrates me that what is taught in testing text books and testing courses is a filtered, abstracted and sometimes disfigured version of the original theories on software testing. Particularly of the 1970’s, which was a period in which software testing theory was formed, the tester in the field generally knows very little, perhaps only a few quotes, cut out of their context.

System theory in software testing

So if we look at how software testing theory evolved in the 1970’s and 1980’s, it becomes clear that Systems theory – certain (mathematical) system perspectives applied to, or originating from(!), computing and software – has been the main driver for that effort.

Automata theory

One of the branches of Systems theory is the Automata theory. Automata theory by and large started with Alan Turing, who conceived the Turing machine in 1936. From this theory arose theories on computational complexity, which is itself is a branch of Complexity theory, which is a branch of Systems theory. In computing Automata theory gave rise to finite state machines, for which we have a test technique called state transition testing (Chow, 1978).

Graph theory and partition analysis

Other ways of looking at systems, closely related to system design, developed in software testing in the 1970’s. Theories formed about the flow of information through software code and the selection of test data for testing the program. Regarding the flow of information Graph theory (branch of Network theory, branch of Systems theory)  was frequently used. The cause-effect graph (Elmendorf, 1973) is an example of that knowledge applied to in software testing. Also using Graph theory several path-based techniques were introduced, such as basic path testing (McCabe, 1976) and decision-to-decision path testing (Miller, 1977). One other (domain testing) technique, partition analysis (or equivalence partitioning), was particularly used for the selection of data to be used to test the paths (Goodenough, 1975). Partition analysis can be thought of as an application of Set theory, which is a branch of Systems theory.

Hierarchy and modularity

Another way of looking at systems is by seeing them as a hierarchical structure. This is called Hierarchy theory. On software development, the concept of hierarchical structures has had a huge influence. In 1972 David Lorge Parnas introduced decomposition and modularity into programming (Parnas, 1972). In testing the functional decomposition is a way to reduce the complexity of a system.

 Applying Systems theory

The problem with applying insights from Systems theory to software testing is a manifold problem. The first question that needs to be tackled is whether the making of software has changed in such a way that a new technique is warranted. In short: do we need other test techniques to test the current software systems? I ask this question because a number of our ‘black box’ testing techniques (particularly path testing and partition testing) definitely come from a ‘white box’ background. They are closely related to the way software (a program) is made. It therefore should be no surprise that software testing started out as ‘program testing’ (Hetzel, 1973). Other techniques, such as CRUD analysis (Martin, 1981) are equally based on code. Has the coding (programming) of our systems changed in such a way that the old techniques are no longer adequate to cover the system sufficiently? Has a change in programming forced upon us the usage of other aspects of Systems theory in order to create new techniques? Looking at our testing text books, I still notice a certain prominence of old techniques. Perhaps the answer to this question should be ‘no’.

There are two other questions that may be more interesting if we want to use the Systems theory perspective in software testing. The questions are: has the behavior of software changed and has the usage of software changed? Perhaps there are fundamentally no radical changes in code, but there may be radical changes in behavior or usage of software systems that could eventually lead to other ways of failure than those investigated using the classic test techniques. Perhaps there are patterns in systems that cannot be investigated using partition or path analysis.

I think it is safe to state that software usage has changed radically and that – accordingly – in the functioning of software behavioral patterns have emerged that require us to rethink the tools we use to test the behavior or functioning of systems. It is likely that Systems theory can help us find these tools. In subsequent posts I will try to investigate these new tools.


Bertalanffy, Ludwig von  – General System Theory (1968)

Chow, Tsun S. – Testing Software Design Modeled by Finite-State Machines (1978)

Elmendorf, William – Cause-Effect Graphs in Functional Testing (1973)

Forrester, Jay – Industrial Dynamics (1961)

Goodenough, John B. – Toward a Theory of Test Data Selection (1975)

Hetzel, William – Program Test Methods (1973)

Martin, James – Information Engineering (1981)

McCabe, Thomas J. – A Complexity Measure (1976)

Meadows, Donella H. – Thinking in Systems (2008)

Miller, Edward F. – Program Testing Techniques (1977)

Parnas, David Lorge – On the Criteria To Be Used in Decomposing Systems into Modules (1972)