Overview
Structured exploratory tests are a form of manual testing that merges the pass/fail criteria of scripted tests with the flexibility of exploratory tests. With these tests, each pass/fail step defines the objective to be met but does not specify how to achieve it, allowing testers to explore and exercise creativity while meeting defined outcomes.
Coverage
While each verification step describes the main target to be achieved, you are also expected to validate the behavior of connected elements while achieving that main target. This means you need to apply different heuristics, critical thinking, and various testing techniques during the test, including, but not limited to:
Identifying high-risk areas and focusing on components that are most likely to fail or have the most significant impact.
Using past experience and intuition to find and interact with potential error-prone areas.
Testing Time
The time allocated for a structured exploratory test is listed in the prerequisites. Read through all the steps, set priorities, and divide the allocated time for each step to ensure you have enough time to complete everything.
Test Data
Explore the verify statement to cover both positive and negative scenarios, for example:
Positive scenarios: Verify the behavior when valid input data is provided. Consider the types of data that real users might need to enter.
Negative scenarios: Verify the behavior when invalid or unexpected input data is provided. Focus on system responses and the error messages displayed during negative flows.
Connected elements: Reflect on how real users might interact with the application and consider various user flows. If the target can be achieved via multiple pathways, cover each of the pathways.
Use different black-box testing techniques while selecting test data, such as:
Boundary value analysis to identify potential errors by testing input values at the edges of allowable ranges.
Equivalent class partitioning to reduce the number of covered flows while ensuring adequate coverage.
If a step requires you to cover all specific data options (such as going through all available languages), the test explicitly mentions this. Otherwise, apply these techniques to select only necessary data.
The time allocated for test also determines how in-depth you can go with data coverage. Always make sure to cover basic scenarios and basic alternations.
Execution Flow
The execution flow combines regular pass/fail and exploratory test execution practices:
Identify that it is a structured exploratory test. All of these tests are listed as such in the test title and at the beginning of the test.
Skim through the entire test to understand the coverage and time provided. This determines the depth of the testing you can perform.
For every step, verify the core flow together with alternations that are critical to this flow. Explore various ways to do the action and consider how real users might interact with the feature in different scenarios.
Optionally, find additional information as the Expected Result, including important details about the feature, such as limitations and known issues. Please note that you do not see any step-by-step testing instructions.
Marking Results
Consider the following when marking test steps:
Pass
Select Pass when the core flow described in the step can be performed without blocking issues.
Report related issues that do not block the flow.
Fail
Select Fail when you cannot follow the flow described in the verify statement or you meet severe obstacles in it.
After selecting Fail, either create a new issue or add a reproduction comment to an existing one.
Unable to test
Select Unable to test when the functionality described in the test step cannot be tested.
When selecting Unable to test, always specify the reason. Follow the general test execution guidelines.
Feedback
You are not asked to leave feedback about the flows you covered during one step.
Test feedback is for providing general comments about the test step when something is hard to understand or the test step could be improved.