Exploratory testing

Discussion about exploratory testing.

Exploratory testing is like a chess game with a computer. You revise your plans after seeing the move of your opponent. Yet all your plans can be changed after one unpredictable move of your opponent. Can you write a detail plan for a chess game with a computer? Let us think about how a chess master plays with a computer.
Does he write a detailed plan (he may have to write thousands of pages)? No, but he uses all his knowledge and experience. He can define only the fist move in the game and it is unreasonable to plan far ahead. You can plan 1 move ahead, or 20 moves if you're a very experienced player, but you can't plan the whole game. To plan 20 moves he had to spend a lot of his valuable time (the clock is ticking).
Of course he is trying to find some information about existing situations between moves. This is exactly what an experienced exploratory tester does.
After running any test case, testers may need to find additional information about application and system from a developer, system architect, business analyst, or may be from literature. A lot of information is necessary for correct exploratory testing. We are not testing an application that is written by a team of 10 or 20 developers. We are testing an application that was build by the whole Microsoft team if the applications work on Windows OS. Other teams whose products are used for creating the applications have influence on our testing too.
The definition of testing, for us, is the process of finding the most important bugs in a short period of time.
Can we use any test automation tools in exploratory testing?
There is a lot of good, bad, and sometimes difficult to use tools for software testers with a long pay back and learning period.
Many important small tools that we now need are missing. Let us take one example.
"Test Procedure Recorder" tool. This tool records our testing activities during the time that we are studying and testing an application using exploratory testing. All activities must be recorded in easy to read plain English, and may be in a simple, plain text format e.g. in notepad. There must be a possibility to correct records and make comments at any time. The objective is to have a soft copy of all our activities at any time. Sometimes we do not really need the complex replay function, because the automation of this test case is very difficult. We always need to have the possibility of reproducing our activities at any time. If we will find the bug, the record made by this tool will be the draft of the bug report and the directions to the developer how to reproduce it. If there is no bug found, this record can be used for the following regression testing.