Balancing Exploratory Testing With Scripted Testing

This is the best explanation I have ever seen that deals with the balance testers must strike between scripted and exploratory testing:

"To the extent that the next test we do is influenced by the result of the last test we did, we are doing exploratory testing. We become more exploratory when we can't tell what tests should be run, in advance of the test cycle, or when we haven't yet had the opportunity to create those tests. If we are running scripted tests, and new information comes to light that suggests a better test strategy, we may switch to an exploratory mode (as in the case of discovering a new failure that requires investigation). Conversely, we take a more scripted approach when there is little uncertainty about how we want to test, new tests are relatively unimportant, the need for efficiency and reliability in executing those tests is worth the effort of scripting, and when we are prepared to pay the cost of documenting and maintaining tests. The results of exploratory testing aren't necessarily radically different than those of scripted testing, and the two approaches to testing are fully compatible."

This makes sense to me. The messing around I do as I am figuring out how new things work and how I should test them is really a form of exploratory testing. And this may be the only testing that is necessary for very small applications. But with a bigger app like eduCommons it is clearly impossible to keep everything organized without scripted (preferably automated) tests.