Cypress vs Rainforest: Which is a better fit?

Dale: Hi, my name's Dale. I'm a senior software developer in test. I work for DoiT International. We have around 800 employees now but still growing very rapidly. And we use Cypress. And if I'm going to give it a rating, I'll probably give it four out of five because I think there's always room for improvement. And luckily, Cypress is constantly evolving. We've been using Cypress now at DoiT International for almost two years. Prior to Cypress, I was the first QA engineer to join, and all the testing was done manually, especially end-to-end testing. So it was a manual process which took a long time to complete. So I brought Automation and Cypress into the company and onto the platform that we provide our customers. So there's a lot of reasons why we chose Cypress actually. So first of all, I would say the great support. So there is an open-source element of Cypress, which keeps the community engaged. And there's also a profitable business side of Cypress, which makes sure that this is a project that continues even without that open-source contribution. That's one big reason. The other reasons are it has a lot of features built in, so you don't have to program around things. So one great example is built-in retries. So you don't have as much reliance on waiting for things because you know that the framework is capable of checking more than once without failing. The cloud platform is also... it's evolved, and especially in the last few months, it's evolved a lot. So now it provides a lot of really, really useful features. So we run all our Cypress tests in our CI, which is GitHub Actions, which is the orchestrator, and we have CI machines in Google Cloud. And to gain that window into the recordings of the tests, there's a Cypress cloud layer, and that gives us that information of when a test fails, why it failed, and enables us now to replay those failing tests with a level of detail that we've never had before. And that is really, really good. So I've been working with Cypress now for around five and a half years. And I came from a test lead, test management background and manual testing background. Cypress wasn't my first attempt at automation. I worked before with Selenium, also Detox for mobile testing. So I had some experience around some different types of coding languages. So JavaScript, TypeScript, Python, and therefore, for me personally, the introduction of Cypress into that stack was relatively easy. And from all the frameworks that I've used now over 15 years, I'd actually say that Cypress is one of the most user-friendly. And the reason for that is that the documentation that's available for it is very, very good. So if you're looking at Cypress for your company, I think you have to consider a few things. And from the top of my head, I would say Cypress is built for developers. So if you have manual QAs, which is a lot of traditional companies that are looking to bring in automation tools, you'll have manual QAs there. You have to consider their skillset, and you have to understand that in order for Cypress to work well in your company, you have to make sure that the people who are using Cypress also have that QA mindset. So it's very difficult to give Cypress to just a developer without a testing background and expect him to understand test case design and techniques well, and therefore, to take those test case design techniques and translate them into executable Cypress tests, which are effective in what they do. So you really need to understand what staff do you have and what staff may you need to use this tool effectively. I mean, there's no point in taking a tool and just deploying it in an organization without thinking about your organization. So that would be one big thing that I'd say that you really need to think through. And I've seen that done badly, and I've seen it done very well. Other things that I'd say you should consider is it is an investment and it does take time for it to become effective. So in two years at DoiT International, we now have over 300 end-to-end tests, and it's taken a team of three dedicated automation engineers to get to that point. So it's not a quick fix but if you invest the amount of value that you can add to your quality, and your deliverability is huge.