"free-style testing that largely depends on the creativity of the testers and how well they know the product or feature under test."
I would switch 'creativity' (which I also see at Wikipedia) with 'experience and training'. How well they know the product is definitely helpful.
I break down exploratory testing like this:
The different paths:
Happy - user enters everything correctly and clicks correct buttons and links
Sad - user enters invalid data or fails to enter data - error reporting to the end user should be done correctly - correct markup, not relying on the color red, etc.
Optional - many sites have 'optional' functionality. For example additional orders, 2nd shipping address, different payment methods, etc. Optional workflows will also have happy and sad flows within them
So the above is for workflows. Now to examine individual elements (fields, buttons, text, etc):
You want to test for the following:
- required data
- invalid data type (string for date, integer used for date, etc.)
- invalid data formats being used
- data validations, e.g. 'added date' must be in the past, 'dob' must be > 1900, etc.
- boundary testing (1 under limit, at limit, 1 over limit, etc.)
- valid relationships between data
I feel that the main part of 'free-style' for exploratory testing is spotting new or changed functionality not previously - or recently - tested.
Part of an approach can include 'I only check x every 5 runs, I only check y once a week, I only check z once a month' and I myself have used this approach. It allows a tester to cover a lot more with their testing and helps with the human balance between monotony, boredom and rote and the need to be comprehensive in testing.
One element that might relate to creativity is tester experience and attitude. For example, I know one exploratory tester whose goal tends to be to give a thumbs-up for release. Another tester I know often sees their mission as 'there is always something I can break, I just have to to try hard enough' and they nearly always manage to find some sort of bug - though often minor and not necessarily related to recent change. They have even said that release testing is often a good excuse to check the overall health and functionality of the product. A big part of exploratory testing is also that you learn more each time you do a session and that knowledge gets used by your brain in future sessions without updating any scripts.
In the more broader goal of 'find more bugs' I would also recommend learning more about:
- The industry you are in
- Characteristics of the users of the product
- The product and how it is used as part of other processes
- The business aims and goals of your company
- 'new user' testing services such as usertesting and usabilitysciences