A Guide to Being an Effective Beta Tester

So you’d like to be a Unity beta tester. First of all - thank you!

Our QA staff works hard to make sure that our releases are stable, but there is no way we could do it without members of our developer community providing feedback on upcoming builds. We’re very happy that you want to help out!

To help you help us (help you), we have created this guide to being the best beta tester you can be - how to upload your project, how to write a bug report, and more. Following these steps will allow you to provide us with the most important information so we can fix problems that affect you and the development of your projects.

Your feedback on the beta is invaluable. We analyze every beta bug report rated 4 and 5, and do our best to look at those with lower ratings (if you’re not sure what that means, take a look at this blog post). When we have validated the bug and have a fix, we will schedule it for an upcoming beta release. We are currently unable to provide details on which fix will be in which beta, but know that it will be as soon as possible!

If you have further questions about the beta, visit the beta forum.


Part One - Installation and getting started

1. Download the latest beta build here. This page also contains information on the new features to test and stress.
   
   
2. Run the Installer, choose your options as usual, and be sure to install the beta in a new directory. It’s ok to have multiple versions of Unity side by side.
   
   
3. Make a copy of the project you plan to use for testing the beta, then open it with the latest beta version.
   • Make sure you create a copy in case the beta has regressions that might affect your project.
     
     
   • Note that when Unity opens a project, it automatically migrates the project to the version of Unity you’re using. So working on a copy of your project also saves you time to avoid having to re-import your project when you go back your current stable version.
4. Develop as usual and/or test new features and updates. If you think you found a bug, follow the next steps described in parts two, three, & four of this guide.

Part Two - The Beta Forum

So… you found a bug. First things first: go to the Forum

The Unity beta forum is a great community resource. You can see what other people have reported, get suggested workarounds for issues, and keep up to date with fixes. It’s also a good way to get in touch with someone at Unity if you have additional questions or information.

If you don’t find anything related to your bug, then it’s time to submit a bug report. Once you’ve submitted a bug, it’s also a good idea to come back to the forum and post a description of the bug you’ve submitted, so if others have the same issue they can add more context or provide their workaround.

Make sure to include your Case number (provided in your confirmation email) in the post so that our team can identify the bug report you submitted - it’s the first thing they will ask if you leave it out.

Another great resource is the public Issue Tracker, where you can vote and comment on bugs reported by other users. This helps our team prioritize which bugs to tackle first.


Part Three - Documenting and Reporting Your Bug

Bug reporting can seem a bit intimidating but it’s really not so tough, and it is vital to ensuring stability. Follow these simple steps to write a good bug report that our engineers will be able to easily understand and act on.

Open the Bug Reporter

While running Unity, go to Help → Report a Bug in the menu, or you can access it directly through the executable in the directory where Unity is installed. It will also launch automatically if you experience a crash.



Provide Basic Information

In the “What is the problem related to” field, select whichever option aligns best with the bug you are reporting. Since you’re reporting a bug in the beta, it will usually be “A problem with the Editor” or “Crash Bug.”

In “How often does it happen,” you will need to indicate if this is a problem that you have only experienced once, sometimes, or every time you take the steps that led you to encounter it.

Provide your email address in case our team needs to contact you for more information.

Indicate whether the bug should be shared with the community through the public Issue Tracker. Only the text written in the “Title” and “Describe the problem” fields will be made publicly available, and sharing your bug helps the community. Other users will be able to comment, vote (which aids with prioritization for fixes), and see when a fix is available. If you choose not to share your bug publicly, all information will be kept confidential.



Identify the bug

In the most concise terms, how would you describe the bug? Keep it short and specific, like:

Clicking the Build to PC button causes Unity to crash.


Categorize the bug and write the title

If you had to categorize the bug, what would pick? UI? Asset import? Scripting? Specific Platform? We generally put editor crashes in their own category, so that’s what you would pick in this scenario.

Okay, now add that and your bug description to create the title in the following format:

[Category] description

In this scenario, your bug title would look like this:

[Crash] Clicking the Build to PC button causes Unity to crash.



Provide the Steps to Reproduce

