What QA Teams Need to Know about Rainforest: Featuring Ryan von Rosenberg for CareCloud

ryan von rosenberg QA engineer for carecloud

For many QA teams that are thinking about implementing Rainforest QA, our platform represents a significant change to the way they plan and execute their QA strategies. To gain some more insight into what it’s really like to use Rainforest, we went straight to the source.

We chatted with Ryan von Rosenberg, a QA Engineer at CareCloud, about how he and his team have been using Rainforest. From the challenges of ramping up on test writing to the benefits of using Rainforest as part of his weekly workflow, Ryan shared his perspective on what it’s like to use Rainforest as a QA, and how other teams can use Rainforest successfully.

Want to see what Ryan had to say about a specific topic? Jump to the section you're interested in below:

1. Rainforest workflow 4. Ramp up & training
2. Time savings 5. Communicating results
3. Test automation 6. Advice for new users

Let’s get straight to it. What problems does Rainforest solve for your QA team?

Rainforest frees up time and helps us find bugs, because we don’t have to focus only on happy path testing. As soon as we get our acceptance criteria from the PMs, we’re able to quickly build a rough draft of a test case in Rainforest. Because our happy path is covered by Rainforest, we can almost immediately start working on edge cases -- where we often find bugs that normally might not be found until after release, when customers are using it.

Rainforest also gives us the ability to have tests run by someone who isn’t used to seeing the system every day. Having new eyes on the product is great -- we know that if they see something weird, they’ll let us know.

Additionally, it helps us with better documentation of our tests, which is essential in case anyone leaves the team.

What does your workflow look like with Rainforest? How has your day-to-day changed?

Before Rainforest, I spent probably most of the week doing happy path testing, with a day or day and a half of edge case testing. That led to some burnout -- manual testing work can be mundane and really tiring. There was pressure to complete happy path testing, run edge cases, answer questions, and get feedback in a short time.

Now, the first couple days of my week are primarily in Rainforest. Our developers release what I need to test into a testing environment. While those Rainforest tests are running, I’m working on edge case work.

The rest of the week is pretty much free to work on other things. I have so much more time to actually help my team instead of being stuck in happy path testing. Instead of worrying about not having enough time to complete my manual test plans, now I get to think about how to fill my time with adding value my team. Rainforest has made it so I have time to answer questions, help others understand how to use Rainforest, and walk around the office and maybe play a few pranks on people.

How much time does Rainforest save your team on testing?

A lot of testing pre-Rainforest was happy path testing. Doing that we were able to get lost -- because we already knew the happy path, our minds got locked into it. With Rainforest we save probably 1-3 hours just on happy path testing for each user story. In total, my team has about 40-60 test cases per release. This is up to 180 hours per sprint saved for my team by Rainforest.

You also have an automation team -- how does Rainforest support your automation efforts?

One of our core uses of Rainforest at CareCloud is alongside the automation team. Our automation team pairs every automation script with the corresponding Rainforest tests. When we kick off our automation, if an automated test case fails, we programmatically fire off the paired Rainforest test to validate our automation result. If that Rainforest test passes, we can move forward and know that the automation case might need to be reworked. If the Rainforest test fails too, then we know something may have a real bug.

Let’s think back on when you first started using Rainforest. How challenging was it to use?


I’m a gamer and I love games. Rainforest doesn’t feel like work to me. It feels like I’m creating a game, where my challenge is to write the steps in a way that someone unknown force is going to run through the steps and get to the right endpoint. If I do, I win! It’s like a puzzle that I get to put together.
When I first started with Rainforest, it was one of the most obnoxious things I’ve had to learn. Most people have a more ordered brain, which is something Rainforest is really good for. Rainforest was something I had read up on and research before my team started using it. What was a surprise was once I got it in my head how Rainforest needed to work. After about a week, I was able to quickly write about 5-10 test cases every 2 hours and have them all pass. Once I understood the mindset of the testers, I was able to just go for it.

I’m a gamer and I love games. Rainforest doesn’t feel like work to me. It feels like I’m creating a game, where my challenge is to write the steps in a way that someone unknown force is going to run through the steps and get to the right endpoint. If I do, I win! It’s like a puzzle that I get to put together.

The Rainforest platform UI is clean enough that i don’t get tired of looking at it. It’s so much fun to write these steps and make it cleaner, faster and more efficient. It’s really rewarding that I get to create something that has value to me, to my job, and my company. Rainforest is one of the most enjoyable systems I’ve had to use.

What has ramp up on Rainforest looked like for the rest of your team?

We’ve had two cases of having to ramp people up on Rainforest, and they’ve both taken about the same time to learn the platform. We had a support team member move over to QA, and a new guy join us. The new guy is still learning, but he’s learning every single day how to write tests better.

Thanks to Rainforest, we’re looking at new things every day, and learning every day.
The support team member has a lot of documentation experience, and immediately took off with Rainforest. Rainforest is so similar to what he was doing in support that he was able to jump right in. The challenge he had was once we started using variables, since that wasn’t something he had experience with before. But he’s getting better every day.

The key benefit is that the team is not stagnating, which is something a lot of people fear in their jobs. Thanks to Rainforest, we’re looking at new things every day, and learning every day. It’s amazing for us to have more time to do what we want to do, rather than just what we need to do. All in all, I’m about as happy as I’ve ever been as a QA, thanks in part to Rainforest!

What was the moment that made Rainforest click for you?

I’ve had a couple! My first “aha moment” was the first time I got a long, detailed comment from a tester, where they explained why a test didn’t work. I pushed back for a while, because I thought it was clear enough. As soon as I started thinking from the tester’s perspective, I understood how to break things up to make them easier for the tester to execute.

The second one was after talking to the fantastic support team at Rainforest (Hi, Ivan!), who helped me figure out a complex use case that Rainforest could solve that I did not think it would otherwise. Ivan helped me figure out how to use environmental variables. When I was learning about it, I thought there was no way it would be quite that easy -- I can just grab an ID from the variable sheet, and at run time it just pulls one! Rainforest helped solve that problem in a way I didn’t think it would be able to.

How do you share how valuable Rainforest has been internally? How can you help the rest of the organization understand its success?

We’re still ironing out exactly how that works. We’re trying to be as open in our communication as possible; we constantly talk with not just execs, but our automation team as well. We’ve given a presentation to the developers so they know what Rainforest is all about and understand how we’re using it.

We also have a backlog of things we want to get into Rainforest, and we stay a little later once a month to work at that. We’ve had our CEO and our CTO both come in during that time and see what’s going on. They’re able to see what’s passing, what’s failing, and what’s getting worked on. Our entire company has been supportive of us and encouraging the adoption.

What advice do you have for new Rainforest users who want to get the most out of it?

Even if a test case seems like it’s failing a lot, even if you’re using a lot of credits or you don’t want to bother any more, give it an extra shot. Read the comments that the testers leave you. You might have written the test fine for you, but you have to remember that testers have never seen your software before, if they see something out of place, they’ll note it. That’s why Rainforest is so effective.

Don’t be afraid to ask questions, and don’t be afraid to make mistakes.
My other piece of advice is don’t be afraid to ask questions, and don’t be afraid to make mistakes. Those two things are going to come up in Rainforest.

Find out more about what Ryan’s team is working on at CareCloud. To learn more about how Rainforest helps teams improve their QA processes, check out our features here.