I already tried to figure out if time travel can teach us about testing and I wondered if military history might also have a few lessons to share. I was marginally surprised that when I saw the recent film World War Z, I found myself thinking about testing.

Just to be clear, I got nothing from the movie regarding how to write test cases or how to better distill requirements. That’s not the kind of testing I’m talking about. Here I’m talking about the kind of thinking that goes on during testing or at least during projects where test thinking has to be applied. Also, it’s not so much the hordes of zombies that got me thinking this way, but rather the way people react (or fail to react) to the zombies that offers some lessons.

Find the Crumbs

There’s an interesting bit of dialogue in the film. As our hero Gerry Lane (played by Brad Pitt) is on his way to South Korea to determine the cause of the zombie virus, his fellow investigator and virologist Andrew Fassbach says:

“Mother nature is a serial killer. No one’s better, more creative, but, like all serial killers, she can’t help the urge to want to get caught. And what good are all those brilliant crimes, if no one takes the credit? So she leave crumbs. Now, the hard part, why you spend a decade in school, is seeing the crumbs for the clues they are. Sometimes the thing you thought were the most brutal aspect of the virus, turns out to be the chink in it’s armor; she loves disguising her weaknesses as strengths.”

I wouldn’t quite say bugs are serial killers, but some of what the virologist talks about resonates a bit with me. Whether bugs “want” to get caught or not is irrelevant; what’s more relevant is that they do leave crumbs. But sometimes the trail of crumbs is very little. And sometimes the crumbs are hard to distinguish among all the other stuff. So what we do — the hard part — is to see the clues for what they are.

In terms of applications, sometimes we have to look at elements like the architecture or the nature of the programming language used, or even the programming approach we are using. Sometimes the most complicated elements of our applications are the chink in the armor that lets us find bugs because in those complicated areas are where the interesting boundary conditions lie.

Many times testers are the group that is responsible for ferreting out knowledge of how things are working and determining whether or not that is how things should be working. This is yet another case of looking for those bread crumbs. And those crumbs sometimes extend to people, who hold the knowledge in their heads. So we become like forensic analysts, gathering evidence both from people and technology.

As you’ll notice, Gerry also brought a great team with him, one that had differing skill sets. Make sure you do the same when you set out on your crumb-finding … err, bug-finding expeditions.

Allow for the Tenth Person

In the film, things are not going well for us. Governments are toppling. Cities are being overrun. Law enforcement and military structures are breaking down. No one was prepared for the magnitude or nature of what they were facing.

Well, except, apparently, for one group. It seems that shortly before the zombie uprising began, Israel built a huge wall. They built this wall on the assumption that zombies would soon be overrunning their country. Now, that’s a pretty specific threat to be guarding against and, most would admit, a fairly improbable threat. Yet — they were right! But why did Israel think they needed this wall in the first place? How did Israel actually know the zombies were coming?

As we learn, the Israelite leadership had received a message from India where a general says that their armies are fighting a massive enemy army that is classified as “zombie.” Not surprisingly, when Israeli intelligence learned of this, they felt the message was ridiculous and felt pretty safe in ignoring it. Except for one person: the tenth person.

The idea is fairly simple: when nine people agree on something, it’s the tenth person’s duty and, in fact, obligation to disagree no matter how utterly ridiculous the alternative may seem. In this case, the improbable idea was that zombies were somehow overrunning India. The tenth man proposed that Israel should prepare to keep a lot of potentially undead people from overrunning their own country.

The nine people here clearly represent the idea of group think. The tenth person forced them to consider an alternative view point, one that was not popular and was even considered potentially ridiculous. Our job as testers, according to test consultant James Bach, is to “question emperors and tip sacred cows.” This is an oblique way to describe that our job is to always be questioning and to sometimes go against the grain, even when that’s not the most popular way to go.

Beyond making sure you allow a way out of group think, there’s a couple of things to note here. In the film, the tenth person spotted the one thing that mattered in the report: “zombie.” And he realized, if true, this threat needed to be dealt with, even though it seemed potentially remote. It wasn’t a problem for Israel yet — but he was betting that it soon would be. That’s foresight at a couple of different levels and I think it’s something testers must have. They have to look for situations where perhaps just one important element may be lurking on the horizon and it may not be a problem yet, but it certainly could become a bigger one if not dealt with.

I mentioned in a previous post how a team I worked with had ended up with thousands and thousands of test cases. A tenth person mentality could have probably stopped certain bad habits from forming early on by simply recognizing that they were forming in the first place. Developers routinely have to do this when they spot what are called “code smells” and testers likewise have to be on the watch for “test smells.” Well, maybe that smell is a single zombie just waiting to grow into a horde.

The point of the tenth person approach is not just to do the opposite of what you initially think you should do. It’s purpose is to constantly question your beliefs and force yourself to examine all of the evidence, not just those elements that support your ideas or confirm what you want to believe. The tenth person approach also puts in place a mechanism for you to never become complacent with what you have done or what you are doing.

Now, all this being said, Israel ended up getting overrun. Their wall turned out to be not so great.

The nature of the threat and how it acted was not something they could cope with. So they could stop a few zombies. Maybe even dozens or hundreds. But they couldn’t stop thousands. So maybe here the challenge was that the solution was not appropriate to the threat. After all, due to the nature of the enemy, the wall ultimately did them very little good.

