Does the UI output some kind of configuration file that can be checked into source control? If not, how do I maintain a history of test changes?
Launch HN: Rainforest QA (YC S12) – No-Code UI Test Automation
31–40 of 89 posts
Re: Launch HN: Rainforest QA (YC S12) – No-Code UI Test Automation
#32The hero gif seems to stop exactly before what I'm curious about: running the test. The mouse literally hovers there, and I even clicked on it thinking maybe it's like an interactive thing I have to continue.
Re: Launch HN: Rainforest QA (YC S12) – No-Code UI Test Automation
#33Re: Launch HN: Rainforest QA (YC S12) – No-Code UI Test Automation
#34Earlier quoted context omitted.
Whoops - that may have originated with me (habit). Fixed now - thanks!
Genuinely thought this was one of the worlds longest startup launches!
There was also this one just a few weeks ago - just a coincidence, btw:
Launch HN: RescueTime (YC W08) – Redesigned for wellness, balance, remote work - https://news.ycombinator.com/item?id=28683597 - Sept 2021 (141 comments)
Re: Launch HN: Rainforest QA (YC S12) – No-Code UI Test Automation
#35Ok, I'll bite. How do you integrate with the tested software? Do you a) run the tested software inside your VMs (if so, what's the integration API?) or b) expect your clients to run it (if so, how can the client authenticate your test access?)
Mostly b, but:
a) we can, if so generally they install it as part of the testing (e.g. a client testing a chrome ext), or have us build a custom vm for them (e.g. clients with 20gb download)
b) this is the common path; folks push something, ci builds it, ships to a qa env, they run us, if it passes, push to prod.
For B, Auth is handled anywhere from zero auth (just fully open QA env, but usually it's SaaS so you still have to login to their app), through to http auth, limiting the IPs (https://help.rainforestqa.com/docs/which-ip-addresses-do-rai...), to VPN directly into their QA infra. Without pulling numbers, I'd guess 95% go the zero-auth route.
Re: Launch HN: Rainforest QA (YC S12) – No-Code UI Test Automation
#36Does the UI output some kind of configuration file that can be checked into source control? If not, how do I maintain a history of test changes?
We support that for the human language tests, but not yet for the automation. A few customers have done it themselves by exporting the JSON (it's a defined, versioned schema), but we've not yet productized that.
Re: Launch HN: Rainforest QA (YC S12) – No-Code UI Test Automation
#37The hero gif seems to stop exactly before what I'm curious about: running the test. The mouse literally hovers there, and I even clicked on it thinking maybe it's like an interactive thing I have to continue.
There is a video on the bottom of https://www.rainforestqa.com/how-rainforest-works that shows the product being used, which should answer it!
Re: Launch HN: Rainforest QA (YC S12) – No-Code UI Test Automation
#38>>> slow down or pause the release process to do QA, or move faster at the expense of product quality This is a constant dilemma for Solopreneurs/very small teams. I was just thinking last week - can I find an affordable automated testing platform (need to run tests on new features that I've added to my latest project - an Electron App). Follow up question - does this work for Electron Apps? Either way, still happy t…
Yes, it works for electron apps. You'll need to host the binary somewhere, then install it. You can bundle those actions in to one test and then reuse as a building-block for your actual tests.
Re: Launch HN: Rainforest QA (YC S12) – No-Code UI Test Automation
#39This 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.
Re: Launch HN: Rainforest QA (YC S12) – No-Code UI Test Automation
#40What is the benefit of "no-code"? The benefit of using code is that you have to know what you are doing. Having experienced what happens when people build data driven systems out of building blocks, with out a thorough understanding of what they are doing (brittle, failing is strange ways under load, general unreliability and low quality) I am suspicious
At least for testing, and traditional automation (aka code) the bar is knowing what you're doing AND knowing the product enough to be able to test it effectively. We remove the code requirement, making testing accessible to more folks - i.e. product managers and product designers who have great knowledge of the product, but don't want to or can't code. Also, this doesn't tend to exclude developers either. Currently o…
Completely agree that testing should be more accessible to product managers and designers, and love the concept. Consider the simple example of a web form with multiple `input` elements - if I use your product to click on each input and configure a QA procedure, how does the system unambiguously identify each input given that the page layout may change in the future?
The current code-based testing frameworks force me to add an unambiguous marker to the `input` element, like an attribute or ID, which also makes it easy to query from the DOM during the QA process. How does this QA product handle breaking changes to the UI, and how robust could you expect it to be to code changes?