Tester Movies and Videos

(Revised 1/2015)

Here is a list of some movies and documentaries that helped me think better about testing:

The Pentagon Wars
This movie is about a test manager trying to test the Bradley Fighting Vehicle. It shows some of the elaborate justifications people make for avoiding testing or dumbing down the testing process. It also comically depicts the process of feature creep.

From the Earth to the Moon: Part 5, “Spider”
Depicts the design, building, and testing of the Apollo lunar module. Good film to compare with the Pentagon wars, because in this case management is NOT trying to avoid tests, but still suffers from feature creep, complexity, schedule problems, etc.

From the Earth to the Moon: Part 10, “Galileo Was Right”
Depicts the process of training astronauts to be field geologists. Field geology is a LOT like testing (e.g. trying to find the right rock in big area is like trying to find the right bug), and the process is boring to the astronauts at first. NASA then finds a teacher who makes it seem like a vibrant intellectual activity. This is my favorite tester movie.

The China Syndrome
An accident happens at a nuclear power plant. Jack Lemmon plays a manager trying to figure out what happened and why. Interesting scenes depicting reasoning about a technical system, and the squeeze between quality and cost.

All The President’s Men
Depicts the Washington Post’s discovery of the Watergate cover-up. The plot is a little hard to follow. But it depicts something very much like a technical investigation and shows how the paper struggled with the quality of evidence. Some of the dicussions in the movie remind me of bug triage meetings.

This movie is about a victim of short-term memory loss who’s trying to find his wife’s killer. The story is told backwards, and dramatizes how the man must use a notepad to record information so that he won’t forget it a minute later. Apart from being a thriller, it’s an illustration of the difficulty of writing clear specifications. I also find it a meditation on the relationship between defined process and people.

Death By Design
Artful documentary about programmed cell death (cells in our bodies that die on command). Approaches the subject from a general systems perspective. This is relevant to testers because it raises many interesting issues about how our tests and products become obsolete and how we must cope with changing conditions.

Plane Crazy
Three part documentary about a man who tries to design and build his own airplane in 30 days. There isn’t much testing in this series, but there are breathtaking examples of developer self-delusion, and wonderful examples of bad teamwork and great teamwork. Good fodder for discussing risk analysis and team dynamics.

Clear Vision: Dewitt Jones
This is a video of a keynote presentation by photographer Dewitt Jones. He gives many specific and entertaining examples of creativity principles at work in photography. This is relevant to testers because we too have to “see” the right things at the right time in the right way in order to find bugs. I’m not sure if this particular video is still for sale, but Jones has other similar videos offered on his web site.

21st Century Jet: The Building of the 777
This is a multi-part documentary about the project to build the Boeing 777. Lots of good details about how complex projects work.

NOVA: Lost Roman Treasure
Illustrates rapid testing in the domain of archeology. Racing against an impending flood caused by a dam downstream, archeologists in Turkey try to excavate a whole city, searching for historical treasures. Using techniques reminiscent of rapid testing on software projects, they succeed: “The discovery of the mosaic in Zeugma has stunned the world of archeology and prompted an international outcry. The archeologists convince the Turkish government to give them time for another series of short digs.” See transcript here: http://www.pbs.org/wgbh/nova/transcripts/2911_zeugma.html

NOVA: Volcano’s Deadly Warning
Depicts the development of a new way to predict when volcanoes will erupt. The relevance to testing is that the guy who figured it out was able to do so partly because of his unusual education. This dramatizes the value of having diverse people on a test team: “It would take a scientist with an unusual eye to find the right signal hidden in the noise. He trained in aeronautics and physics, but then, intrigued by volcanoes, Bernard Chouet spent years trying to decipher their secret code.” See transcript here: http://www.pbs.org/wgbh/nova/transcripts/2913_volcano.html

Physics By Inquiry: A Video Resource
This is a video about the Physics By Inquiry program at the University of Washington. It depicts high school science teachers who struggle to learn physics through experiments only, so that they can teach it more authentically. When they put aside their knowledge of the “right answer” they often discover that they don’t really know how to conduct a scientific inquiry.

Towering Inferno
Maybe not a testing movie per se, but one that has a two minute scene with Steve McQueen (his first scene in the movie) where, as a fire chief, he takes control of the firefighting effort. It is this scene that provided my impressionable mind with a template for how experts behave under pressure. See him grill O.J. Simpson? That kind of thing is what I do when I drop into a project and size up the testing situation.

Tim’s Vermeer
Documentary about a fellow who, though not a painter, invents a mechanical device that allows him to recreate a great painting. Full of analysis and reasoning that appeals to testing and scientific minds.

Apollo 13
Technical problem solving under pressure! One problem after another! Lives at stake!

A man questions the sacred cow truths of his profession, applying statistics systematically to the building of a sports team.


(Revised: 1/2015)

As a process guy, I often hear the term “common sense”. It’s a strange term. Like “luck” it’s a concept that generally brings an end to inquiry, because it’s a reference to magic. “That’s just common sense” seems to be a signal that “I haven’t thought about that, and I’m not prepared to talk about it, either.”

Same with the word “obvious”, sometimes. When you ask a technical question about a product and a developer says that the answer is obvious, you can generally count on that to mean that he hasn’t discussed the matter with anyone. Not discussing it, the team is likely to be oblivious to risks associated with it, if there are any.

It is the tester’s duty to keep an eye on things that seem unimportant, yet might be important after all.

Just because something about a product is obvious to one person, doesn’t mean it’s obvious in the same way to everyone. It may be especially non-obvious to a user.

The obvious leads to the oblivious, and that makes me nervious.