In addition to providing requirements for each Exploratory run, you can also provide additional parameters to help further focus each Exploratory run and optimize your results. A parameter in the context of Exploratory additional guidelines that provide context in a run. Below are some types of parameters that have proven helpful in guiding testers through an Exploratory run.

1. End user resources

End-user resources are any resources that you would provide to an end-user of your application. Such resources can take many forms, from documentation from your support center to videos showing an end-user how exactly the application works.

Why provide end-user resources?

End-user documentation has proven helpful in many ways. Not only does it clearly explain how a feature or application should work, by providing context in both test-creation and bug-finding scenarios, but is also acts as an accessible guide for the tester for the during of the run. 

How to provide this parameter to testers?

To be helpful parameter to testers, end user resources must be accessible. To that end, support documentation can be provided directly from your help or support center via a direct link. Alternatively, documentation could be provided as a PDF or other document type and attached to the Exploratory instruction form. Again, the important thing is for this documentation to be accessible.

2. A list of known Bugs

A list of known bugs is exactly what it sounds like: a list of some sort that details a known bugs that have not been addressed.

Why provide a list of known Bugs in the first place?

The primary purpose of providing a list of known bugs to testers during an Exploratory run is to have testers use their time efficiently and not report back bugs that are already known to your team. A list of known bugs can also help testers contextualize what a bug looks like within your application.

How to provide this parameter to testers?

Because a hypothetical list could be anywhere from 1 to 100, how to let testers know these bugs can change. If there are just a few known bugs, these could be easily logged within the instructions themselves. If the list is more expansive, perhaps a document such as an excel sheet would be more suitable.

3. Ranking testing areas of focus by priority

Ranking areas of focus by priority is a process where you identify which areas of you application or feature are the most important to test during an Exploratory run. 

Why rank areas of focus?

Giving or ranking areas of focus has an effect similar to providing a list of known bugs as it steers testers toward areas you want them to focus more attention on.
If there are multiple areas that you want Exploratory testing done on, we highly suggest that you discuss run details with your Rainforest CSM.

How do I rank areas of focus?

Very simply: all you need to do is specify the areas of your application that should take priority in the test instructions. This could be as simple as identifying these key areas as the primary purpose of the run and adding instructions for testers to test other areas after testing these primary areas.

Dialing in these parameters for each Exploratory run will help hone and focus your results. If you have any additional questions on how to turn these dials, please reach out to us at support@rainforestapp.com!

Did this answer your question?