Where Exploratory testing fits into Agile Testing?

I'm a great believer in exploratory testing as an essential component of Agile testing. I used to combine exploratory testing and large-scale project management almost a decade ago, and I still do it now as part of an Agile development project. I've written several articles on exploratory testing and how to get the most out of it (just search my blog or buy my book), but in this article, I'd like to address one question that I'm frequently asked: "Where does exploratory testing fit into Agile testing?"

Exploratory testing, in my opinion, is an important part of agile testing, and it's important to understand where it fits into the overall Agile development process. One of the most common uses of exploratory testing is to confirm if "We built it right?" because it allows the team to effectively explore the workflow to see if they are delivering the expected business value. Exploratory testing allows the team to test their preliminary assumptions from the start of the project and fill in any gaps discovered during the exploration session.

So, to answer the article's main question, I'd like to focus on the four levels of Agile planning items: product release, feature, story, and task. Let's see what kind of exploratory testing would be appropriate at each of those levels:

Product Release level (Epic): This is where you'd test an integrated product or a release candidate before making it available to your customers. Exploratory sessions will be used at this level to identify product quality issues that are most likely related to team dependencies and high-risk workflows. One of the things I enjoy doing at this stage is involving different types of stakeholders (PO, Dev, and testing personnel) in the explorations session to ensure that all E2E flows are working according to business flows.

Feature Level: Once all of a feature's associated stories are "done," it's time to explore the entire feature. You should concentrate on the main feature workflows and interactions with other applications at this level. Aside from the team's exploratory sessions, I usually add another layer of exploration by providing a lab for the product team to explore the product and main business flows to ensure that the product as a "whole" is working according to their vision when defining the product requirements.

Story level: At the story level, exploratory sessions can be used at various times. In my teams, we run exploratory sessions once the story meets the expected results, which means that all coding activities have been completed and automated tests have been deployed. You can start exploring and focusing more on unique flows and variations that are not covered as part of the regular testing activities or as part of the automation suite at this point, before marking the story as "Done."

Task level: Exploration would take place at this level as part of the coding and testing activities. Examples might be a programmer's exploration of an API, Exploring boundary conditions, and even pairing with a tester to validate a new part of the system prior to it being integrated into the system.

Continuous exploration can be extremely beneficial to agile teams. When they brainstorm how to test new features or even partial parts of the system ready during the sprint. The most important thing is to concentrate on what you learn during the exploration sessions; this will aid your team in improving quality and the overall testing process as the product evolves.