In the Rainforest Customer Spotlight series, we highlight the superstars of the Rainforest QA platform: the Rainforest project managers (PMs) that write tests, manage databases and help build better quality processes for their organizations.
For this post, we interviewed Kristen Hill, who has translated her love of solving mysteries into a passion for hunting down bugs and creating great software at MassageBook. Read on to learn how Kristen has used Rainforest to boost her team’s test coverage to over 97%, and what advice she gives other teams on meeting their QA goals.
2book, Inc. provides a software called MassageBook, which provides professional bodyworkers with a success engine for their business. We offer massage therapists and bodyworkers the ability to attract new clients, keep their existing clients company back, along with all the tools they need to run their day-to-day business.
I’m in the role of Quality Assurance. Since we are a small company, I happen to be the only QA for 2Book, Inc. I never actually intended to be in QA. I always thought I’d be a forensic scientist using technology (and insects!) to solve mysteries. Instead, my path led me to 2book, Inc. where I was recruited to be a Customer Success Manager. I found a love for breaking things, and I got so good at it, that I was told that I should do it more often. You could say that I did end up specializing in mysteries, technologies and bugs after all!
We use JIRA to track bugs, enhancements or simple engineering tasks. When a developer has completed their work on a JIRA ticket, they send it to me to provide tests and feedback. Once I pass it, it goes into code review, and after it’s reviewed by our Engineering Director, it’s ready for release.
We release updates to our software every 2 weeks. Since our test cases are steadily increasing, the time it takes to test is also increasing. Currently the testing process alone takes about 3 business days, but with Rainforest the process is cut down to about 1 ½ business days to test a full release.
In MassageBook’s early days, we were happy to get around 75%-80% of release test coverage. Unfortunately, that left a large percentage of our product untested, and almost always resulted in users finding bugs in features. As our software matured and our user base grew, we had to find a better solution.
With the help of Rainforest, we’re rocking a steady average of 97.5% test coverage on each release. The team has noticed the impact, and our users see that our software has a steady level of quality that they can depend on.
On top of using JIRA to track our release creation process, we use Jenkins to build it to our test environment. I personally use TestRail on the side to organize test cases. TestRail aids me in tracking which test cases I have in Rainforest and which ones I plan to write for future releases. We also use HipChat for company communications, and the Rainforest integration for Hipchat is really helpful for alerting me to failures I have during a run.
For about the first six weeks, I blocked out about half the day just for Rainforest. If I hadn’t set aside that time, I would probably get distracted by something else that needed to be looked at in the company. The team came to recognize and respect that that time was reserved for Rainforest.
A few months ago I made a goal to get a specific amount of tests written and covered by Rainforest. During that time I spent my mornings testing bug fixes and enhancements that were meant to go into a release, and the afternoon was dedicated to writing tests in Rainforest.
Now that I have that goal met, I typically run Rainforest every other Thursday prior to release, then monitor the tests for any failures that I need to investigate. As soon as I confirm any failures in a release, I’ll pull in a developer and they’ll address it.
It was very hands-on. Since it was a brand new mobile platform, many of the test cases were also brand new. To get the best handle on it, I went into the application as if I were a user and thought about each flow. For example, if I’m supposed to be able to book an appointment, what are the steps that I’ll need to take to do that? I wrote out the test cases as I went through that thought process. I was able to copy and enhance some of our previous tests to reuse them where I could, but it was mostly all about getting into the application and making sure that I was creating clear, succinct test cases. In turn, that created success for the release of our new mobile platform with maximum test coverage.
Our secret sauce was creating links for our application that took testers straight into an account created for them to test in. Prior to that, there was too much complexity to our tests because every test had at least two steps just to log in. It was time consuming to the testers and it wasn’t really efficient overall. Our Engineering Director worked with me to implement state testing in Rainforest, and it has successfully sped up our test time for testers.
I wish I had asked a colleague to proofread the tests I wrote. When you’re writing tests for four hours a day you really get in the zone and can easily get “QA tunnel vision.” You think you’re writing a test with clear instructions, but you may have actually done it in an odd way that may be confusing. That can be avoided with a simple proofread!
Set daily goals and find your balance. At first, setting up everything seems like a daunting task if you have a lot of tests like we did. Finding a balance between how much you spend on your normal work responsibilities and the time you spend writing your initial test suite is vital. Within no time, you’ll find yourself transitioning to Rainforest without overworking yourself or stressing yourself out.
Check out MassageBook to learn more about what Kristen and her team are building. Catch up on our previous posts on Rainforest project managers here: