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.
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.
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.
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.
https://searchsoftwarequality.techtarget.com/feature/10-exploratory-testing-techniques-for-QA-professionals