The Power of Exploratory Testing in Agile development
Exploratory testing is one of the most effective and powerful methods of testing. It combines different activities such as test design, test execution, and test documentation; it focuses on learning the application under test. Exploratory testing is one area where applying different ways of thinking is especially beneficial. As a result, whoever uses this method of testing will have to employ a variety of thinking processes, including conscious, logical, and calculating. Above all, he needs strong intuition to know when, how, and where to dig deeper during the testing process. This article will discuss the evolution of exploratory testing and how you can use it in your agile teams.
Whoever conducts exploratory tests (tester, developer, etc.) must consider several factors, including the product's end users, how the feature under test relates to the company's business goals, and the impact the feature may have on other parts of the system. Exploratory testing, in my experience, is the most efficient and productive method of testing; as a result, testers who are skilled and experienced in exploratory testing add tremendous value to their teams.
Exploratory testing, unlike traditional testing, which is usually based on predefined scenarios, can be a little challenging for someone who has never done it before. In exploratory testing, we do not enter the session with predetermined, expected results (although we can combine the two, which is called "Script Exploratory testing"). Instead, they use and manipulate the system to compare its behavior to what they might expect based on heuristics, experience, and common sense.
Exploratory testing has a place in any testing strategy; I learned it after experiencing it for more than a decade. It is still relevant today in the Agile environment as it was relevant a decade ago in traditional testing projects. Today, we see more and more companies moving to the cloud, meaning that they invest more in CI/CD frameworks, but that doesn’t mean that their exploratory testing is not relevant. Remember, automated tests won’t tell you that the system has bad performance unless you explicitly tell it to look in advance. It won’t tell you that the UX doesn’t provide a great user experience. And the funny thing here? When you identify a problem, you usually investigate it using explorations while you dig through the reams of configuration, data, and system flows.
In an Agile environment, exploratory testing is a fantastic method to use. It allows the person in charge of the situation to use positive and negative scenarios to simulate real-world customer usage. As a result, if you want to simulate negative system usage, you should use your awareness of possible issues to try to break the system. Here are some actions you might consider taking in this sort of investigation:
Inputs that aren't supported, such as long strings, negative numbers, and so on.
Communication between components is being closed.
During system operations, restart services.
Open the program in modal dialogs.
Error messages are triggered invisibly.
Experiment with data spikes.
Exploratory testing is beneficial as it allows you to give greater attention to your instincts. It enables us to harness the full potential of our ability to objectively assess, critique, and challenge your understanding of the product to generate critical data while using the system. Exploratory testing and automation are not mutually exclusive; instead, they complement each other. The day-to-day repetitive regression testing is handled by automation. Testers, on the other hand, can use exploratory sessions to test many flows that automated tests can't cover or system scenarios that the team had not even considered before coding.
The beauty of exploratory testing is that there are no limitations on how deep you can go into the system. As you dig a little deeper, you'll discover more flows, issues, and areas that need to be explored further or automated. Some projects are too complex from the beginning, meaning the stories are there but the team does not know how to test it since there are so many "unknown unknowns." Programmers and testers can work collaboratively and "Pair" to explore as they start executing system flows, attempting to remove the unknowns and supplying critical feedback on how well the system is built based on preliminary requirements.
If you've done exploratory testing before, you should be aware that there are numerous ways to explore, regardless of the system under the test's complexity. As a result, the exploration can be carried out by a single team member, in pairs, or even by the entire team working together in some cases.
Exploration guided by Test charts
A test charter lays out a clear objective for your exploration session. You can, for example, make charts that focus on happy path scenarios, recovery scenarios, or even performance and scalability. If you are new to this method, it is you must practice the right level of detail feet best for your purposes. Too specific chart means that you don't have enough room to wander off the beaten path to make unexpected discoveries. Too vague charter doesn't provide enough focus and may lead you to waste time on unproductive exploration sessions.
let's check a few possible charters you can create:
Explore . . . <target>
With . . . <resources>
To discover . . . <information>
Example:
Explore creating a new user
With real user attributes
To discover if there are issues in the creation process
Or
We can use a mission statement and areas to be tested, for example:
Analyze the edit menu functionality of user creation in the console
identify and report on areas/flows of potential risk in the console.
As you can see in the examples above, keeping a charter simple makes it very easy to stick to and follow during the exploration session.
Always use the charters that work best for your teams, experiment with different formats, and ensure that your teams are involved in the creation process as they're the ones to use it in real-time.
A couple of years ago I was consulting for one of the largest corporations in the security industry that used an agile method. The business domain was very complex and challenging to test as it was built by different teams over decades. Each group contained the people who had the expertise, knowledge, and skills needed to ship software. Also, each team determined its processes independently. The company held a sprint-based "Testing Guild of Practice" meeting to coordinate testing efforts. The "charters" adopted by the teams over the years were incredibly long (2 pages on average) and prescriptive.
For me, a charter is a mission for testing and therefore should never be so long and spread on different components (as the teams currently write and used). In Agile software development, functional tests are part of story work, a charter might address a risk we want to investigate or invest time to mitigate. So the change we made was to create focused and simple charters that the teams can use when working on users' stories, Here are some examples:
Test <Security item type X> with <different type of connection types>.
Test <component> under <new SQL versions>.
Test system recovery after failures made with <Tool X>.
Test the system Analysis flow for phishing attacks with time and scope attributes.
Let's go over these charters once more, as you can see, they are very focused, address specific testing goals, and are short (try to keep yours to be at the range of 150-250 characters long). It's important to remember that charters can be used for a variety of purposes other than testing. You can use them to set meeting goals, for example, to plan bag activities or to identify risks. Charters, in my mind, are small chunks of work, typically lasting up to a half-day. If you use charters, it's also a smart option to connect them to a user story, just like you would with many other items like DOD or acceptance criteria, all of which are used to guide development teams in their delivery efforts.