I think it's quite a nice idea, but I'm struggling to imagine myself using this. For a start, I want my tests in my source code repository. Secondly, I want to run my tests locally before I upload to production, perhaps even before I write the code to satisfy the tests.
I see that you have also developed a chrome extension so that one could run their tests locally. But that is essentially different from running your tests as a service. In this case you're essentially providing a testing library.
I could just about see myself writing my tests locally (perhaps using your chrome extension) and using the local tests for development and then uploading those tests and using a service to check a production server periodically. But I'm a little sceptical (why not just have the production server run the tests periodically itself?)
There may be some other uses for Web UI Automation as a service, for example scraping.
Hey HN, I built TestBeacon, a platform for writing web UI automations (think Selenium/iMacros) without ever leaving the browser. No native drivers or extensions to install (although we do have an extension for quick writing/testing of scripts! https://chrome.google.com/webstore/detail/testbeacon/ibonccc...). I wanted to be able to easily access and share automations so each one has a unique URL and can be ran at the click of a button.
TestBeacon can also run your tests in the background (via PhantomJS) and notify you of the results via email, with screenshots, console logs, etc. We run them on your schedule on a weekly basis.
TestBeacon runs on top of Flytrap.js (http://docs.flytrap.io), the programming language used to build and drive automations. It’s just a javascript library and interprets and runs scripts written in Flytrap. Just embed a single JS file into your web app, and you’ll be able to automate the mindless clicking around during feature development. The automation can then double as a safety-net for testing & QA, and used to spot-check problematic areas post-deployment.
Let me know what you think!