What we were doing in this story is called exploratory testing—simultaneous test design, execution, and learning. It's the opposite of scripted testing (pre-scripted manual tests or automated tests). I combined purely manual exploratory testing and interactive automated testing to narrow the cause of the problem. (I call using the computer as a tool in testing computer assisted testing, a term I picked up from Cem Kaner.) I would run part of the test in an automated fashion, watching the script run on my screen, and then I would take over by hand to do exploratory testing at the point in the application where I wanted to focus. Gerard Meszaros describes this type of partial automation as creating a "test fixture" for exploratory testing.
Jason, the developer in my story, was also doing exploratory testing. When he was running automated unit tests, changing the inputs based on results and analyzing the code, he was doing automated testing interactively. This interactive nature of testing is a key component of exploratory testing. When tests are prerecorded as procedural test scripts, automated unit tests, or automated acceptance tests, they run without an interactive element. Most automated tests run without any human interaction. Many pre-scripted manual tests don't have much interaction, either. An important part of exploratory testing is that a tester is able to change behavior based on new information provided by the program. The tester can redesign test cases and execute them immediately based on new information. Pre-scripted test cases often discourage this behavior, and machines running automated tests aren't intelligent, so they can't change and adapt without being programmed by a human.