Sometimes we have to key in on one thing to the exclusion of others. In our cases, that one thing might be a threat but it may also be an opportunity. Yet there’s a difference between thinking like the “tenth person” and taking action. This is where testers have to be careful when they propose taking a risk, such as getting rid of a pre-existing test management system, changing a test automated tool, using a different approach to writing test cases and so forth.

Given the nature of how testing, as a discipline and practice, evolves and given its close relationship with quality assurance, I believe that all test teams should strive to have a “tenth person” and encourage such.

Look For the Patterns

In the film, Lane begins to piece together what might be a weakness in the zombies. He realizes that they are not attacking some people. However this realization is based on certain observations that were, for the most part, disconnected. It involved a few phrases he heard people say and a few situations where he noticed how zombies were or were not attacking, usually when he was himself running for his life — such as when he noticed the zombies not attacking a kid in their path:

This is important: looking for the patterns. It’s sort of an extension of looking for that trail of crumbs and finding patterns in the evidence that we manage to accrue. Unlike Gerry Lane, perhaps we’re not distracted by running for our lives while doing this, but we are often distracted but other project realities or sometimes by the personalities of the people involved.

Now, we could ask: couldn’t anyone have figured out what Gerry Lane had figured out? It just happened to be him; but it could have been anyone. Err … right? The short answer is, no. Using our senses, making observations, finding patterns: that’s a start. But there are two powerful steps beyond that kind of observation, which make all the difference. Carrying out deliberate, controlled experiments, instead of only watching things as they unfold. Along with that is carrying out quantitative observations: making measurements, and trying to find patterns in whatever you are measuring.

That pretty much sounds like what we have to do as testers, right? Intelligence is more than just about finding facts. It’s about properly analyzing those facts. It’s about drawing the right conclusions, even based on incomplete or misleading evidence. That last point is certainly important because many times what we have is little more than speculation. But speculation is powerful as it can lead us to investigate.

I should note that in the film Gerry Lane as a United Nations Investigator. He was not a virologist. He was not an expert in human relations. He was certainly not an expert in zombies, assuming there is such a person. The point here is that Lane was not an expert in the zombies or the virus that was reanimating them. This lack of expertise can be a strength. The nuclear strategist Herman Kahn coined the term “educated incapacity.” This is the idea that experts often miss things because they are experts and, as a result, have set-in-stone perspectives that they cannot see beyond. (Maybe they need a “tenth person”?)

What I’ve seen is that testers who are “experts” or who have specialized tend to have viewpoints that are of the “set in stone” variety and often lack the flexibility needed to look at situations without the eyes of an alleged “expert.” Thus when dislocation happens, they get overwhelmed.

Not only this, such testers tend to set up approaches to their activities that allow them to get overwhelmed. After all, those experts in Israel built that wall — and that didn’t do them much good, did it?

And the experts presumably set up orderly evacuation plans for the cities and the airports but that didn’t work out so great either.

Movement is Life

At once point in the film Lane is in an apartment building after things in the city start to go south. As his family hides out with another family, he realizes the situation is untenable and he tells the others that “Movement is life.” His point basically being: “If we don’t do something, we’re going to be in trouble.” Put another way: “The status quo may just kill us.”

What this really says to me is that you have to be in motion in order to stay alert and be ready to react to changes. Becoming too static can trap you. I see this all the time with testers who, for example, don’t keep up with their skill sets. To me, they have not engaged in the notion of “movement is life” in the sense that continual movement in your skill set keeps you always learning more and becoming more marketable. This is certainly not just the case with testers. I have routinely run into developers who seem to have also settled on their own personal status quo.

Likewise, within a project, sometimes you see the oft-stated “analysis paralysis.” I see this most often when testers stop to debate, ad nauseum, what testing tool to use or what programming language to use to write their own home grown solution. Sometimes you just have to move forward and see what happens. It may not be the “best” course of action, but it is at least a course of action and at some point you will only learn by continuing to move forward.

Yet, do keep in mind that the zombies had movement as well — and they weren’t life!

Finally, I would note that one thing some teams fear to do is even consider a “scorched earth” policy. But sometimes that’s exactly what you need to do; you need to purge that which came before, just as the Israelites were forced to do when they realized their approach was no good and was not capable of being salvaged:

So, yes, your movement can be chaotic and actually lead you into more problems, including the need to entirely destroy everything you built up. But if you have a good team that follows crumbs and looks for patterns, and relies on a tenth person, you can offset the chance of your movement from being as destructive as that of those zombies.

So did zombies teach us anything?

As I said earlier, probably not. But the zombies themselves may not be the true threat. The true threat is if we don’t contain and/or control the situations that allow zombies to be a threat in the first place. And that same kind of thinking is often what happens with our projects. Bugs are not the true threat. Neither are slipped schedules, bad requirements, or unskilled team members. The true threat comes from how well we spot the trends that lead to those problems (“zombies in India!”), how we choose to deal with those situations (“look for patterns in how the zombies act!”), how we choose to avoid dealing with those situations (“build a big wall!”), and how effective and efficient we are in building the right solution to handle the problems (“find why the zombies don’t attack some people!”).

Incidentally, purely as a side note, if you are curious about the software they used in terms of making relatively realistic looking mobs of the undead via CGI, you might check out this video on the making of digital zombies. You can also check out how some of the visual effects were performed. It’s all pretty cool stuff!