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.

A Taste for Test

I am a tester.

Employed by a medium-sized (150-or-so employees) consulting company in Stockholm, Sweden, I currently work with software testing at a large online gaming company. The product is transaction-intensive, geographically widespread, and used by players on one end and administrators on the other, both with high demands on availability and response times.

The testing methodology we apply, and a personal favourite of mine, is largely exploratory and charter-based, drawing a lot of inspiration from The Church of Bach. At the time of writing, we have recently had a personal visit from James Bach who spent a day with us, discussing our implementation of exploratory testing, our use of charters, and delivering many helpful tips and examples. I am fortunate enough to spend my days at a very liberal workplace, where new thoughts and ideas are always welcome and the staff is well motivated and unafraid of change - if, of course, for the better.

This culture gives us testers lots of room to explore not only software, but our own processes and strategies as well. As mentioned, we are currently in the midst of chiseling forth an exploratory way of working which means running into a lot of obstacles, but also overcoming said obstacles and spawning brilliant solutions, convenient shortcuts and new ways of collaborating. In the words of James Bach, "Are you writing about this?". Well, I am now.

This blog is a window into my workday. If any of the above tickles your interest, or if you are curious about different approaches to exploratory testing or are looking for input on different kinds of test management, you will hopefully find some use for the things I write.

My intention is not to preach anything as an "absolute truth", and I don't think anyone should, but to add a trickle of thoughts to the ocean that is software testing and to, hopefully, tickle your imagination and curiosity in new ways and, primarily for those less experienced in the field, stimulate your Taste for Test.