You can do exploratory testing without an experienced exploratory tester. Indeed, that's what all exploratory testers do with a new system / technology / customer etc.; start from a position of ignorance and get exploring.
There are a couple of ideas that I'd recommend keeping in mind:
- one of the things you'll be doing is gaining experience, and (through reflection) expertise. This is part of all exploration, but it's particularly true when getting going on something new. Expertise will help you find more/better information – and you'll find fewer/poorer without expertise – but it takes time to build. However useful it is, it is neither necessary, nor sufficient, and even expert teams explore better with a newbie in the numbers. This is because...
- if a few of you are exploring, there will be great diversity in your approaches. Learn from each other - and try to take those lessons in a way that doesn't flatten that diversity.
1 Exploring via Diagnosis: 3 person-hours
- Pick out some current bugs that aren't clear, or that aren't reproducible. Doesn't matter if they're in your bug tracking system or not, but they should be already known, and not yet fixed.
- Explore those bugs, seeking information that will clarify them or make them more reliably reproducible. Keep track of your activity.
- Review what you've done, collate the information gained. Log new bugs, update clarified bugs.
- If you can generalise from the investigative approaches you're used, then do so.
- Tell the whole team your results.
- Schedule another 3 hours on a different day and repeat!
- Spend 10 minutes writing down lots of different ways that bugs manifest / get into your software (Use any or all of cause, effect, location, conditions, etc.). Aim for diversity and volume, not completeness or clarity. This might be fun as a whole-team exercise.
- Leaving enough time for the review+generalise+share steps at the end, split the remaining time in two.
- In one half of the time, pick out problems that you've not yet seen in this release, and look for them. Keep track of your activity.
- In the other half, pick out places that haven't yet seen many problems, and look in those for problems. Keep track of your activity.
- Review, collate, log, update.
- Generalise and tell the whole team your results.
- Schedule another chunk of time on a different day and repeat!
- Make your trigger list publicly accessible. Invite people to contribute, share, refine etc.
If you have a favourite bootstrapping-into-exploration source, post it here or on Anna's original posting.
Note - I have an upcoming, no frills, public class on Exploratory Testing, in London, December 8-9. Lots of exercises, discussions, and learning by example.