How do you handle complex or dynamic systems or environments in exploratory testing?

Re: "They are not necessarily true or accurate...." In my opinion, "optimal" is a more appropriate adjective than "true" or "accurate." The reason is that I can't think of an instance where an untrue or inaccurate assumption is useful in efficiently simplifying a problem or reaching a valid decision.

Re: "....and executing tests in an interactive and adaptive way." Perhaps, investigative, fact-finding, spontaneous, prior event-driven...way, rather than "interactive."

"Oracles are sources of information or criteria that help you determine whether a test result is correct, expected, or acceptable. They can be based on specifications, standards, expectations, or experience." Specifications are important, because if your testing is not based on the requirements, then how do you know that your software works the way it should? Standards are handy for helping you to organize your testing and make it easier for someone else in your organization to follow it. Expectations for me would be things like object behavior that might not be in the specifications but are common in the industry. Finally, experience tells you where your focus should be, what needs more and what needs less testing.

The heuristic models mentioned here are all ones I created. The strings of letters are meant to be mnemonics that refer to guide words that serve as generative heuristics for test ideas. But those are only one of many kinds of heuristics we use in testing. Useful heuristics are all around us. One of my favorite ways of discovering them is to video myself testing, then go through the video moment by moment and put into words every single pattern of reasoning and problem solving I engaged in. In this way intuitive heuristics can be brought into the light and made teachable.

This isn’t quite right. An oracle in testing is any means by which you recognize a bug. Without an oracle you are not yet performing a test. So, they don’t merely help you, they are an essential aspect of any test you do. Many people who speak of oracles seem only to be referring to “authoritative” oracles. This is unnecessarily limiting. We use suggestive as well as authoritative oracles. We use explicit as well as tacit oracles. All oracles are heuristic by nature. There is no such thing (at least practically) as a perfect and complete oracle. Oracles are not special or different for highly exploratory or experiential testing. All forms of testing involve any kind of oracle.

In my opinion, the comparison of actual and expected results is not, in and of itself, informational. So, does that comparison actually help anyone "evaluate and report exploratory test results?" I think it is but an activity of the provide an oracle and verify test cases process, not unlike the generating expected outputs and executing test cases activities. It seems to me it's the determination of whether the result of the comparison of expected and actual results is an indication that a fault exists that supports the evaluation of exploratory test results.

While this is true, it’s very important that you realize all testing requires oracles and all testing is based on heuristics. Therefore these statements are really just telling us that testing is not perfectible; good testing is hard to do. You can define test cases in a highly rigorous way, yet that process is still heuristic and your oracles are still incomplete in some way. There is no algorithm that can possibly guarantee that you will find all the bugs in a non-trivial product in the time available. However, in specific cases we may be able to test in highly penetrating ways that give us confidence that any bug that evades us would have to be quite obscure indeed.

Exploratory testing depends on the skill and knowledge of the tester. Heuristics are and approach, but is everyone on the team using the same heuristic? Do we care? If they are, do they apply it the same way. Exploratory testing is subjective. The way I navigate the system may be very different than the way someone else does, yet we perform the same task. If we want everyone doing the exact same thing, then we likely want automated testing and not exploratory. The team should learn from each other and develop standard heuristics and oracles. Those become tools or templates. You use the ones you need on the project at hand.

Exploratory testing is like a knife, it needs to be sharpened or it will become dull. The same applies to our skills and our processes. Heuristics and oracles are processes for testing. We need to have an attitude of continuous improvement. Exploratory testing allows us to focus on testing rather writing lengthy documents. We uncover more issues in the system. Collaboration is still key as mentioned here. The Bible says, Proverbs 27:17 (ESV): "Iron sharpens iron, and one man sharpens another." This is talking about moral character and not software testing, but it still rings true. Exploratory Testing requires skilled testers, so all testers have to start somewhere and can benefit from the knowledge of their co-workers.