The Unity QA and Development teams need all the help you can offer in diagnosing and fixing an issue. Depending on the information they receive, they may not be able to identify the root issue, or they may get misled and fix something else that isn’t your bug. So, it’s in your interest to provide as much information as possible up front to make sure your issue definitively gets addressed.The easiest way to do this is usually to backtrack through the steps you took prior to encountering the bug. So, what was the very first thing you did before you saw the bug?

Clicked the Build to PC button.

So that is the last step in the Steps to Reproduce. What did you do right before that?

Opened up the Build Settings.

Keep doing this as far back as you can remember, ideally to when you first opened up Unity. The more information you can provide, the easier it will be to reproduce and fix. If you can’t remember everything, see if you can reproduce the bug on your own. If that works, provide those steps. For instance, if you’re not sure exactly what you did before the bug occurred, but you can reproduce by just opening Unity, opening Build Settings, and clicking the Build to PC button, your steps would be:

1. Opened Unity
2. Opened the Build Settings
3. Clicked the Build to PC button
4. Unity crashes

Please note that you do not need to provide the steps in written form - for instance, you can submit the steps via video capture of your screen. What is most important is that it clearly illustrates the steps so that our engineers can recreate the bug.

Add the Expected Results

What did you think would happen before you encountered the bug?

For it to Build.

There you go! Use the following template to add your expected results:

Expected Results: summary

So to review, your bug report should currently look like this:

[Crash] Clicking the Build to PC button causes Unity to crash.

Steps to Reproduce:

1. Opened Unity
   
   
2. Opened the Build Settings
   
   
3. Clicked the Build to PC button
   
   
4. Unity crashes

Expected Results: Clicking the Build to PC button will continue and make a build.



Attach Your Project Folder

The Bug Reporter will automatically include your entire project folder in the bug report. Unless your project is already very small, it is recommended to remove the attached project folder and provide a new one that is smaller and more focused. This allows our QA and Development teams to isolate the issue more efficiently and provide a fix much faster.

To get the minimal project that reproduces your issue, you should try exporting the scene in which you encounter the bug, Then import it into a new project and see if the bug still occurs. If it does, upload the new, smaller project. If it doesn’t, you can keep trying with larger versions of the project.

The smallest project that recreates the issue is ideal, but large projects are definitely better than nothing, so please do include your whole project if you’re unable to narrow it down.



Perfect! You’ve put together an informative and concise bug report that our team can use to find and fix the issue. Just one last step:

Submit Your Bug Report

Hit “Send” to submit your bug report.

When your bug is submitted, you will be sent a confirmation email containing the Case number, which you’ll need to hold on to. The email will include a link to a web page with the current status of the bug. You can check back on that page anytime for an update.

Thanks to forum user @Peter77 for the following tip on keeping track of your bug reports and project folders:

1. Anytime you submit a bug report, create a .zip file of the project that you attached.
   
   
2. Keep a .txt file of the bug report itself and keep it in the Assets directory so that you know what error the project shows and how you can reproduce it.
   
   
3. After you submit the bug report, grab the case number provided in the confirmation email and prefix your .zip file with it.

This way, you can quickly find the project you attached to a report once Unity sends you an email to notify you that your bug report has been closed.

Upon receiving the notification from Unity regarding your bug report being closed, you can check to see if the bug has been fixed by finding the appropriate project and opening in the latest Unity beta. Follow the steps to reproduce, and you can easily determine if the bug is gone.

While this is a bit of work on your end, it means a) you are more likely to have a high-quality bug report, which means your bug is more likely to be reproduced and fixed, and b) you can easily ensure that the bug has been fixed in a future beta version.

Part Four: Follow Up

It is always ideal for our staff to be able to get in touch with you in case they have questions. Of course, they have your email address and can get in touch that way - be sure to respond promptly to any emails you receive from the team to ensure a faster bug fix.

If you didn’t see your bug mentioned in the forums, you can create a post. Remember that others may have experienced the same problem, so posting any workarounds you find is a fast way to make friends in the beta community!


That’s it!

Thank you for taking the time to learn how to be an effective beta tester. If you have questions about any of the above, please post them below.