Whenever you open up your unreleased software to the outside world, you are exposed to some risk. As with most things in Rainforest, it's worth weighing up the risk you're exposed to against the complexity of mitigating that risk.
Typically most of our users are testing a staging server minutes before that code is shipped to production and open to the public. If this is your use case, there's not much that a tester can do that a regular user cannot do once the code is live. That said, there are several things to consider.
The most basic protection is the Terms of Service that all testers are subject to. This differs depending on the crowd they came from. We have used two main crowd providers to recruit testers in the past, and all testers are subject to either one of these:
It is your responsibility to ensure that all data provided to testers that is or may be personally identifying is sanitized correctly.
Good staging and QA environments mirror production environments as closely as possible. (If this sounds scary to you, our CTO's blog post on Optimal Environment Setup is well worth a read). Part of that is ensuring you have realistic data that is similar to what's on production. Credit card numbers, personal email addresses, phone numbers, and the like should all be obscured. It goes without saying that you should not give testers access to shared logins for critical parts of your application.
Most of our testers make their living with Rainforest. We have thousands of workers who rely on Rainforest as a source of income. As such, they do not treat this relationship lightly, and they work hard and diligently to do their job well. Testers are not driven by short term motivations, and since we have a single crowd of testers with many users sharing one crowd, each tester will test and see multiple websites and apps each testing session. It's worth considering this when assessing the level of risk.
Updated 2 months ago