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”


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. 

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.

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

Are there issues that only exploratory testing can reveal? 

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.