In a previous post (on Test Shapes) I was somewhat practical. Here I’m going for a bit more philosophical, but with the hope that this philosophical bent does showcase an actual distinction regarding how to think about testing as an activity.

First, a few contexts points. Awhile back I had I used an example about shapes in the context of test thinking. Little did I know then that my simple example might be representative of a wider problem. In that same vein I’ve previously talked about the dimensionality of testing, which is certainly tied into the idea of shape and structure.

So first let’s get at least one term defined for our purposes. A dimension is a “degree of freedom.” It’s an independent way of moving in some sort of space. This can be a physical space, such as what we move around in every day, but it can also be a conceptual, abstract space. This is how we might refer to the dimensions of a problem we have.

Testing can be considered an abstract space but it has dimensions just as much as a physical space. Yet when you hear some people — unfortunately, including some testers — talking about testing, it often seems as if they treat testing as if it has only one dimension. This tends to be the reactive execution activity variety of testing.

This can lead to testers trying to find a “square peg” (their testing practice) into a perceived “round hole” (the rest of the development practice).

So maybe we have to change the shape of things.

A Dimensional Vocabulary

This idea of a “dimensional” aspect to testing can seem a little strange, perhaps. Certainly most of us would agree that our words and our terminology provide the shapes by which we think of things. Yet the way we use words to frame how we think is often much less important than the philosophical frame by which we approach things.

A frame, in this philosophical sense, is a specific viewpoint that tends to dictate the way you likely think about a subject or the kind of questions you are likely to ask. The “kind of questions you are likely to ask” is very much front-and-center for testers.

The important point is that using frames allows us to understand particular issues in their larger, sometimes even opposing, contexts. An example of this might be: “We want quality, we really do. But we do want to deploy something to production every hour if possible.” Does such a desire for a high release cadence threaten quality, as some argue? Or is it just viewing things along a different dimension? Such as, for example, considering speed a particular type of quality.

Or consider the situations when you are arguing for how serious a bug is and others are disagreeing with you. Is this just obstinance? Or are you perhaps moving along different dimensions of the problem?

All of this is relevant to my core topic here because geometry and topology are also specific viewpoints. So if we have “geometrical thinking” or “topological thinking,” that tells us how we approach our discipline.

Terms — “testing”, “quality assurance”, “automation” — draw associations in people’s minds. A key question for specialists is how we promote what we feel are the correct and accurate associations. But a key question before that is whether there even is a “correct and accurate” association. Perhaps instead there is a gradient of associations that can be applicable depending on context. Perhaps, in other words, there are more dimensions to this that we need to consider?

It’s my view that thinking of the distinctions between geometry and topology helps train the mind for gradients of associations. And dealing with gradients of associations is one way that specialists in testing and quality provide value.

The Geometric and the Topologic

Imagine a surface made of some thin, easily stretchable pliable material, like rubber. You can bend, stretch, twist, and deform this surface any way you want. Just don’t tear it. As you deform the surface, it’s certainly accurate that that surface will change in many ways. Yet it’s equally accurate that some aspects of the surface will stay the same.

The aspect of a surface’s nature which is unaffected by deformation is called the topology of the surface.

On the other hand, a surface’s geometry consists of those properties which do change when the surface is deformed. Curvature is the most important geometric property but other geometric properties include area, distance and angle.

So where does that leave us? As I say these next points I would ask you to try to be cross-discipline associative and think about how these phrases might be applied to testing or thinking about testing. Think of this as one of my “testing is like…” concepts but applied to geometry and topology.

• Geometry is about rigid objects that have definite shape and clear angles and lengths.
• Topology is about anything that can be deformed within certain constraints or requirements.

Another way of framing it:

• Geometry is the study of length, angle, area, and volume.
• Topology is the study of connection.

One more way of framing it:

• Geometry will tell you how long and what direction a path between two points will be.
• Topology will tell you whether or not there is a path between two points.

Now, you might be thinking, what in the world does any of this have to do with testing?

Well, consider when you have to explain the distinction between testing as an execution activity (geometry) or testing as a design activity (topology). Consider when you need people to understand that there is a distinction between artifacts (tests; geometry) and process (testing; topology).

