3 ms·

Great to see this shift! I’d be curious to hear about the comparison to https://reflect.run https://reflect.run — I can imagine that access to the tester commu

by tekacs 5y ago

Great to see this shift! I’d be curious to hear about the comparison to https://reflect.run https://reflect.run — I can imagine that access to the tester community is a piece of that…

ukd1 5y ago
The obvious major difference is the ability to use the crowd as well as automate; which I believe is unique to Rainforest. Outwardly, the way they automate is very similar to us. Looking a little deeper, it seems like they _do_ use the DOM pretty heavily (from re watching the video at https://reflect.run https://reflect.run). For us, this is a fundamental difference - we do not believe in this; we want to automate testing-like-humans. It's harder, but we believe replicating how a human would detect things working or not (visually, via kvm) ends up with less brittle, easier to maintain tests that are closer to the reality of how a human would interact with your app. Also, we test using VMs (or physical devices if needed for mobile) - allowing us to test the browser, or any other kind of software. This lets us support a large combination of OS and browser variants out of the box, or custom images for enterprise. Reflect doesn't seem to support more than Chrome when I last looked.
- ukd1 5y ago
  Digging a little more - their pricing; our free plan seems equivalent (yet with better data retention, and no user limits, and email testing included) to their $99/mo plan.
fredsters_s 5y ago
the other major difference is the design principles: our core belief is that everyone owns quality, and so we build for the 'no code' user as well. It's a really hard bar to hit, but I think we've done a good job so far - to use reflect you need to be far more technical. 1/3 of our daily users are PMs.
tmcneal 5y ago
Hey there - I'm one of the co-founders of Reflect so just to give my perspective: The workflow for creating tests in Reflect is pretty similar to Rainforest: we both expose a "cloud browser" that loads up your webapp and you interact with that to create your tests. The biggest difference workflow-wise is that Reflect records all your actions automatically, whereas with Rainforest you often need to both specify what step you're going to take, and then actually perform that action in the browser itself. Recording everything automatically is technically harder to pull off since it's forced us to ensure we accurately record every step you take, but we think it makes for a better workflow since you can create tests faster, and there's less chance of inaccuracies that cause tests to not be repeatable. I would quibble with the statement that you need to be far more technical to use Reflect - we're a no-code product after all. :) We have plenty of folks who aren't developers using our product. But the good thing is that both products have free tiers, so users can always give us both a try for free and decide for themselves. Edit: Also their statement about Reflect running in headless mode is incorrect. Our test grid is a cluster of VMs: we spin up a Docker container for each test run, and each Docker container is running the test steps using a normal non-headless browser.
- fredsters_s 5y ago
  Oh good catch Todd, sorry about that - updated. And totally agreed, both products take a slightly different approach and have different strengths and weaknesses, try them both and see which is a better fit!
  - lharries 5y ago
    What's the reason the Rainforest would need to declare "Left click" before doing it rather than just having the user do it?
    - ukd1 5y ago
      It was a design choice; for some actions it's possible - click being a great example - for others it's not e.g. hover; are you thinking, or actually hovering? ...waiting: are you thinking or trying to add a wait to the test? So, we went the route of having the same way of doing things for everything. We may change this in the future, but at the moment it's consistent and easy to learn. You add an action, then run it - no need to do it twice, or learn multiple ways of doing things.

by tekacs 5y ago

Great to see this shift! I’d be curious to hear about the comparison to https://reflect.run https://reflect.run — I can imagine that access to the tester community is a piece of that…

ukd1 5y ago

The obvious major difference is the ability to use the crowd as well as automate; which I believe is unique to Rainforest. Outwardly, the way they automate is very similar to us. Looking a little deeper, it seems like they _do_ use the DOM pretty heavily (from re watching the video at https://reflect.run https://reflect.run). For us, this is a fundamental difference - we do not believe in this; we want to automate testing-like-humans. It's harder, but we believe replicating how a human would detect things working or not (visually, via kvm) ends up with less brittle, easier to maintain tests that are closer to the reality of how a human would interact with your app. Also, we test using VMs (or physical devices if needed for mobile) - allowing us to test the browser, or any other kind of software. This lets us support a large combination of OS and browser variants out of the box, or custom images for enterprise. Reflect doesn't seem to support more than Chrome when I last looked.

ukd1 5y ago
Digging a little more - their pricing; our free plan seems equivalent (yet with better data retention, and no user limits, and email testing included) to their $99/mo plan.

fredsters_s 5y ago

the other major difference is the design principles: our core belief is that everyone owns quality, and so we build for the 'no code' user as well. It's a really hard bar to hit, but I think we've done a good job so far - to use reflect you need to be far more technical. 1/3 of our daily users are PMs.

tmcneal 5y ago

Hey there - I'm one of the co-founders of Reflect so just to give my perspective: The workflow for creating tests in Reflect is pretty similar to Rainforest: we both expose a "cloud browser" that loads up your webapp and you interact with that to create your tests. The biggest difference workflow-wise is that Reflect records all your actions automatically, whereas with Rainforest you often need to both specify what step you're going to take, and then actually perform that action in the browser itself. Recording everything automatically is technically harder to pull off since it's forced us to ensure we accurately record every step you take, but we think it makes for a better workflow since you can create tests faster, and there's less chance of inaccuracies that cause tests to not be repeatable. I would quibble with the statement that you need to be far more technical to use Reflect - we're a no-code product after all. :) We have plenty of folks who aren't developers using our product. But the good thing is that both products have free tiers, so users can always give us both a try for free and decide for themselves. Edit: Also their statement about Reflect running in headless mode is incorrect. Our test grid is a cluster of VMs: we spin up a Docker container for each test run, and each Docker container is running the test steps using a normal non-headless browser.

fredsters_s 5y ago
Oh good catch Todd, sorry about that - updated. And totally agreed, both products take a slightly different approach and have different strengths and weaknesses, try them both and see which is a better fit!
- lharries 5y ago
  What's the reason the Rainforest would need to declare "Left click" before doing it rather than just having the user do it?
  - ukd1 5y ago
    It was a design choice; for some actions it's possible - click being a great example - for others it's not e.g. hover; are you thinking, or actually hovering? ...waiting: are you thinking or trying to add a wait to the test? So, we went the route of having the same way of doing things for everything. We may change this in the future, but at the moment it's consistent and easy to learn. You add an action, then run it - no need to do it twice, or learn multiple ways of doing things.