Become a Beta Tester
- Chris Shaw (Unlicensed)
Beta-Tester Program
How to Join?
To participant in the Beta Testing Program, please fill out and return the Disclosure Agreement and forward to support@sciencetrax.com
Release Cycle
Typically, there are at least two major releases and two minor releases of StudyTRAX each year. Beta testers can be involved throughout the development process, but most often are involved once internal testing is nearing completion.
Reporting Bugs
The goal in beta testing is two fold: 1) Find any bugs, and 2) Document the steps to reproduce the bugs found. The most important thing for eliminating bugs is documentation that our developers can follow that reliably reproduces the bug. Without being able to know how to reproduce a bug, the ability to fix a bug is serverly happered.
The article, “How To Report a Bugs Effectively” provides a good summary of bug reporting. Below are some recommended guidelines for bug reporting to ensure the most effective communication and resolution of a bug report.
Summary
- The first aim of a bug report is to let the programmer see the failure with their own eyes. If you can’t be with them to make it fail in front of them, give them detailed instructions so that they can make it fail for themselves.
- In case the first aim doesn’t succeed, and the programmer can’t see it failing themselves, the second aim of a bug report is to describe what went wrong. Describe everything in detail. State what you saw, and also state what you expected to see. Write down the error messages, especially if they have numbers in.
- When your computer does something unexpected, freeze. Do nothing until you’re calm, and don’t do anything that you think might be dangerous.
- By all means try to diagnose the fault yourself if you think you can, but if you do, you should still report the symptoms as well.
- Be ready to provide extra information if the programmer needs it. If they didn’t need it, they wouldn’t be asking for it. They aren’t being deliberately awkward. Have version numbers at your fingertips, because they will probably be needed.
- Write clearly. Say what you mean, and make sure it can’t be misinterpreted.
- Above all, be precise. Programmers like precision.
Keys to Bug Reporting
- Replicate— Ideally, the bug report should be able to re-create the bug from the information contained in the report. Almost as good is the tester being able to re-create the bug on command. Less good, but acceptable, is admitting that you can’t re-create the bug, but describing how you tried to re-create it. Bad is not trying to re-create the bug, not admitting when you can’t, and/or not putting whether or not you can replicate the bug in the report.
- Isolate— Bug reports are more powerful and are generally taken more seriously when the steps to re-create the bug are simple. By isolating the actual bug — separating it from any incidental or unrelated steps you took the first time you observed it — frequently enables you to document the most direct (or at least a very direct) path to replicate the bug. It also minimizes opportunities for confusion in the report.