While sifting and sorting the ISTQB Glossary 2.1 I finally found a couple of terms which definitions were both correct and useful:

1. deliverable – Any (work) product that must be delivered to someone other than the (work) product’s author.
Good, because it puts focus on the fact that you are creating the deliverable so it can be useful for someone else.

2. user-based quality – A view of quality, wherein quality is the capacity to satisfy needs, wants and desires of the user(s). A product or service that does not fulfill user needs is unlikely to find any users. This is a context dependent, contingent approach to quality since different business characteristics require different qualities of a product.
This is one of five ISTQB definitions of quality that are worth knowing about. This one is also correctly described.

3. walkthrough – A step-by-step presentation by the author of a document in order to gather information and to establish a common understanding of its content.
A sometimes useful practice, and a definition including the magic “common understanding”.

So if someone says that all ISTQB definitions are wrong, I can confidently say I disagree.

Storytelling has been rising for quite some years and it will soon boom for software testing.
The reason is simple: people like stories.
And if it is used as status reporting instead of lame numbers, it is a step in the right direction, to say the least.
But when testing this idea theoretically, I find some fears:
* they will take long time to tell
* they will be too entertaining, less informative

And when comparing with my experiences, I find success stories when remembering conversations where I fast communicated the essence.

We already have a core tester skill in writing effective bug titles.
We should learn how to do this for whole test efforts, we should always have an executive summary up our sleeve.
We shouldn’t tell stories, it should be more like a librarian’s summary.

To accomplish this we need a lot of training, but I doubt it will be enough.
We also need more words.
They don’t have to be unanimously defined, and they can be reconstructed at each company, as long as they are useful.
Do a daily exercise of explaining the state of the product in thirty seconds, and try out your own terminology.

We need more words to effectively communicate the essence of our findings.

Exploratory Testing in its purest form is an approach that focus on learning, evolution and freedom.
Cem Kaner’s definition is to the point: “Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.”

ET in real life is a collection of ways of testing, sometimes used as example implementations of the approach, sometimes used for testing that don’t follow a script, and sometimes as a synonym to ad hoc testing (because that word has become increasingly under-rated.)

Scripted testing in its purest form is an approach that focus on precision and control. It is yet to be defined by proponents, but a benevolent try could be:
“With a scripted testing approach the testing effort is controlled by designing and reviewing all test scripts in advance.
In this way the right tests are executed, they are well documented, progress towards 100% execution can be controlled, and it is easy to repeat tests when necessary.
The scripted approach is not dependent on many tester heroes, and can take advantage of many types of resources for test execution, since the intelligence in the test scripts are created by test design experts.

Scripted testing in real life mostly means designing test scripts early, and executing them later, and these scripts have quite detailed steps, and a clear expected result.
The terminology is rich, complex and sometimes confusing, since they at least can mean approach, style, method, activity and technique; and these are in reality so connected and intertwined that distinctions aren’t necessary or helpful.

So are the distinctions important?
I think they can be, especially if the words are used without details, e.g. in statements like “Exploratory Testing is the opposite of Scripted Testing” or “combining exploratory and scripted testing”.
Both statements can be true, because the first talks about the approach, and the other about methods.
By understanding the different meanings of the words it is possible to get a more nuanced debate, and to see other combinations, e.g. test scripts with an exploratory approach, or scripted approaches with elements of ad hoc testing.

The intention of the used method shows which approach you are using (inferred from Cem Kaner’s Value of Checklists… p.94):
If test scripts are used to control the testing, it is a scripted testing approach.
If test scripts are used as a baseline for further testing, it is an exploratory testing approach.

It would be nice to have a solution to this semantic mess, but I don’t think it is feasible to always attach approach or method to Exploratory Testing and Scripted Testing (or to distinguish between upper case Exploratory and lower case exploratory.)
It is extremely difficult to give life to new words, but I do have some hope in the clarifications by testing vs. checking, and less hope for a renaissance of ad hoc testing.
A start would be if more people are aware of the different meanings, and are more precise when necessary, and eventually the problem will dissolve, in 25 years from now.

The variety of configurations (operating system, browser, language etc.) can look overwhelming; and it is impossible to test all possible configurations for Servers and Clients. On the other hand there are certain platforms that are more probable to uncover defects.

This is just common sense, but I haven’t seen any terminology for handling this in an effecient manner, so let’s call it BCM.
Basic Configuration Matrix is a short list of platform configurations that will spot most of the platform bugs that could exist in your currently supported configuration matrix.

The simplest example is to use one configuration with the oldest supported operating system, oldest browser etc; and one configuration with the newest of all related software. A more advanced example could use several configurations that use different languages, Application Servers, authentication methods et.al.

If it would take too long to run most tests on BCM; alternate between the configurations while testing your product. Do variations on configurations when appropriate.