Testing is a craft which can be performed in many different ways. There are several different approaches to define all the ways, styles or schools of testing. But most of these approches are one or at maximum two-dimensional. Of course the reality is different.

All the various classifications are only a model, a representation of one or few aspects. And all these representations are valid - in their specific point of view. One of the most common models list scripted testing on the one end and explorative testing on the other; but in this classification it is hard to fit disciplines like performance testing.

So if you want to classify performance testing it does not work with this model. In performance testing you will always have a script; or at least one script and probably multiple scripts or a whole framework of scripts. But it also doesn't prevent you from exploratory testing, which utilizes different combinations of scripts, configurations and test data. This concept is not widely spread yet and many people will associate performance testing with classical approach of load testing which is used to validate the performance requirements. It is seldom used during a development cycle to give feedback about actual behaviour in edge situations; but as performance requirements are seldom strict requirements but have many dependencies on other system variances, a exploratory approach would be even more important as for functional testing. It allows to do performance engineering including tuning, optimization, troubleshooting, bug fixing etc. It even might give you the ability to define performance specifications in the first place.

And in the light of this context the concept of scripted test doesn't seem to fit for performance testing anymore. Having this new viewpoint on performance testing, what would be the opposite site of the exploratory context? - Regression testing fits best.

In regression testing we want to make sure that during the product lifecycle in further iterations we don't have regressions. We like to have this as quick and cheap as possible - so we are using test automation (whenever possible) for this task. I often refer to this type of testing rather as checking. For a new system we would use exploratory testing to gain insights about system behaviour and gives us the ability for defining scripted tests we will use as regression test in later iterations.

Having a definition of in this way, the different testing approaches are looking complementary instead of trying to beat each other. Questioning one approach or favoring the other approach is faulty from beginning.

Another example where you could use both approaches complementary is when you have a highly modularized configurable system consisting of several software components. Having automated component tests can be supplemented by explorative system testing with focus on system configuration and component interactions.

This said the classification into regression and exploratory testing is of course not complete! There a various other point of views into testing and none of them is the ultimative one. Relying on only one strategy however should be avoided.