Please can you tell us who you are and what you do?
I’m Fred Stevens-Smith, one of the co-founders of Rainforest. I’m a designer and developer. Rainforest does QA as a service. We’re based out of San Francisco, but we are originally from London. We’re currently a team of 4 engineers.
Rainforest is our attempt to drag QA tools into the brave new world of beautiful, usable webapps. We’re starting with functional front-end testing. Our theory is that checking the core functionality of your web app should be part of the deployment process, should be triggered automatically so you don’t have to think about it, and should involve no infrastructure setup and minimal time investment up front by your team.
You’ve approached the multi-browser web-app testing problem in quite a unique fashion. Can you explain why you decided this was the best solution for your customers?
We took the ‘concierge MVP’ approach when we started Rainforest, so we spent a couple of months being a small QA shop. We wanted to do this to really understand the problems and bottlenecks with the current tools and processes, to feel the real pain of doing QA. And hell was it painful. Basically once we were working on this full time, we realised that we were mostly limited by the number of hours we had in the day to execute tests, so we decided to try crowdsourcing to remove the bottleneck.
It worked and became the basis of Rainforest’s stack. Nearly every major system design decision happened this way.
Continuous Deployment is apparently the new agile. How well does your solution fit into this model?
We built Rainforest because of Continuous Deployment. From our customers’ perspective, CD is awesome because it enables them to ship fast and often, to constantly be improving their product and iterating on customer feedback. However the big pain point is that maintaining good test coverage of your front end becomes very difficult.
So we designed Rainforest to fit into this new workflow, because we practise it and we felt totally underserved by the quality tools and processes available to us. At a high level, it should:
- Have a fully featured API.
- Have a command line interface to make running tests trivial.
- Be simple to integrate with whatever CI process we’re using.
Also, it should:
- Be simple to use for non-technical users.
- Make it easy to create tests.
- Most importantly, make it trivial to update tests.
Let’s say I have 200 browser tests that I currently run as part of my build and deploy process. If I wanted your testers to run those tests across the 4 main browsers, how long would it take them and how much would it cost?
The time it takes depends on time of day and complexity, but between 30-45 minutes. Our plans are based on a number of steps you can run in a month, so you would want to be on the Medium plan to be able to run this test suite. You’d be able to run this suite 3 times in a month on this plan.
We really want to work with the forward-thinking part of the QA community to make Rainforest as useful as possible for testers. We’re doing our job right if you get promoted for introducing Rainforest. So we need feedback!
If you are finding yourselves overwhelmed by the amount of time you spend checking apps in your testing jobs, you should definitely check out our tool at RainforestQA.com.