Hi. My name is Kinoshita and I work in the Eight division of Sansan. "Eight" is a free-to-use business card organizer and professional social networking platform for individuals, with over 2 million registered users. I am the lead of the QA team of Eight, and in this post I will talk about our experience adopting mabl this year.
Creating tests without code in mabl
mabl is an E2E test automation service for Web applications. It allows users to create tests while recording actual operations using Chrome extensions, which makes it possible to create tests without coding. In addition you can also embed created tests into CI/CD to incorporate them into the development process, run cross-browser tests, and schedule designated tests to run at a predefined date and time.
The need for automation
At Eight, we run regression tests called "pre-release check" before releases. They run to ensure that the added and/or modified functionalities do not unexpectedly affect other functionalities. We run these tests before every release. However, for Eight's server-side and Web front-end updates, we were not able to run for every release because of a few key problems - there were too many items to review in the pre-release check and the releases were delivered twice a week.
Too many items for the pre-release check
Eight has various functionalities including managing business cards as well as SNS elements such as profiling and posting, to organization-level functionalities such as employment platforms and card sharing functionalities, all of which has increased the number of items to check. To run adequate cross-browser tests manually required two to three full working days to complete.
Two regular releases delivered every week
Releases for Web aspects and server-side of Eight are delivered regularly twice a week. Running the above tests so frequently requires considerable test execution resources to run them. Under these circumstances, we have not been executing pre-release checks on the Web side every time. We have been running pre-release checks only for releases that would widely affect users, such as updating source code and version-ups of Rails.
Even so, the problem with high spending costs on every run remains. They could be run by using a lot of manpower, however, it is inefficient to spend two to three workdays for the same tests every single time - so we decided to automate them to gain operational efficiency and run tests for regular releases.
Why we chose mabl
1) Coding is not necessary
The primary reason we selected mabl is that it does not require coding to create tests. There are test automation options that require writing test code, like Selenium for example, but it also requires manpower of engineers who can code to create and maintain tests. With a tool like mabl, the ability to create tests without coding liberates things from the above restriction so that anyone can create and maintain the tests. This allows our team to allocate engineering manpower to developing new functionalities and modifications.
2) Includes the ability to test emails
You can also automate testing of email delivery with the mabl Mailbox functionality. It can test whether an email can be delivered to the expected address, or whether the behavior of the links within the email are correct. The mabl Trainer can issue dedicated email addresses. Sending an email test to the address allows you to check the UI and the links of the email on mabl Trainer.
3) Testing across web browsers
Many people face a common problem with regression testing - improving the efficiency of cross-browser testing. With mabl, the same tests can be run by selecting one or multiple browsers in a single click. It is also possible to select whether to run multiple tests simultaneously in parallel or browser-by-browser (sequentially).
Additionally, mabl can run designated tests when a pull request is uploaded on Git by integrating mabl into your CI tool. I am happy with it because it can be used for various purposes in addition to pre-release checks.
Increased test coverage
Now with mabl we run tests before each release every week. The advantage of adopting mabl is that we can now run the tests that we did not have time for, which has already yielded positive results by helping us detect defects that would have otherwise been difficult to identify.
*Special thanks to Kinoshita-san for sharing the Sansan story with our readers here. Visit https://buildersbox.corp-sansan.com/entry/2020/08/27/110000 to read the original post in Japanese and follow their journey with test automation.
See for yourself how easy it is to create tests with mabl? Sign up for a free trial today.
