Go where nobody thought to go

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 the overall quality of the product. Now I am sure as you are reading this a flow of questions, comments or have reasonable disagreement with what I have said. Perfect, that is the intent. As some of you know, I am a regular on SPaMCAST with Tom Cagley in a segment of the same name as this blog. I wanted another avenue for those that listen in addition to those that will just read here to foster a 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 single 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. 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 the 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. They go in and do whatever they want, documenting what they do, of course. To see what happens — usually done at the end of a cycle, if time allows. So that planned work on the changes is 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. In our last session, we had a few executives come in and play around. We found a few things, nothing serious, although the most significant intention of the outcome is to give the understanding to everyone what the QA team goes through in a short period.

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

The additional benefit of Exploratory testing is improvements in requirements. Think about it, why was it decided to go off and try something on a system that lacked documentation? To see what happens. The 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 have to keep in mind that when developing the WHAT  in a change, they will add some additional detail to avoid future issues.

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