Request info

A testing approach that fits in with just about any QA strategy, exploratory testing helps uncover issues that are beyond the scope of more scripted tests. In this context, it helps reveal bugs that may have been missed by automated or regression testing. The exploratory aspect emphasizes discovery and investigation – relying on the tester’s ability to actively interact and experiment with the product. But while this testing method offers quite a bit of freedom, it still requires discipline, creative thinking and skills. Therefore, a properly structured exploratory testing approach – that is able to successfully tap into testers’ instincts and expertise – is essential. 

To dig a bit deeper into this topic, we asked Testlio Network tester, Max, to share some of his practical knowledge with exploratory tests. An ISTQB certified QA specialist with 10+ years of software testing experience, Max has been with Testlio since 2014.

Meet a Testlio Network Tester

“I approach exploratory testing tasks as if I was a CSI investigator”

Max

Related: Meet a Tester: Max

What is exploratory testing and why is it important?

Exploratory testing is an approach that uses scenarios generated ‘on the fly’ during the testing process. Compared to other types of testing, exploratory tests involve a tester’s experience and intuition the most. The more products a tester has tested, the more skills he/she has in their arsenal to predict potential issues – thus rendering the scenarios generated more productive. 

Exploratory testing is important because even the best scripted testing approaches have limitations. Ultimately, a scripted approach can only verify the parameters set within the script. So adding exploratory tests throughout the application development process is key to making sure that there are no critical bugs/issues that have slipped the net. 

In my experience, using exploratory testing in combination with other methods, such as running manual or automated test cases, performing sanity and even performance or load testing (when needed), ensures better app quality and user experiences.

Related: Best use cases for automated and manual testing

When does it make sense to use exploratory testing?

It’s simply impossible to cover all the functional requirements of a system with test cases that follow a predefined script. So exploratory testing adds another verification layer by helping unearth issues that are not covered by test cases.

Furthermore, it helps provide rapid feedback at the early stages of software development and also review the product characteristics from a user perspective. Exploratory tests are also very useful in uncovering impactful quality issues when teams do not have enough time to prepare structured test cases.

Overall, exploratory testing should be used when overall app quality matters, and especially when:

  • Rapid product feedback is required (e.g. after a UI change or new feature implementation)
  • Test cases are obsolete (in the context of CI/CD processes they almost always are!)
  • You want to uncover more complex issues

On the other hand, some products are inherently complex and require more comprehensive test coverage to make sure nothing is missed. 

Are there issues that only exploratory testing can reveal? 

In my experience, there are indeed certain bugs that are less likely to be covered by test cases – such as issues caused by OS restrictions on file names. For example, you can’t create a file named ‘aux’ on Windows. This restriction comes from DOS and has been obsolete for many years, but it’s still enabled in the latest Windows 10. However, there is no such restriction on Mac and as you can imagine there are plenty of cross-platform products that could be exploited in this situation… 

What is your approach to exploratory testing tasks?

I approach exploratory testing tasks as if I was a CSI investigator! Above all, I always lean on my intuition and try to explore the application from a broader, end-users’ perspective. 

Generally speaking, my best practices for exploratory testing include:

  • Understanding the application inside and out: what’s its purpose, who is it intended  for – and thus how it can be ‘broken’ or what the developer might have missed
  • Checking all common cases (boundary values, validations, etc.)

Some testers also like checking offline cases (endless loadings, incorrect or absent error messages, etc.) but personally, I prefer to concentrate on other cases, especially when time is of the essence. The reason is that while offline cases are perfectly valid, they are generally low priority. Take for example the absence of an error message when a user attempts to open a page offline – it’s not perfect UX, but it’s not a critical issue either. However, there are of course exceptions depending on app specificity. You should definitely test offline cases when the application is expected to work a certain way when offline – e.g. queue uploaded files, show cached images, etc. 

Pro tip

As a reference point, I always keep in mind a list of known problems that are common across similar web or mobile applications. For example, if you have a form for file upload – don’t forget to check if it will work with super big files, passworded files, high-resolution images, files with restricted names etc. – something is likely to fail.

This is part of our Ask a tester series where we feature QA experts from our network who share with us their experience, expertise, and perspective on software testing.