In those cases you are very much describing a “shape” to people. Those people are making decisions about the contours of that shape based on how you articulate it to them. But that shape will be more or less constrained by the style of thinking it engenders, whether that be geometric or topologic. Sometimes you want people to draw associations that are bit more rigid and defined; other times, you want people to draw associations that are bit more flexible.

The Pattern of Shapes

In topology, objects are classified in terms of their shape in the most general sense. For example, there are only two kinds of one-dimensional space:

• a line (a curve with two open ends)
• a circle (a closed curve with no ends)

The line could be completely straight or entirely squiggly. The circular curve could be oblong, forming ellipsoids and spheroids. The curve can even be situated so as to be a square.

Basically you have a situation like this:

Things that seem fundamentally different are, in fact, not so. At least from a certain style of thinking.

Topologists are often concerned with the broad strokes of the shape of something whereas geometers want to understand the exact shape (and thus the curvature) of objects. So let’s consider some shapes a little more schematically:

You can see the lines threading each of those shapes. So how is a shape built up? Something like this:

And, of course, such a bounded space can easily morph in usually fairly simple ways:

But, of course, that’s just a shift between relatively simple structures. What gets more complicated is when there are more dimensions to how a shape can morph. More dimensions means more degrees of freedom that you have to consider. And more degrees of freedom is one of the key drivers of complexity. And complexity, ultimately, is what testers are dealing with.

Many testers seem to act like topologists rather than geometers, whereas others are much more geometers rather than topologists. But, as I hope you might be intuiting, there’s really a need for both styles of thinking. On the one hand, looking at the exact surface or shape of something and being able to measure it pretty exactly is a necessary skill. On the other hand, being able to deal with shapes that morph and deform and still make sense of them is also a necessary skill.

Spaces Guide Our Exploration

Let’s try to drive the thinking points home here and see how they correlate.

I already talked about there being only two kinds of one-dimensional space (line, circle) above and that was probably somewhat intuitive. Now consider that to a topologist the number of two-dimensional spaces is also reduced to two:

• sphere
• donut (torus, if you prefer)

Is that as intuitive? Well, consider:

Any surface without holes is technically a sphere. This includes prisms, cubes, pyramids — basically anything. A surface with one hole is called a torus but it can actually have any number of holes.

Two-dimensional surfaces that are both compact (closed up and finite in extent) and orientable (double-sided) can be classified by the number of holes they have. And this leads to an interesting situation: objects are topologically identical if they have the same number of holes.

So, yes, a donut (torus) and a coffee mug can be identical. Topologically speaking, of course. But notice how it takes effort to actually determine this and see it in the first place?

Shapes Guide Our Intuitions

This can be very much line with the thinking about equivalence classes in a testing context. We have something that’s in a different configuration (“certain holes distributed all over it”) but that is actually still identical to something else that appears very different (“because those objects have the same number of holes, even if distributed differently”). It can take some intuition, however, coupled with knowledge and experience to truly harness this.

In fact, this thinking is pretty much exactly what I wanted testers to do when I encouraged them to “act like a developer”. Being a good developer, I would argue, means being a good tester. That can be easy to see and may even be intuitive. It’s not necessarily as easy to see that being a good tester, very realistically, can mean being a good developer.

Back to our shapes, I should note that you can’t create new holes in an object, or otherwise tear it, without changing its topology. This means topologists regard two shapes as functionally equivalent if one shape can be molded into the other by squeezing and stretching but, crucially, not ripping or tearing. Consider again our donut morphing into our coffee cup:

Here again is the idea of equivalence: something can be functionally equivalent, say, how a given bug is produced when using the application in a certain way.

There’s a practical element to this. What this tends to mean is that you can consider economy in test cases because you know that just one test will expose a bug across different aspects of an application if those aspects are functionally equivalent. Ah, but this does force you to ask what “functionally equivalent” means. Does it just mean that the parts of the application do the same thing, such as, say, check for a valid email? Or does it mean that those separate parts of the application actually call the same code that checks for a valid email?

Two very different situations, right? One path has us saying that the code is broken into different parts but that (allegedly) do the same thing. And the logic in our application calls those different parts. The other path is that we have one central bit of code that does something and all parts of the application call that central bit of code. If you think back to what I’ve described, you’ll see here how we have a case of either geometry or topology.

