Guided Recon Session

We - the team - are currently working on a new application which is an extracted subset of an already existing system component. In other words, we - the testers - are already familiar with the domain, the use cases and the functionality on a conceptual level. It still needs to be tested, though.

In its earliest incarnation, I deemed the application too unstable to be the target of any real test sessions. Thus, before unleashing the band of bugthirsty testers at my team's disposal, I was fortunate enough to be able to sit with the developer for a couple of days, deploying new versions to the test environment, getting an introduction to an administrative interface, being able to ask questions and getting immediate feedback - a priceless method, if you can find the time and resources.

After these most educational sittings, and getting the application to install, start and perform according to specifications in most cases, I decided to spread my recently acquired knowledge to the other testers. Also, I feared that my close-knit relationship with the developer might have caused some of his love for his own software rub off onto me, making me more forgiving, or even oblivious,to some of the application's quirks and weirdnesses. Another two pairs of eyes would be worth their weight in gold, and more.

This led to a guided recon session with two testers performing the actual work with me in the background guiding them on a very loose leash, taking notes and answering questions.

Although not an approach I would recommend for everyday purposes - three testers on the same case is not always cost efficient - the benefits of doing this during a one-hour recon session were obvious:

•  we had six eyes on the same problem area and thus less probability of any anomaly slipping through unseen
•  it quickly became apparent that our three different views on reality and what is considered "normal" (in the domain under test, specifically) enabled one of us to pick up on bugs and other strange behavior that the others did not notice
•  the de-briefing became instant - if a tester came across something that might be worth investigating, that was immediately brought up and could be discussed (for, say, a minute) and with the added experience of the sherpa and the other tester we could quickly determine whether it was worth exploring right away, or should be recorded for further investigation during another session

This approach was also very well suited for a recon session, where problems with setup, new behavior, etc could be solved immediately by the sherpa, allowing the tester to advance more easily.