The Relationship Between Exploratory Testing and Test Automation

There is a lot of information (and misinformation) on the role and value of exploratory testing in the testing process.  Many teams plan their testing practices based on verifying that requirements have been met, and that is an important approach.

But software quality is more than just meeting requirements.  Sometimes requirements make assumptions that aren’t tested through requirements-based testing, and aren’t discovered until defects not related to requirements are found.  Also, many times requirements are focused strictly on business functionality, and don’t look beyond that to other parts of an application.

Exploratory testing, on the other hand, relies on the tester’s skill, experience, and intuition to examine an application in a structured way, trying things that the tester believes may uncover weaknesses or limitations in the application.  While occasionally the actions may seem ad hoc, they are typically well thought-out and always recorded and documented.

Exploratory testing will never fulfill all of the needs of software testing.  Neither will requirements-based automated testing.  But we’ll get better and more comprehensive testing by using both, alternately, with information from one strengthening the second.

For example, with good documentation or an automated way of recording explorations, exploratory tests can be easily converted to manual or automated tests.  While they may not flow directly from requirements, they are relevant because they test functions or activities outside of the scope of what business analysts and testers believed important at project conception.

At the same time, automated tests can provide good exploratory testers hints on future explorations.  If an automated test fails, that often represents a regression that could affect other parts of the application.  Even when automated tests succeed, they can suggest areas for further exploration.

Taken together, exploratory testing and test automation represent a virtuous cycle of information and improvement.  Stay with me over the next couple of posts, and I’ll describe in more detail how this might work.

Peter Varhol

About the author

Peter Varhol

Peter Varhol is an Evangelist for Telerik’s TestStudio. He’s been a software developer and software product manager, technology journalist, and university professor among the many roles in his past, and believes that his best talent is explaining concepts and practices to others. He’s on Twitter at @pvarhol.