Exploratory testing is a type of testing where you are not given a detailed test plan. Instead, you follow a provided mission and use your knowledge, experience, heuristics, judgment, and creativity to explore the system.
Your goal is to discover, investigate, and learn about the behavior of the product while identifying risks, issues, and inconsistencies.
Coverage
It is essential to first understand the testing mission. This mission serves as your primary guide, setting the clear focus and specific goal for your testing session.
Your mission includes focus areas. Explore these areas deeply while also keeping an eye out for unexpected behavior in nearby functionalities.
Exploratory testing aims to achieve strategic coverage via smart decision-making. While exploring, use your understanding of the system under test, past knowledge, and experience with this and similar systems:
Cover critical flows
Explore edge cases
Try variations (such as different inputs, sequences, interruptions)
Execution Flow
When executing an exploratory test, follow these steps:
Review the instructions and focus points.
Each exploratory test includes a description and a set of focus areas, listed in the Focus on section. Read through all instructions carefully before you begin testing.
Understand the purpose of the feature and the focus points β these guide what you should explore.
Plan your testing session.
Take notes as you go β ideas, test paths, odd behaviors, or areas you want to revisit.
The expected testing duration for each step is indicated in the test step title. Plan your testing and issue reporting to stay within this amount of time while still fulfilling the mission.
Explore within the focus areas.
Leverage your experience with the product and the featureβs context to identify potential weak spots.
Think beyond the instructions: What could a user do? What might go wrong? What are related areas that might be impacted?
Be curious!
Document what you tested and log issues clearly.
Testing Time
The time allocated for testing a particular step is given in the test step title. Read all instructions and set priorities based on your testing strategy.
How to use your time effectively:
Read all instructions before starting.
Divide your time across the listed focus areas, leaving some buffer.
Example: If you have 30 minutes and 3 focus areas, allocate ~8 minutes each.
Prioritize areas with:
High user impact
More issues/problems historically
Mentioned risks or areas with recent changes
Avoid spending the entire session on a single path unless explicitly told so in the instructions.
Your goal is to maximize coverage, learning, and issue discovery within the allocated time.
Please note that issue reporting time is already included as part of the overall task assignment and is not compensated separately. Exploratory testing tasks are viewed as being compensated on the basis of completing the task, rather than an hourly basis.
Test Data
Good exploratory testing requires diverse inputs and scenarios to find hidden issues.
Use a variety of data, not just the βhappy path.β Consider different user personas and perspectives (such as new vs. existing users, power-users vs beginners)
Try edge cases, extreme values, missing values, incorrect formats, and so on.
Use different account types if applicable (including logged-in/logged-out users, new users).
Vary test conditions (low connectivity, orientation changes, backgrounding the app) when relevant.
Please note that according to the FSA (see 2.15), you are not permitted to use public artificial intelligence tools while performing services for Testlio. When agreeing to the FSA, you acknowledged and agreed that you will only use artificial intelligence tools that are available on the Testlio platform, and only to the extent enabled in a workspace. In addition, you agreed to comply with the AI Acceptable Use Policy.
Mark Results
When performing exploratory testing, it is important to provide a record of what you tested, what worked and what did not, and where you have additional considerations and questions for future testing.
Separate your notes by features or the area you explored. Use the same features/areas listed in the Focus on section.
Under each feature/area, list the high-level behaviors and scenarios you tested.
Start with action words like: Verified, Investigated, Checked.
Be specific β avoid overly broad statements like βTested the appβ.
Focus on testing activities; donβt include lengthy explanations. List only the high-level testing ideas you covered. Don't list every detailed scenario, but make sure to include all important notes.
Use symbols to mark your results:
+= Expected behavior verified-= Expected behavior verified, but an issue was found (include the issue number)[?]= Reported questions related to the feature under test (when reporting questions is allowed in the workspace)[i]= Reported improvements related to the feature under test (when reporting improvements is allowed in the workspace)[A]= Additional test ideas (optional)
If a particular flow uncovered an issue, mention the issue ID. Donβt forget to also link all issues to the test step using the + Issue button.
Use the following guidelines when documenting the results of your exploratory testing. Each section helps us track what was tested, what issues were found, and what needs a follow-up.
Results Report Format
[Feature/Area]: Use this section for each feature or area you explored. List down the scenarios you covered. Symbols: - Use + when you verified expected behavior or completed a test successfully - Use - when you found an issue or inconsistency (include ticket numbers) [Feature/Area]: Split features into separate sections when needed to keep the notes clear and easy to follow. If all scenarios cover the same area, separate sections are not necessary. Questions (optional, add only if something is unclear): Use [?] to document anything unclear or requiring clarification regarding the features under test (add ticket numbers). Improvements (optional, add only if you have something to point out and improvements are allowed to be reported): Use [i] to document improvement ideas regarding the features under test (add ticket numbers). Additional test ideas (optional, add it only if there is something to point out): Use [A] to list anything you were not able to cover this time.
Results Report Template
[Feature/Area]: +/- +/- [Feature/Area]: +/- +/- Questions: [?] Improvements: [i] Additional test ideas: [A]
Results Report Example
File upload: + Verified that file upload handles unsupported file types + Confirmed that the upload progress indicator displays correctly for large files + Investigated behavior when the network connection drops during upload File search: + Verified that there are valid errors when entering special characters in the File search bar - Investigated filtering and sorting features on the listing page (#123456) Questions: [?] Is the search supposed to return partial matches or only exact matches? (#223456) Improvements: [i] Unable to remove an added image before upload (#334567) Additional test ideas: [A] Test file upload cancellation during upload and image preview after upload
Was this article helpful?
Thatβs Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article