I have long maintained that testing is ultimately about thinking. A lot of your work is going to be predicated upon spotting incongruous elements (whether in documents or application code), resolving potential ambiguities in what you read or see, and dealing with potential inconsistencies or outright contradictions. Sometimes people will frame problems in such a way that your ability to “solve” or deal with the problem effectively is compromised from the start.

A good way to practice your thinking skills is to apply them in an entirely different arena than software testing.

A Time Travel Scenario

So here’s a scenario for you. Let’s say you start out in the present year (which, as I write this, is 2011) and you are standing near a huge oak tree. You then utilize your handily available time machine to go into the future to 2012 — exactly one year later. There you see the huge oak tree is still standing. So now you go back to the year 2011, shortly after you originally left. Let’s say you left for 2012 at exactly 11:00 AM in the morning. So you return at 11:05 AM. Now you chop down the tree.

With me?

Okay, so, now say that you travel back to the future of 2012, one minute before you appeared there the previous time.

Consequences of the Scenario

First: is the tree still there? (Let’s just say there’s no chance it could grow back in only one year.) If yes, how is that possible since you chopped the tree down back in 2011? If no, how is it that you saw a tree there when you visited 2012?

Second: since you arrived back in 2012 a minute before you originally arrived there, would you (if you waited around a minute) see your younger self appear and look at the tree? Or would you see your younger self now looking at a stump? If you think it’s the former, how would this be possible since you chopped down the tree in 2011? If you think it’s the latter, why do you not remember seeing a stump when you “first” appeared?

Believe it or not, I find that how people think about concepts like this gives some indication of how they might think about development and testing or, at least, how to approach those disciplines. Putting a scenario like this in a time travel concept allows me to use this as a bit of a “brain teaser”, for lack of a better term, that hopefully encourages thinking and that serves as lessons to learn about how people think and about how people question what they think about.

Great. So what’s the point?

One of the first things to note is that this kind of scenario depends on what viewpoint of time you have, assuming you’ve given it any thought at all. Many people tend to have an inherent notion of how time “works”, even if they aren’t aware of it.

Lesson: Something we all experience, like a project or an application, can be the same but we all experience and/or interpret it in different ways. Without questioning to determine if we share a common viewpoint, problems can ensue. For example, perhaps my time travel scenario was accounting for “parallel universes” or “multidimensional time” — but without any clarification there is no way to determine that. Yet how you respond to the scenario problems very much depends on that viewpoint.

Going with the idea of self-consistent time travel in a single timeline (or single temporal dimension, to be more accurate), you would not have seen the full tree in 2012 in the first place, when you first time traveled to that year. Thus the premise of the “paradox” that I present is (potentially) undermined right at the start.

Lesson: Sometimes you have to question the very basis of what you are being told. Yet notice that the other side of this questioning is recognizing the assumptions inherent in the basis of what you are told. It’s not so much that those assumptions are wrong; rather it might be that the way something has been stated relative to those assumptions is “paradoxical.”

So: you would not have seen a full tree when you first visited 2012 in a single timeline model. You would have, instead, found a chopped down tree or the stump. That’s a key point: the tree would not have been there in the first place. So that means that if you did travel back to that same time in the future (just prior to when you appeared the “first” time in 2012) you would see your previous self appear and see yourself looking at a stump — which is consistent with what you would remember doing and remember having seen.

Lesson: Sometimes a fundamental assumption of the whole setup needs to be questioned. The statement was simply given to you that you had traveled forward and saw the tree; the emphasis on the rest of the scenario was on how you then went back in time and chopped down the tree and then went back again to see what your past self would have seen. In other words, a lot of further information was given that masked the fact that a major assumption was made: namely, that you definitely saw a tree when you first traveled to 2012. Sometimes you have to revisit what seems like the earliest phase in a project or discussion. Sometimes you will find that things are stated as a fait accompli and that is perhaps erroneous.

The Core Problem

The problem people tend to have with a time travel situations like I have presented boils down to a single question: What if I decide to do the exact opposite of what I have seen or done?

The logic seems to be: “If I’ve seen a full tree, I’ll chop it down. If I’ve seen a stump, I won’t chop it down.” Certainly from a “free will vs. determinism” point of view, that becomes somewhat difficult at this point for some people.

And yet …

… notice that this difficulty is not necessarily because of the situation itself, but rather by the way people formulate — or choose to interpret — the situation as it was specified.

Lesson: People can introduce complications into any scenario and those complications can speak to any specifications of the scenario (application/project/etc). It’s important to realize that complications can occur solely by the way a scenario/problem was framed or stated. And that goes back to the first and second lessons: be aware of the assumptions, such as a single timeline model, that are inherent in how a problem is framed or stated.

Also be aware that I framed the problem such that I force you to try to “explain” a contradiction, but I never justified why a contradiction was necessary in the first place.

So, has time travel taught us about testing?

In a way, yes. Rather, what I think a scenario like this has done is taught us how to think about testing because, ultimately, testing is a very broad subject. You can test assumptions. You can test statements, both written and verbal. You can test scenarios that people present to you. Not all testing has to be with test cases or program code but instead can involve using your cognitive skills and applying critical thinking to what you read and what you are told, focusing on three core areas that testers should hone: spotting inconsistency, resolving ambiguity, and highlighting contradiction.

As an added bonus to my loyal readers these lessons should serve you well if you ever find yourself in a time travel situation.