Pair testing can be challenging for a several reasons, not the least of which is just finding the time for it. But I still try to do it when I can. It's more difficult now that I'm a manager. I haven't really tested in months, much less pair tested. I need to work on that... but I have other things I need to work on too. Always to much to do.

When I'm pair testing with someone for the first time, I'm looking for some specific things:

• How does the person I'm pairing with like to work? Do they take notes realtime? Do they use multiple screens and laptops, multitasking their work? Do they use tools? If so which ones?


• How does the person I'm pairing with like to communicate? Do they talk out loud? Are the good at stream of conscious speaking? Do they IM a lot? Do they write stuff down, and if so, what?


• How does the person I'm pairing with like to test? Do they use scripts or charters? Do they have data handy? In what format, a spreadsheet, text files, database, other? Can I see them using specific test patterns, heuristics, or techniques? As their testing unfolds, is it always the same or does it change? How does it change?


• What does the person I'm pairing with value? What's a bug to them? How do they assess priority? Who do they view as their stakeholder(s)? What information is credible? What oracles are credible? What parts of the system do they focus on?


• How does our dynamic come into play while we are pairing? If they are a programmer (testing their own code or not), what words do they use or concerns do they exhibit that would tell me that by their testing? If they are a tester, what words do they use or concerns do they exhibit that would tell me that by their testing? If I manage them, does that affect their behavior in a noticeable way? (And how would I notice?)


• How do I behave while we're testing? Do I take control? Not speak up? How do I feel as we test (about the product, our testing, my interaction with the other person)?


• What do we do after we test? Do we combine and clean up our notes? Does one of us write a script (manual or automated) for anything we tested? What defects get written up, which ones don't, and what information goes in them? What follow up charters do we think of? Do we both do a debrief?

I suppose that somewhere in there I also find time to think about the testing that I'm suppose to be doing. But I can't be bothered by those details. :)

A while ago I answered the following question on SearchSoftwareQuality.com's Ask The Software Quality Expert: Questions & Answers:

It's been my experience that only the senior testers I work with do exploratory testing well. Is experience a requirement for exploratory testing?

Here is a clip from my answer:

Experience isn't a requirement for exploratory testing, but certainly, as with anything, experience can help. An "experienced" Java programmer (whatever that means) will (in theory) write better code then a Java programmer out of college. That doesn't mean the Java programmer out of college can't write code -- he can. He just doesn't have the same experience to draw on.

The same is true with exploratory testing. Experience can be good, but it isn't required. Notice I said can be, because the wrong experience can be bad.

You can find the full posting here.

Part of that posting lists the skills and tactics used by exploratory testers. It’s also worth noting that version 1.6 of the list is out and posted on the Satisfice website. It has some stylistic changes to it.