Exploratory testing continued.


I came to realize for someone that’s starting saying “exploratory testing” is kind of an ominous blank page.

The essence is that you are exploring each combination of things that you can do and map them as you go along… how they work, how they function.  Like any person that gets lost, it’s good to stop and ask for hints in terms of how things are built.  That helps you find bugs faster.

The more you know about how the architecture lies the more you can explore.  Ie if someone hands you a map, don’t you think you’ll be able to get to point B from A quicker?  So of course, asking the dev for more info will help.  Do you necessarily need it?  Eventually you can read the code and figure stuff out on your own, but that will take more time. So yes, I will ask dev questions because time is a limiting factor when you have a target dates… and that’s what I did during work weeks and such.  Sometimes they help me come up with more or better test cases, just from the discussion of their area and something I wasn’t aware of before talking to them.  So a QA doesn’t work in isolation from people, even though they can.

Better testing means breaking testing into areas, and sub areas, esp where things have changed in the code… and being able to go fine grain down the alley ways and hidden passages that the dev might help uncover.

I want to get away now from saying exploratory testing because it’s too vague… I suggest that we start using a more specific type of exploratory testing : Session based testing

I highly recommend please read about session based testing.  It’s a method that works for top bug finding testers.  I use a modified version of it:


Filed under: Uncategorized