This is a perfect example of how the physical space (the code of our application) has dimensions and we moved along those dimensions to come to some understanding. Likewise, our abstract space (the testing we are thinking about) can move along those same dimensions but with the added benefit that we apply thinking styles (geometric or topologic or both) to those dimensions.

Getting Exact

But all this talk of surfaces and dimensions and shapes can still seem a little hard to deal with unless we can measure them in some way. And, the good news is, this is exactly the problem we faced when we engaged with these concepts in other contexts.

To that end, a guy named René Descartes taught us that thinking in terms of coordinates rather than pictures can be very useful. What became known as the “Cartesian coordinate system” essentially united algebra and geometry. Descartes showed that by drawing x, y, and z axes that intersect in a point and are all perpendicular to each other, you can pin down any spot in three-dimensional space with just three numbers (x, y, z). This is easy on a flat plane but it’s not even that hard on curved surfaces:

The above is just a two-dimensional rendering of a curved three-dimensional surface. The X-coordinates represent the idea of Cartesian coordinates while the S-coordinates are those same coordinates but mapped as vectors on the curved surface. What you can get from this — and I’ll spare you the details — is the general equation of the surface as a whole. In other words, you could apply geometric thinking to get towards an understanding of the topology of what you are dealing with.

And that brings up an important point. Key to this ability to measure and pinpoint, in the exact Cartesian sense, was the potential for enlarged scope. With the coordinate system in hand, it eventually became possible to use algebraic equations to describe very complex, much higher-dimensional geometric figures that are not as readily visualized as the above. You could contemplate higher-dimensional spaces of any order — and do various calculations concerning them — without having to worry about actually drawing them.

This, too, has some parallels for the geometers in the crowd. We often have to trace the path of something through our applications, such as, say, a correlation ID. Yet if we actually attempted to draw the path this ID takes through our services and our applications, it can be surprisingly difficult. This is even more so the case as applications and services become part of a multi-cloud infrastructure.

Shapes Are Implicit in What We Do

A few times here I’ve mentioned testing solely as an execution activity. That’s one dimension of testing. As anyone who reads what I write or hears what I say, you also know that I talk about the much more important dimension is that of testing as a design activity.

And when I say this a lot of people, including testers, assume I mean about test design; i.e., quite literally designing tests. That is an important area, to be sure. However, the area I’m often talking about however is one I talked about regarding testing and design pressure.

There is an element of the geometric here (designing tests) and there is an element of the topologic here (putting pressure on the design of what is being built). So my “Cartesian elements” there might be my artifacts, my actual tests that I can perhaps situate along some coordinate system. But then there is the higher level visualization of what those tests are actually doing: attempting to guide the creation of something.

That idea of putting pressure on design (a complicated dimension!) couples with another idea of keeping design as cheap as possible cheap at all times (another complicated dimension!) and those two things do, in fact, have an impact on how we design our tests. In other words, the process (testing) can put pressure on how we design our artifacts (tests). We shift from the topologic to the geometric and back again. To put it in terms I’ve used before, we shift polarities.

What this does is also align us much closer with our requirements. In fact, we have a bit of a Möbius strip there!

A Wikipedia article (helpfully?) tells us:

“The Möbius strip is the simplest non-orientable surface. It can be realized as a ruled surface. … Any topological space homeomorphic to this example is also called a Möbius strip, allowing for a very wide variety of geometric realizations as surfaces with a definite size and shape.”

Whatever that means, right? Well, the key point there is actually how the concept is described as “topological” but leading to “geometric realizations.”

So, as you’ll hopefully have come to see, it’s not a question of is testing like geometry or topology. Instead, it’s a statement that testing is like geometry and topology.

One More Dimension …

Maybe you’ll come away from this article thinking: “Wow! Testing is intimately tied up in the structure of the universe and mathematics!” That’s fine. I’ll settle for something more modest, however. It will be more than enough for me if you come away from this thinking: “Wow! Testing is actually a multi-faceted discipline that requires a great deal of thought to articulate and practice.”

Thinking about testing is thinking about how humans interact with technology. Given that our world, and our societies, are becoming ever more dependent on various forms of technology, this is a fascinating series of dimensions to explore, travel along, map out, and try to understand.