Live data from Hacker News

Launch HN: Rainforest QA (YC S12) – No-Code UI Test Automation

news.ycombinator.com

51–60 of 89 posts

Re: Launch HN: Rainforest QA (YC S12) – No-Code UI Test Automation

#55
post #13

Earlier quoted context omitted.

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 s…

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!

What's the reason the Rainforest would need to declare "Left click" before doing it rather than just having the user do it?

Re: Launch HN: Rainforest QA (YC S12) – No-Code UI Test Automation

#56

Chiming in as a happy Rainforest user. This tool has been a huge benefit to our startup. It is a great way to maintain ongoing QA at a minimum cost of hours while iterating your product, and the built-in ability to get your test fixed by Rainforest for a few bucks or to have certain tests done by hand at an hourly rate is extremely useful and makes it simple to quantify the cost of outsourcing to rainforest vs doing…

Thanks so much - glad y'all love it!

Re: Launch HN: Rainforest QA (YC S12) – No-Code UI Test Automation

#57
post #39

This is amazing. Raising a Series B with an enterprise sales model, then releasing a self service, bottoms up product is like the hardest possible shift. Hopefully it's exhilarating.

It is definitely exhilarating, and a lot of work - but we're proud of what the team has done and where we are at today!

Re: Launch HN: Rainforest QA (YC S12) – No-Code UI Test Automation

#58

Looks awesome! How hard was it to get the testing working from visual alone? Would love to learn what you're tackling the problem technically?

It was pretty hard to be honest, but it was helped by the fact we already had our own virtual machine infrastructure that we use for the crowd side. Without that, it would be a much steeper hill to climb.

Re the problem itself at a basic level, it is balancing visual matching (what does and doesn't matter in an image, what is the match in the VM - is that acceptable, and how/why?), and OCR (what is there, what matters, etc), and timing and interaction issues and complexity as well, and for us has to work on basically any platform we can run in KVM.

Re: Launch HN: Rainforest QA (YC S12) – No-Code UI Test Automation

#59

Earlier quoted context omitted.

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!

What's the reason the Rainforest would need to declare "Left click" before doing it rather than just having the user do it?

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.

Re: Launch HN: Rainforest QA (YC S12) – No-Code UI Test Automation

#60

Earlier quoted context omitted.

Agree, no-code seems to optimize for a large number of people being somewhat effective, but with less control over the output (increasing fragility, rework) Code is more upfront effort but more control and thus less fragility but more maintainable over time (if done right). I imagine there are some/many situations where throwing many people at a problem is the “best” way and this would suit that quite well I guess.

In my experience, many orgs that work with Selenium and its derivatives have described that (coded) approach as flaky / brittle (i.e., fragile). Of course, until automation gets to be as clever of humans, any test automation approach is going to have some flavor of brittleness.

Agreed; also, even with human testing, their nuance can be a double-edge sword. Testing, and specifically QA is hard - as today it's mostly about the "assurance" part; does one feel assured enough to ship this, which is subjective.
Post reply on HN