When I first started at FrogSlayer a few years ago, I had no idea what I was getting into when it came to testing. I had no experience with developing software beyond a few courses in school, but that didn’t stop me. I’ve been testing software for a good amount of time now and even though I can’t say that I have any “professional” training, I believe I can still share some valuable insight that I have acquired through self-teaching and on-the-job training, particularly on the importance of exploratory testing.
While there are benefits to scripted and automated testing, I usually prefer testing that is more on the exploratory side. In the long run, I find that the advantages offered by exploratory testing make it a much more productive means of testing. Instead of having testers stick to a strict script that restricts them by promoting repetition ad nauseum, exploratory testing gives testers freedom to work more efficiently and with a more positive outlook on their task. Don’t get me wrong, repetition is a necessary part of testing, but it doesn’t have to consume the entire testing process.
Before I go into some of the strategies that I have developed for exploratory testing, I want to note that exploratory testing might not work as well in the beginning for testers that are just starting to test software. The freedom that it allows can sometimes be counter-productive for those who have no discipline in the area or low enthusiasm towards testing.
“No Strategy” Strategy
You might think that having a strategy while exploratory testing is a bit of an oxymoron and you’d be partially right. The first strategy that I use on occasion is to have no strategy. Makes sense, right? I know it sounds stupid, but having no strategy occasionally allows some of the more obscure bugs to be discovered. By abandoning any plans when approaching the testing, you can more readily emulate the conditions that a new user would experience. It’s very important to note that exploratory testing without a strategy sometimes works in the tester’s favor, but not often enough for it to be a totally viable means of testing.
Continuous Variety Strategy
Continuous variety is another important thing to consider when exploratory testing. Believe it or not, even when given the freedom that exploratory testing offers, it is still very easy for a tester to get too focused on one specific part of the software and work less efficiently. By constantly reminding myself to move around to other parts of the software, I have found that I can stay much more productive. Personally, I have found that a great way to stay fresh and motivated is to work on multiple projects at once. Although some people complain that juggling projects is not helpful for them since it means they have to keep track of multiple builds, meetings or deadlines, I find it to be an effective strategy for testing.
This last strategy is probably a bit more controversial than the others, but I think it is worth noting. I have found that distracting myself can sometimes be a valid strategy to implement while exploratory testing. To be more specific, finding a way to take up some of your attention while you are testing can help you to subconsciously find bugs that you wouldn’t find if you were testing at one hundred percent. I’m not saying you should strive to be distracted from work, but sometimes it pays off. It’s as easy as putting on some music or half-watching a video to keep your mind less occupied with testing. Of course there are drawbacks to this strategy, the most obvious being the risk associated with “semi-slacking” while working potentially leading to completely slacking off your testing duties. Also, I’ve found that when you do stumble upon a bug when using this strategy that you often aren’t paying enough attention to reproduce the issue. But this is where the strategy kind of pays off. Because if you’re anything like me, you won’t stop messing with the issue until you can reproduce it reliably, therefore returning to the testing mindset with a more defined purpose. This is definitely a bold strategy and should only be attempted by experienced testers.
If you have any questions about exploratory testing, leave a comment below.
BlogSlayer is the official blog of FrogSlayer, a custom software product development shop in Bryan/College Station, Texas. Our specialty is getting your product to market in 90 days or less. If you would like a free consultation for your project or big idea, email us at firstname.lastname@example.org. You can also connect with us on Twitter, Facebook, or LinkedIn.