Tonight we spent the after dinner session taking a first crack at describing what we’ve learned from the session so far. I imagine we’ll be revisiting the topic again in the next couple of days, but here’s the slightly annotated list of points we came up with tonight…

• Managing XP with cards is like chartered exploratory testing
• Easy to pair program with people new to pair programming
• Testers seemed like programmers when pair programming
• New environment + code led to thrashing
• James wants to pair for an hour or so where his role is specifically to be a tester rather than a programmer.
• Testing requires different mindset than programming (“How does this work incorrectly” vs. “How do we make this work as simply as possible?”)
• Still need a system testing phase
• Purpose of pairing is to make life easier for both developers and testers (developers can fix bugs while they’re still focused on the code, testers don’t have to repeat work because they know what testing the developers did)
• Pairing can improve trust between testers and developers, and increase efficiency. Less looking over shoulder and more doing something collaboratively
• Acceptance testing is a pain to setup
• Need standard approaches (cookbook/patterns) for acceptance testing
• Hard to remember to unit test when developing your acceptance test framework
• Hard to know whether unit testing for an acceptance testing framework is needed
• Lack of commercial support for open source dev & test tools leads to wasted time
• Able to cite examples to refute nonsense about XP/testing
• Training, experience, and instincts in testing don’t necessarily translate well into unit testing (instincts tell us to filter out tests that are too trivial)
• Change detection is different than testing
• Identifying opportunities for useful unit tests is a skill worth learning
• Developers seem to be working with more junior testers
• Testers don’t have to be adversarial
• Inclined to thinking more about magic tricks as metaphor for thinking about tests (You watch a trick, and what did you see?)
• Different metaphor = law enforcement investigation (testers as detectives)
• Learned why pair programming can be an advantage (John made an observation that ours is the only profession where it is considered abnormal on two people working together to solve a problem, Cem suggested lawyers as another and doctors for anything which does not require litigtaional support, then asked to what extent the practice of consulting others in medicine is the result of being sued for malpractice)
• There are many types of testing some of us didn’t know about — both crazy and interesting
• Good exploratory testing does not mean “monkey sitting at keyboard”. Instead there’s a discipline and structure to it.
• Exploratory testing articles: James’ “Exploratory Testing Explained” and “Exploring Exploratory Testing” (which Cem and I wrote for this year’s STAR East conference)
• More rigor to than some of us realized. (Comment was made in reference to James’ Satisfice Heuristic Test Strategy Model
• Recommendation of How to Solve It by George Polya and other works by him as well.
• Really interesting we didn’t use FIT, and we need to explore why. It was speculated that had Rob Mee been here, we might have focused more on FIT.
• Testing is messier than XP admits
• Acceptance tests may be written like unit tests
• FIT Might still happen
• Regret that we didn’t use FIT
• Eagerness to code deferred acceptance tests
• UML finally makes sense when animated
• Excited by “Iron Man CRC” (aka “Naked CRC”) (don’t write anything down, but use blank cards to move things around) [Editor’s note: I missed this. I’m going to try to get a private showing, but until then, I don’t know anything more about this :)]
• Happily surprised pairing was as comfortable as it was
• “Tipping Point” — (This is mine, so i get to explain it here. We couldn’t get it to a succinct bullet point that I liked. What I was trying to express was that while I’ve been aware and fairly comfortable with agile development practices, they hadn’t crystalized into my style. I could look at a project and see how agile techniques would work, I could follow the reasoning for the benefits, but I had to consciously decide that I was going to use agile development principles on any given project. After this week, it feels much more like a natural thing for me, and I think I’ll be building agile practices into my personal all-the-time approach to developing.)
  Distributed pairing (Chris does this as his job — team is colocated with the exception of himself. He’s found that remote pairing is no less efficient than when he’s on site. He uses these tools: WebX, PlaceWare, NetMeeting, and VNC. He’s presenting a paper at ADC next week that he thinks he can send out once the conference publishes it. For him, Placeware has been the best, but it’s also the most expensive. His team uses standard phone lines for the audio portion (they all have headsets)).

  At this point, we declared a night.