Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Exploratory Testing: Testing in the Wild

DZone's Guide to

Exploratory Testing: Testing in the Wild

What opportunities does exploratory testing open up? Learn how to get started and how it helps you find issues before they ever reach your users.

· DevOps Zone ·
Free Resource

Learn more about how CareerBuilder was able to resolve customer issues 5x faster by using Scalyr, the fastest log management tool on the market. 

“Not all who wander are lost.” -J. R. R. Tolkien, The Lord of the Rings

Why Exploratory Testing?

One of the most interesting forms of testing is exploratory testing. Personally, I find a lot of enjoyment in sitting back and using the applications that the development teams are working on. Most often, I have had this experience while in a war room before launch. Helping another team out when they have a more or less final product for beta or launch can be one of the rewarding parts of being in a QA team. The whole point of the war room is to test outside of what the team has already done, outside of the stories, and think like a user of the product. Find what may have been missed with an outside thought process.

How Should I Test in the Wild?

When it comes to exploratory testing, I like to use one of two approaches; the first is as a science experiment, the second is as a user. When testing as a science experiment, I propose a line of testing with what I expect to happen. In this case, I have a hypothesis that guides my line of testing. This process helps me tackle different options and what types of interactions with other systems I will do; whether it be mobile and desktop applications or tracking on admin sites. Having this structure can be very helpful when you are first approaching a new application in an environment you are already familiar with. This process has helped me find the cause of numerous sticky issues that our standard testing missed.

The second approach is as a user of your product. Some people call it “champagning,” others call it “eating your own dog food,” but in the end, it means using the product that you are developing and selling. I believe in using your own product, regardless of what you call it. It is an excellent way to see what your customers see when they are using your product. For me, I treat all users as either my father, my mother or Batman.

  • My Father: Very knowledgeable in his selected field and their tools, but is not quick to try a new technology.

  • My Mother: Has a broad, but not deep knowledge of different technologies and will usually try to figure something out on her own before asking for help.

  • Batman: Has a deep knowledge of a product/field and will surprise you with what they know about your product. In addition, they are well connected and can champion or ruin your product.

When testing as one of these users, put yourself in their mindset and think like them. How would someone new to your product expect interactions to work? How would someone who has been using your product for years learn a new feature? What is the important feature that you would want to hear promoted on the radio? You will learn about your product in a new light and might find some random issues you would not have found otherwise. (After all, this is exploratory testing.) This style of testing has proven powerful because thinking how a customer uses your feature impacts how you will measure risk moving forward.

What Else Can You Do With Exploratory Testing?

Besides looking for issues that are outside of your normal line of testing, they can be useful for finding gaps in your current testing strategy. I like to outline what my exploratory testing is doing and accomplishing, especially when taking the scientific approach. This way, I can document what I did, and depending on my findings, I can go back and create end to end or scenario test cases out of them.

Exploratory testing is a great way to test, but not a great way to learn your product. I wouldn’t recommend using this approach with new hires because it will cause lost time. Your new hire will chase waterfalls and you will explain why they should stick to the rivers and streams. Exploratory testing should be left to people who already know the company.

Conclusion

Exploratory testing can be awesome and helpful. Formulate an idea of what you will be doing with your testing and be sure to document your findings. Have fun with your testing and work to build some exploratory testing into your week. Actually using your company’s product is a great way to find issues before your customers and help your Product team out.

Find out more about how Scalyr built a proprietary database that does not use text indexing for their log management tool.

Topics:
software testing ,exploratory testing ,qa ,devops

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}