In my career I have tested many projects deriving from different sectors: fashion, banking, social, agricultural, mechanical and beyond. For all these software I preferred to adopt the same methodology, understanding over the years where it works and where it doesn't.
Every time I always thought the same thing: the best way to test software is to explore it.
But let's start from the base. What does it mean?
Software exploration is an approach in which testers learn, design, and run tests simultaneously. It is a method that is based on the experience, instinct and skills of these people. It allows you to find bugs, understand and provide information on the state of the application in order to help project managers make decisions towards customers with greater awareness.
Testers can interact with the application however they like and can use the information provided by the app to react, change course and explore features without restrictions.
Exploratory testing is particularly suitable for developing modern applications using agile methodology. Development cycles are short, leaving little time for writing and formally maintaining test cases. Features often evolve quickly, so it would help to keep this part to a minimum. If the test case has a good chance of becoming irrelevant, why write it in the first place? You risk spending more time writing and maintaining it than actually running the software.
The objectives of the exploratory test are:
- Understand how the application works: helps to understand how its interface is made up and what features it implements. The objective is often adopted by testers who begin working on a new project or by those who want to understand how to approach the software, identifying what to test. Understanding the application also allows you to obtain the information to write test plans. This lens is also used by expert testers to explore an application and become aware of the effort needed to complete the work;
- Force the software to show off its capabilities: the idea is to put the software under pressure. This may or may not allow you to find bugs, but it will certainly provide evidence that the software performs the function for which it was designed;
- Find bugs: exploring application limitations and identifying potential weaknesses is a specialty of test exploration. The goal is purposeful, rather than aimless, exploration to identify untested and historically flawed features. Exploratory testers should not simply stumble upon bugs, but should focus on them with purpose and intent.
It is a technique that also has some weakness: there is the risk of wasting a lot of time wandering around looking for bugs and things to test. Additionally, lack of preparation and good guidance can lead to many unproductive hours and repeatedly testing the same functionality, particularly when multiple testers or testing teams are involved. Without good documentation, how do testers ensure they get a good result?
And this is where the guidelines come into play. Exploring without a good guide is like wandering around a city looking for interesting tourist attractions.
It is a methodology that brings more advantages than disadvantages and should be spread more in cultural terms.
James Whittaker, author of the book “Exploratory software testing“, he succeeded using a metaphor who compares this approach to the visit of tourists to cities.
It is an effective and winning metaphor to reach readers more easily and which, by taking it up too, I hope can bring benefits and greater knowledge of this technique. My intent is to spread more awareness about this topic through its explanations and concepts, as I have already done in this article.
Personally, I have always found it pleasant to explore a city. And it's the same feeling I get when I explore software.
Source: “Exploratory Software Testing: tips, tricks, tours, and techniques to guide test design”, James Whittaker
English (UK) 
Italiano