10 exploratory testing techniques for QA professionals
Software testers, embrace your creative and fearless side. Learn how to do exploratory testing with approaches for QA professionals of all skill levels.
Many types of software testing use a scripted set of detailed steps. But exploratory testing is a distinctive approach that relies on the quality assurance professional's creativity. There's no one right way to execute the testing style. Sometimes called ad hoc testing, the approach is flexible, creative, quick to implement and requires little-to-no documentation or training.
QA engineers use their understanding of human behavior, the user experience and the application's purpose to inform their exploratory testing efforts. This testing approach works well within the Agile methodology because of its speed and ability to fit anywhere in the software development lifecycle, including requirement and design review.
Exploratory testing phases -- planning, test case development and execution -- happen simultaneously. With scripted testing, the application code must exist, in a testable state, before the QA team can develop and execute on test cases.
QA engineers should perform exploratory testing whenever possible, as all test phases occur at once. QA professionals can use exploratory testing techniques to evaluate application functionality as well as how code will deploy to test and production servers.
QA teams must plan how to approach exploratory testing. After planning, the testing style is all about discovery and creative investigation. Regardless of how the team documents or executes tests, exploratory testing relies on the QA professional's creativity, diligence and experience.
How exploratory testing compares to scripted testing.
In this exploratory testing guide, we detail several techniques for both beginners and experienced QA engineers. Let's start with beginner techniques.
Exploratory testing approaches for beginners
Exploratory testing neither requires formal training nor a complex understanding of back-end processes. But the testing style can disorient beginners, for whom scripted tests are easier to follow than thinking outside the box.
QA professionals can improve their skill and instincts rapidly when they perform exploratory testing. Testers should learn to manage and plan their approach, spot weaknesses in application design, and discover both obvious and deeply embedded software defects.
Create a team charter for beginners, and time-box test execution. Charters are statements to guide testing, not scripts to follow. A team charter explains the approach or test plan, including who performs what function, on what features and areas of the software. This information helps distribute testing to cover the entire application.
Here are five exploratory testing techniques for beginners to try:
create user scenarios or stories;
go beyond the happy path;
find defects, don't just confirm function;
analyze for gaps in functionality; and
plot out a mind map.
Create user scenarios or stories. Exploratory testers can construct textual descriptions of an application function within a user workflow. Detail a single user path through the application.
Here's an example of an end-user scenario. You're testing a medical application that enables a physician to track a patient's health on a particular medication, and edit dosage as needed.
The steps that take place with the software are:
The physician logs in and finds the patient's status and treatment duration.
He looks at lab results and compares values for the last month to six months ago.
He views a report that compares the lab results.
He analyzes if the patient needs a change in dosage to get better results. As a result, in this scenario, the physician edits the dose by 0.5 milligrams.
He requests the patient get new lab tests in two months.
Finally, he sends -- via email or text message -- the appropriate lab form to the patient and moves on to the next appointment.
This exploratory testing example assesses how the physician's workflow intersects with the software's database, calculated values and any analytics built into the reporting function. This scenario also tests the software user's ability to edit a dose with a realistic value, and send both a lab request and a lab form to the patient through multiple communication channels.
The tester can expand this user story based on the application functionality -- what happens with multiple patients, changing screens between patients, for example? That tester could also implement a level of security testing to ensure that when a user switches patient screens, the pages refresh with the appropriate person's data. Stories can be long workflows or short snippets; and these descriptions can be based on the user or the function to perform within the application.
Once QA testers become familiar with the thought process of user stories, they can think critically and assess diverse user workflows, both expected and unexpected. Test coverage and documentation benefit, as the testing stories can inform future evaluations of application usage.
Go beyond the happy path. Many scripted regression test suites define precise, expected steps and validation points. These tests, whether automated or manual, verify the application performs a function as expected or the expected logical flow occurs.
As an exploratory tester, you must also verify the non-logical flow. Go off the beaten path and test the application's response to double- or triple-clicking buttons. Use the infamous back button on the browser. Input the expected fields in an illogical order. Go back and forth; change your mind; change the values; and click buttons in an unexpected sequence.
A happy path or expected flow will always exist, but so do several hundred or thousand ways for users to act in a different pattern. Explore as many of these paths as possible.
Find defects, don't just confirm function. Exploratory testers should try to break the software, not just verify it works.
Rely on your own experience from using new software programs and look for similar defects. For example, many popular documentation applications handle bulleted and numbered lists poorly. As a tester, I can't tell you how many times I've had to wipe out a list and start over because somehow my text entry is off a line, or it makes a carriage return and I'm unable to edit the list properly.
Here's another example: logging into a banking application and checking the box next to Remember me or Remember this device for 30 days. These login options are a bad idea for security reasons, and most of these features simply don't work as expected. I use several banking and HR applications that simply never remember me, even before I clear the browser cache and cookies.
Collect all these defects you find in your daily use of applications to test against your own.
Analyze for gaps in functionality. Many software development organizations map out requirements or the design flow graphically, or in written form.
Graphically represented documentation of workflows helps testers find gaps in functionality. In this exploratory testing technique, you analyze the design for missing requirements before they become defects or additional development stories. You can also take this approach with written documentation, but you'll likely have to map requirements out for yourself to get an idea of how the complete application will function.
Give yourself time to find gaps. Analyze where and how the application pulls or pushes data to the database, or to other connected applications. Check when and how the page data refreshes. If the application allows a user to generate email or SMS messages externally or internally, test if the functionality works as expected. Connection issues with third-party messaging systems are plentiful -- see how many you can find.
Plot out a mind map. Project managers typically use mind maps -- graphical groupings of ideas and concepts -- to make sure they don't forget any necessary pieces during project planning. When exploratory testing, mind mapping is an excellent way to take the function, story or workflow you want to test and diagram all the possible options. Exploratory testing mind maps can grow to impressive sizes. These diagrams give testers many pathways to find defects.
For example, a restaurant's delivery ordering application has an endless variety of menu options. There's a large number of combinations, individual items, payment options and delivery directions. As a QA professional, you can map out how to test each option and various combinations of them in different user workflows. Here are some other questions you might want to map out during exploratory testing:
What happens if the user edits an order and saves it? Forgets to save it?
What happens if the payment fails to process?
How does the application handle multiple payment types? Opting to pay in cash?
I like to scribble out a functional testing mind map on actual paper. But you don't have to create the diagram in an analog format. You can use Google Docs, Microsoft Word, Apple Pages or any other basic documentation tool for simple mind maps; each one features the ability to add a variety of shapes with text you can move around the page. If you prefer to diagram visual mind maps digitally, plenty of software options are available, such as Ayoa, Microsoft Visio, Lucidchart, Milanote and Coggle.
Advanced exploratory testing techniques
Testers of all background and experience levels can make use of exploratory testing methods. The exploratory testing process takes advantage of a tester's full skill set, which means that the tester only gets better over time.
Experienced testers possess creativity that helps them discover user workflows that are off the beaten path. These testers often take circuitous directions to find defects that would have otherwise gone unnoticed.
Learn how to exploratory test like a pro with these five techniques:
analyze individual developer strengths and weaknesses;
search for gaps in data and back-end processes;
fold in some integration testing;
separate customer needs from app functionality; and
be fearless.
Analyze individual developer strengths and weaknesses. Don't psychoanalyze your software development team, but understand its behaviors. When you work with a development team, whether through a single release or for several years of releases, you'll learn how each person operates.
Frequently, developers test only on their local machine. And often they want to get the code to QA as quickly as possible due to time limitations. Or, the development team might only review code, not test it. When developers produce code but not unit tests, and when they don't test outside of their local machine, software defects are easy to find. You'll find bugs right at the start of testing, without much digging or creativity.
Some developers go above and beyond; they create unit tests and then execute them in the application -- after they merge the code and before they hand it over to QA. When developers make this rare extra testing effort, you'll have to work harder to find defects. You'll need more creativity to find the user workflows developers are unaware of, or test variations that stray from the expected functional path.
Some developers also miss requirements. Perhaps the user story is a long running list of options, and the developer didn't enter them all. Developers who don't fully read the requirements documents or acceptance criteria also fail to code all the options. This pattern of behavior also makes defects easy to find.
Don't leave out the rest of the team. Observe the product owner who creates the user stories and requirements. Does the product owner tend to leave things out? Does this person know how the application works from end to end? During design reviews or story grooming, do some exploratory testing before developers write the code. You won't be able to work in the application, but you can still create a mental prototype and walk through the test steps. Does the prototype make sense? Find where conflicts with the new code interfere with existing code. Always consider how code affects customer workflows.
Exploratory testing example of a user story
Follow along with this basic, short example of an exploratory testing story. It is a single sample, not a rule: Use your testing creativity to come up with your own application testing needs.
Testing the relationship between patient, doctor and medication:
Log into My Patient as a member patient assigned to a participating medical doctor team. View the Details page, verify the doctor lists a primary practice address, which populates on the patient forms. View the list of past medications and doses. Open and view the patient details, and make sure they match.
Does the application show the patient is current or overdue for a medication review? Process a review for the patient in both a current and overdue state.
Print a monthly report. Change the patient's dose -- increase by varying percentages, like 10, 20 or 60. Set up an appointment to discuss dose. Change the appointment to an invalid or past date. Check whether appointment alerts trigger to the assigned nurse and doctor.
Select to view lab results. Open one or more results. Verify the patient's name on the lab result form matches the patient selected. Verify the result data displayed matches what is shown on the patient dashboard. Open the lab result PDF. Confirm it's for the correct patient and that the patient details match. Confirm the PDF form is not editable.
Click on each main icon and section, and then search for a history of doctor assignments and medications. Verify the search results are what was expected given the search parameters, and that they display correctly.
Sort and filter on each searchable field. For example, filter on the current date, and then view how the data looks on the page.
Click to open all individual charts. Make sure the values match the specified lab test result.
Search for gaps in data and back-end processes. Design your exploratory testing approach to include analysis of back-end processes, such as third-party tool integrations that enable application functionality. Discover how and where the application saves to the database, and when it calls up data. Be aware of data feeds that come in from outside sources like APIs, and pinpoint what actions in the application trigger them. Most data feeds are scheduled for activity at specific times; test around those times to see if it impacts the application. Find out how the application responds when data feeds or database connections fail.
Test around third-party integrations built into your application. Developers can provide information on where and how these third-party apps function. For example, third-party services often send and receive email or SMS messages within an application.
If the application enables customers to configure features, search for defects in the process. When you explore the depths of configuration, you'll definitely find defects, though you might need to dig. I start with settings for anything that's regulated or high risk. In medical applications, for example, the software supports medication ordering, dosing calculations or diagnosis coding. Hit areas that will potentially cause the most damage first. It might be tedious to flip switches in random combinations for hours, but you will certainly find defects.
Look for settings that contradict each other. Turn on both settings and see what happens. Can both settings be on? If so, does one take precedence? Examine how the application responds to these conflicting configurations. Application configuration settings are an overlooked testing area full of possibilities for defects. Exploratory testing stories for back-end processes helps open up areas of concern typically unreachable via other forms of black box testing.
Fold in some integration testing. As an experienced tester, you'll likely learn where an application's end user workflows intersect. When you evaluate these connections, that's called integration testing. Create stories for integration test coverage. Focus on application workflows with different user roles, variances in security or access settings and related areas.
For example, I'm testing a healthcare application that automatically creates financial billing charges based on the drug and dosage assigned to each patient daily. I can test to see how the financial side of the application handles changes in these values. Some questions I ask include:
If the user assigns a drug with an incorrect dose, how does that impact the billing charge calculation?
What happens if I change the assigned drug, but not the dose, on a daily basis?
Does the billing calculation pick up every change?
Does the app know when charges don't match the drug?
Most software includes integrated functional areas, like reporting and financials. Use your testing experience with the application to uncover other integrated functions to test. The mind mapping technique comes in handy here, as diagrams can help uncover all the possible exploratory testing options.
Separate customer needs from app functionality. Test the user acceptance criteria or requirements for each story and see how it all plays together when moving through customer workflows. Testers tend to assess applications using the eye of the customer, but it's easy to lose this perspective during rapid development cycles. Applying this perspective is a helpful creative exercise, but it's difficult to put into practice when a tester is continuously focused on testing individual user stories.
With your exploratory testing approach, focus only on the user impact. Forget what you know about each story. Think about how the user interacts, or can interact, with the application. Concentrate on testing workflows defined by user role or access level. For example, most healthcare applications have specific workflow possibilities for roles like doctor, patient and nurse. Know which role you're testing for at any given time. Forget all other functions. Test based on what the user can do in the application.
When exploratory testing, don't fear breaking the application, the server, the database or underlying connections. Be fearlessly creative.
Keep in mind, most users do not follow the expected workflow. Users can get interrupted during data entry, or hit the wrong button sequence unintentionally. They might cancel an action rather than save it. Exploratory testing as their proxy provides a nearly endless loop of QA opportunities.
Be fearless. When exploratory testing, don't fear breaking the application, the server, the database or underlying connections. Be fearlessly creative. If you can break the underlying support system or connections on a test system, then end users probably can too. Break anything and everything. You might know about an application's weak spots, or which functional areas tend to be brittle -- exploit them to your best ability. Your only barrier should be security access.
Creativity has been overlooked for years, but it's a critical skill for a QA tester's career. Exploratory testing methods depend on fearless tester creativity. An exploratory tester finds the alternative answer, goes the wrong way, performs functions incorrectly, goes backward and clicks buttons repeatedly. Exploratory testing is a chance to test outside the box and uncover problems in areas otherwise often only superficially tested. Be fearless, like a target user who knows no bounds.
