Geometry is about getting from one place to another. It’s about looking at where we are and where we want to be. Or, perhaps, it can look at where we are now and help us backtrack to where we came from. However you use it, geometry takes place over a certain region of space and time. Space and time — whether looked at in the context of cosmology or just on our projects — is all about dimensions. So let’s talk about this a bit.
Author: Jeff Nyman
Anything I put here is an approximation of the truth. You're getting a particular view of myself ... and it's the view I'm choosing to present to you. If you've never met me before in person, please realize I'm not the same in person as I am in writing. That's because I can only put part of myself down into words.
If you have met me before in person then I'd ask you to consider that the view you've formed that way and the view you come to by reading what I say here may, in fact, both be true. I'd advise that you not automatically discard either viewpoint when they conflict or accept either as truth when they agree.
Testing and the Project Singularity
In mathematics, a singularity refers to a point that is basically undefined because it is infinite or what is known as degenerate. In physics, a singularity is a “region” that has infinite density with an infinitesimal volume. So what does this extreme concept have to do with testing? Well, let’s talk about that.
Testing Is Like Cartography
What do maps do? Well, let’s think about how they great created. They get created by humans. So maps essentially distill the experience of others for the purpose of helping you understand a particular terrain. Maps help you get from where you are to where you want to go. Maps thus serve as a way to package up a vicarious experience by providing a representation.
Cartographers are people who create maps and it is very much a discipline. Further, it’s a discipline that shares a lot with testing. So let’s talk about that.
The Shifting Polarities of Testing
Everything we rely on is in the past. Even the very moment of “now” became the past just as you read this. As the future gets here, it becomes the “now” and — you guessed it — moves into the past. So while we may build services and applications for the future, our work immediately becomes part of the load-bearing struts of the past.
This reality, while simplistic sounding, has important ramifications because it means we have to move between polarities.
The Character of Projects
I was going to title this “The Irrelevance of Agile” but that struck me as an unfair title and not entirely indicative of what I wanted to focus on. Testers will periodically be involved in the “Is Agile Dead?” debate. Or even the “Agile is (Once Again) Dead” debate.
I’ve found these discussions to be an emotive area to wade into so I want to approach this from a different angle. This is me experimenting with thoughts rather than claiming to have any answers, so expect a bit of this to be somewhat muddy as I feel my way forward.
Testing and Things That Matter
I wrote about how testing is like writing fiction. Testing can actually influence reading fiction as well. And reading fiction can be great practice for exploration in a lot of ways. I recently came across a good example of that.
Testing and the Human Element of History
What an awful blog title, huh? Testing and history? What am I even talking about? And the “human” element of history? As opposed to what? Have you ever seen a blog post that starts with such short sentences ending with question marks? Utterly awful. It’s like splitting infinitives. Or running sentences on and on (and on). Still with me? If so, let’s talk about history. And science. And the human aspect of both.
A Logic of Testing Thought
The more I talk with testers, the more interesting it becomes to consider how the industry has evolved — and often how testers failed to evolve with it. We still see testers talking about concepts in testing as if this was the early 1980s. Is this a bad thing? I think so but let’s talk about it.
Testing Is Like …
I want testers to stop trying to “solve” the problems they’ve allegedly been trying to solve for decades now. I want testers to start looking at testing as a discipline that has a broad-focus, wide-angle lens. I want testing to start solving the real problems, including the ones that it has painted itself into. I want testing to get out of the reductionist and into the ecological. Let’s talk about this a bit.
Testing Helps Us Understand Physics
In our testing industry we’ve borrowed ideas from the physics realm to provide ourselves some glib phrases. For example, you’ll hear about “Schrödinger tests” and “Heisenbugs.” It’s all in good fun but, in fact, the way that physics developed over time certainly has a great deal of corollaries with our testing discipline. I already wasted people’s precious time talking about what particle physics can teach us about testing. But now I’m going to double down on that, broaden the scope a bit, and look at a wider swath of physics.
Reframing Test Interviews with Gamification
In our testing industry we’ve borrowed ideas from the physics realm to provide ourselves some glib phrases. For example, you’ll hear about “Schrödinger tests” and “Heisenbugs.” It’s all in good fun but, in fact, the way that physics developed over time certainly has a great deal of corollaries with our testing discipline. I already wasted people’s precious time talking about what particle physics can teach us about testing. But now I’m going to double down on that, broaden the scope a bit, and look at a wider swath of physics.
Continue reading Reframing Test Interviews with Gamification
Test to Put Pressure on Design
In a previous post on test dogma and tradition, I talked about the famous “test pyramid” as an example of what people cling to as means of explanation. My concern there was that people often run too far with this or draw the wrong conclusions from it. Let’s look at a particular example of that.
What Can Politics Teach Us About Testing?
In the United States we are currently going through one of our normal rounds of political craziness as we move towards a new election. This is not a political blog and I don’t want to add to the crazy. Thus this post will not discuss current political viewpoints, whether for or against, and will have nothing to do with current candidates. Rather this post will discuss one specific aspect of politics that has a historical context that relates to how our testing industry has evolved and continues to evolve.
Dance of the Automation Marionette
As many automation engineers know, we’ve been dealing with Marionette, the successor to the Firefox Selenium driver, for some time now. We’re starting to see a light at the end of the tunnel. However, I’m finding a lot of teams are still struggling with what all of this means. Here I’ll talk real briefly.
The Challenge of Testing
Awhile back I talked about what makes testing complicated. To be honest, that post is embarrassingly written as I look back on it. That said, I think there is some value in what it says. But to show how my thinking has refined, as well as become a bit more operational, let’s piggy-back on my previous “code as specification” posts and look at why testing is challenging.
Driving Design with Code as Specification
This post follows on from my code is a specification. I highly recommend reading that post to get the context because here I’m going to add a bit to the sample code from that post. This is being done to illustrate the idea of test code and production code working together to act as an executable specification. Here I’m going to focus a bit on how this has relevance to the business as well.
When Code Is The Specification
Early on I talked about business needs becoming specs that become code. More recently, in my modern testing posts, I talked about the idea of production code being the specification of behavior. I wasn’t necessarily very descriptive in all of that, however. Let’s see if I can do better here.
The Use of Tradition and Dogma in Testing
It’s become tradition — with a bit of dogma — to point to triangles and quadrants to “explain” things about testing and development. A good case in point is presented in the article Agile Testing Automation. My goal is not to critique the article but rather to use it to highlight what I see as some of the problem. So let’s subject tradition to some rational inquiry and let’s subject dogma to a bit of scrutiny.
The Integration Pact
In previous posts about the integration / integrated distinction (see part 1 and part 2 of that series), I talked about how there is in fact a distinction and provided a little rationale behind why this distinction currently matters. So now let’s talk a little “around” the concept of integration — not integrated — and see where this takes us.
Integration and Integrated, Part 2
In the previous post in this series, I talked about the counterargument of there being no distinction between integration and integrated. That post ended on a question. In this post, I will start from the presumption that there is a distinction between the terms and explore that a bit.