Exploratory testing

Time to get the hiking boots, walking sticks, pen and paper it is time to go where nobody thought of going in a testing cycle, the weird and undocumented paths that could happen in the product under question: exploratory testing.

OK so there is no hiking boots or walking sticks needed, I was adding dramatic effect, although you will need a pen and paper to document what you do. Well it is the digital age so some form of documentation software will do.

Here I will give my views and insight on this tool in the vast toolbox of a QA professional that can use and help improve overall quality of the product. Now I am sure as you are reading this a flow of questions, comments or just plain disagreement to what I have said. Perfect, that is what I am looking for. As some of you know I am a regular on SPaMCAST with Tom Cagley in a segment of the same name of this blog. I wanted another avenue for those that listen in addition to those that will just read here to foster conversation that will generally help this great discipline call Quality Assurance.

So on to the topic at hand, exploratory testing. When I hear exploratory testing I have this vision of going off the beaten path, basically trying something that was not thought of to see what happens. There is plenty of documentation out there that states the same thing. As I said it is a tool, and as with construction there isn’t one sole tool that will do everything you need to build something, so we should not be reliant on exploring different paths as the only method for QA work.

Exploratory testing, in my opinion, is putting on the hat of a user for a short period of time. We have all come across some form of ticket from users where they have done something odd like open a bunch of windows in a workflow then went back to a previous window in the flow and made changes, then the system would freeze up when trying to save because it didn’t know what to do with the transaction. This example sticks with me because it was one of my first tests I ever did as a UAT tester at the start of my career. My thought process was simple, what happens when I do this?

With my teams now I ask that there be some time set aside as: User time. Basically they go in and do whatever they want, documenting what they do of course. Just to see what happens. This is usually done at the end of a cycle, if time allows, so that planned work on the changes are not impacted. We have also had testing parties, or Bug Blitz as we called them, and we get not only the QA team involved we get all the stakeholders involved in running through the applications. Our last session we had a few executives come in and play around. We found a few things, nothing serious although the biggest intention of the outcome is to give the understanding to everyone what the QA team goes through in a short period of time.

In Explore IT! by Ellisabeth Hendrickson she uses the analogy of a net and testing when trying to find issues. The more testing that is done the tighter the weave of the net becomes. There is still a risk of issues popping up in production, as we all know a system is not fully tested it is the elimination of risk. Exploratory testing is adding a few more strings to the weave to catch what we can.

The additional benefits of Exploratory testing is improvements in requirements. Think about it, why was it decided to go off and try something on a system that was not documented? To see what happens. The end result is driving out a new way of thinking for those that are documenting change. Now with the knowledge they have from this out of the box thinking they will now have to keep in mind that when developing the WHAT  in a change they will add some additional detail so things could be avoided.

Use a tool right and the quality will be there. Use it wrong and something will get built, unfortunately it will not look like the way it was intended.