All Collections
Test Types
Test Types: Bug Hunt
Test Types: Bug Hunt

Users explore your product and submit quality bug reports. Useful for Functional Testing & Exploratory Bug Testing.

Updated over a week ago

Our Bug Hunt test helps you quickly find bugs and technical issues in your product, across a range of real-world devices and use cases. By having a wide mix of testers go through your various features, you will discover issues across devices, operating systems, browsers, and more, that can't be found with in-house testing.

Our bug reports capture device information, and testers can add screenshots and videos to understand how to replicate the bug. You can also message testers within each bug report to ask questions and get more information.

Choose Bug Hunt from the test type section when you create a new test.

Test Details

Test Title

Your survey title is shown publicly to potential applicants during recruiting. Make it something relevant to your test, for example: "Bug test for a video editing app".

Brief description of your test

In the description, you can describe a bit about the test process or who you're targeting. This is also shown to applicants during the recruiting phase

How are my test title and description shown during recruiting?

When you launch your test, testers will receive an email invite with your Test Title as the email subject and Test Description in the email body. It will look similar to the screenshot below and will ask testers to apply to participate.

In the below email "We want your feedback on a new packaging design" is the Test Title, and "Help us understand what resonates..." is the Brief Description of Your Test.

Test Instructions (Bug Hunt)

Be sure to include:

  • Link to access your product (e.g. link to your website, TestFlight public beta URL, Play Store, APK, Firebase, prototype URL, etc).

  • Details on what you'd like testers to do. A Bug Hunt can be more "Functional Testing" with step-by-step tasks, or "Exploratory Testing" with high-level guidance.

  • Optionally attach any other document for instructions. Make sure it's clear and easy to understand, or you'll get poor results for your test.

If you upload a file (e.g. a spreadsheet with tasks) make sure any instructions you provide to testers are clear. It should not be a guessing game to understand what you're asking. Do not ask that testers update a spreadsheet that you provide with their test results. The output of a Bug Hunt are the bugs that are filed through BetaTesting.

Don't include:

  • Do not ask testers to update a spreadsheet or upload a document with their test results. The output of a Bug Hunt are the bugs that are filed through BetaTesting.

  • Don't put questions directly in the instructions. Instead, you need to include any questions you want to have answered directly in a survey itself.

  • Don't expect a tester to purchase something or go through a process that requires sensitive personal or financial information

  • If you have a complex functional test or a test process that requires multiple usage sessions instead, use the Multi-Day Test with the Advanced Test Workflow mode.

  • Don't provide a test process that can't be completed within 12 hours.

Timing & Pricing

How long do you want users to test

Provide a realistic estimate for how long your test process will take. You can give testers up to 60 minutes for a bug hunt. This should take into account the time required to get your product, go through features, and complete bug reports.


This section will differ if you're on a Recruit (pay as you go) or Professional plan.

Recruit Plan (pay as you go)

On our Recruit plan, you'll see a price per tester, based on the time required, test duration, and targeting requirements. This price is inclusive of all costs and tester rewards/incentives, and there are no additional fees.

Professional Plans (subscription plans or custom quotes)

On our Professional plans, you can customize the incentives provided for testers and provide an optional bonus to encourage high quality testing.

The Base Reward is the reward that all testers will get for following any tasks you provide and attempting to find bugs. For the base reward, our system automatically recommends average incentive amounts based on your test type, time expectations, and your target audience. You can learn more about choosing how much to incentivize in this article.

Define a Bonus reward to indicate that you will decide to provide bonuses at the end of the test to the testers that did a great job. You will have the opportunity at the end to choose which testers earned the bonus.

We recommend using a bonus to encourage more and higher quality bug reports.

Recruiting & Screening

You can choose your recruitment criteria and screening questions like you normally would on any test. Learn how tester recruiting works here.

Survey Design

Choose what survey you'd like testers to complete a survey after they finish your bug hunt test.

Standard Bug Hunt Survey

Our standard Bug Hunt survey includes a series of questions that allow you to analyze the quality and stability of your product (e.g. number of bugs found, technical stability, speed, ease of use, etc). This is a safe bet for any bug test, and you can use as-is or edit as you desire!

Building your own survey

You can build your own survey by using any of our base question types, or our core question bank. Learn about the various survey question types here and how to use show/hide logic here.

Participation Verification Survey: Linking feedback to your database usage data

BetaTesting does not integrate directly with your product. A Participation Verification survey is useful in the following cases:

  1. If you want to cross reference your user feedback to exact usage data in your database

  2. If you want testers to prove they participated fully and completed your tasks and instructions

The Participant Verification Survey is a simple 3 question standalone survey that asks testers for the following info:

  • Username / email / or phone number used to access your product, so you can cross-reference the dat

  • Screenshot to validate that they used the product

  • A few sentences about the testing experience.

You also have the option to add "participation verification" questions directly to any survey that you create. Choose "Verify Participation" within the Core Question Bank, and it will add these 3 questions directly to any survey.

Bug Report Results

After your test launches, you will see bug reports on your Bugs tab in your test. Each bug report includes self-reported data from the user that submitted the bug, such as:

  • Priority Level

  • Status

  • Title

  • Expected Result vs actual result

  • Bug Description

  • Attachments: screenshots or videos

  • Date Submitted

From this page, you can change statuses, delete bugs or mark them as complete, combine bugs as duplicates, search for bugs, and much more.

๐Ÿ’กWant to learn more? Book a call/demo with our team or get in touch through our contact form.

Did this answer your question?