Exploratory Testing: How to get started?

Some people coming to this project may be used to working as testers in fairly structured environments, where there are clearly defined Requirements, Specs, Test Plans and Test Case documents.

On this project, we want everyone to work in the way they feel they can add the most value. But the fast-paced nature of the project means that we are often don't have much in the way of detailed documentation to work with.

This context means that Exploratory Testing may be a good approach to take, even if it’s not an approach you have tried before.

So how do you get started with Exploratory Testing?

Here’s a few basic ideas, mostly based oon ideas from “Session Based Test Management”. I hope that others on the project with experience of this approach can help improve on these

• Start by making clear you have a good understanding of the value that the product you are testing is intended to deliver: who is going to use it? What will they use it for? Why is it valuable to them? The “Apps Gone Rogue” Whitepaper, and our Safe Paths Quality Map may be useful places to start.
  
  

• Now have an initial play with the app - just to get a sense of how it works, and how it provides that value. You may immediately spot some things that seem wrong, or are obvious bugs (especially if you are the first to pick up a new release). If you aren’t sure whether something’s a bug, try reaching out to #testing first, or maybe someone in the Development team.
  
  

• Once you have that basic familiarity, I’d suggest you pick a specific area to focus on: a particular niche of the product to explore. Ideally it’s one that’s not been explored much before (at least not in the latest release). That means you need to have a sense of what’s been tested before. We’re trying to build up better records of this, but in the meantime, try posting on #testing to ask if anyone has already tested in a particular area.
  
  

• If you can’t think of a particular area to test, try taking one from this list ofTest Session Charters . If you think of aspects of the app that might be interesting to test, but don’t have time yourself, please add them to that list.
  
  

• Spend a few minutes jotting down a few test ideas: aspects of the product that might be at risk, or aspects that really matter that you know you want to check. It doesn’t need to be complete: you can (and probably will) extend the list as you get stuck into testing and learn about the product.
  
  

• Exploratory does not mean unstructured. Set yourself a time box (60 to 90 mins is usually good) and explore the area of the app thoroughly. Take notes, including what seems to work, what seems odd, ideas for future testing etc. At the end, review your notes, and decide what bugs reports to file. It will help both testers and developers if you also write up a Test Report, which you can file in Test Reports, and link to that from the list of Test Charters (so people know what’s been done). Here’s a good set of ideas to cover in a Test Report - but use your own judgment in terms of what it is worthwhile to cover.
  
  

• If you are able to, find an experienced tester that you can run a debrief with (as described in the SBTM doc). They’ll take a look at your test report, make sure that it’s clear & understandable, and have a bit of a dig to see if there’s anything you might have seen that could be worth a deeper explore. Don’t worry if in your first debrief, you receive loads of suggestions for other things you could have checked, looked like, tested out. When this happens, it’s a great opportunity to learn.
  
  

• Celebrate your work: post a link to your Test Report in #testing. There are a few Devs lurtkin in #testing who will pick things up, but you can post things to e.g. #app_dev too if you want to.

Hopefully that’s enough to get you started with exploratory testing. There are plenty of expeirenced testers around. who will be happy to give you pointers and advice if you are unsure about what you are doing, so don’t be afraid to ask!