Create an environment to keep creators focused and boost productivity through the sense of security that “MagicPod will watch at the end”!

BuySell Technologies Co., Ltd.

Browser testing

This time, in the 14th edition of our user interview, we are going to take a close look at an interview with BuySell Technologies Co., Ltd. together with Mr. Ito, the CEO of MagicPod touching on various topics, such as some concrete application case studies and determining factors in the tool selection process.

BuySell Technologies Co., Ltd.

“BuySell” is an integrated reuse service realizing the buy-and-sell cycle. In terms of purchase business, the corporate operates diverse channels domestically in Japan, such as store and home delivery purchases, with a special focus on mobile purchase services with more than 200K annual transactions. In the sales business, on the other hand, it manages purchased products and distributes them through its exclusive E-commerce sites and E-commerce malls, B2B secondhand auctions, as well as many other forms (2B/ 2C, etc.) in the optimal domestic/ international channels.

KEY POINTS

Explore the possibilities to create a test environment looking ahead to production operations.
A user-friendly tool not only for engineers.
Regular execution every 3 hours- it’s only MagicPod, and nowhere else.
Accelerate development and boost productivity through a sense of security.

(Left) Ryunosuke AKAGAWA, engineering manager, Development Team II
(Right) Takuma JIMBO, front-end engineer, Development Team III

The background of coming to MagicPod

Akagawa) My name is Akagawa, the engineer manager of Development Team II. Since I joined the company in 2021, I have been involved in a project called “BuySell Reuse Platform Cosmos”. The development of the Cosmos is through microservice, so we always launch multiple products at the same time. I am responsible for managing those products and I have been using MagicPod for “Store”, a product that aims to improve purchasing experience at physical stores.

Jimbo) I am Jimbo, a front-end engineer who belongs to Development Team III. I just joined this year as a fresh graduate, although I have been working on the development of Store as an intern since last October. Store was under Team II at first while Team III also got involved since the division of functions that we are in charge of the new functions. I used to be in charge of maintaining MagicPod while doing front-end development, but it is now entrusted to a subcontract QA member.

Ito, CEO of MagicPod) I heard that you guys have been using other automation tools, is that true?

Akagawa) That’s true. We have been using other no-code tools in other projects, not Cosmos. However, maintaining test cases remained some issues. The engineers in charge all agreed that we need to explore our options and after a string of comparisons, we found out that MagicPod was a much better choice indeed.

As for Store, I also wanted to create a test environment looking ahead to production operations. So, we adapted MagicPod for Store in March or April 2022.

Ito) Very much appreciated. What features made you think that MagicPod is a better choice?

Akagawa) There are two main reasons. First of all, its universality. Cosmos is developed through microservices with quite a lot of “0→1 phase” products. As we also expected a large number of git differences, it is definitely important to make the tests as easy to edit as possible rather than managing test codes with git.

Another desirable feature is having no limitation on the number of tests executions. We have to carry out more tests for the expansion of microservices, but it also brings about higher expenses. Yet, it’s not really a problem if we use MagicPod so now it’s used in the entire Cosmos system. Projects with other tools are also switching to MagicPod one after another.

Some other teams are still using code-based test tools, but they are not satisfied when the tests are not working as expected despite the huge amount of effort they paid. I believe that MagicPod is penetrating quickly in our company.

Jimbo) MagicPod is always our first choice when we explore test tool options for various projects. I feel like I am like a missionary promoting MagicPod at all times (laughter).

Ito) I’m just more than happy to hear that. Although the selling point of MagicPod is using no code, I would love to develop new functions to show code in scripts so code writers will also fall in love with our tool.

Akagawa) That would be awesome if code can be used for maintenance. I’m so looking forward to that!

Ryunosuke AKAGAWA, engineering manager, Development Team II

Case studies- Examples of Utilization

Ito) So, based on your user experience, what do you think about MagicPod?

Akagawa) It’s easy as it runs just after a few operations. Surely, I think you need some engineering background knowledge, but I’ve never heard of any problems from the QA members. I think it’s pretty much straightforward to use.

I did expect something about regression tests as degrading risk hedges, and it didn’t disappoint me at all. Once I started using it, I realized that it’s super user-friendly when we want to share the test cases. In the case of Cosmos, many authentication-related steps and user account assertions are, in fact, the same so I just found that development costs can be greatly reduced.

Jimbo) The Store team does all E2E tests through MagicPod, it’s carrying out a series of test cases on a regular basis. It’s essentially important to maintain the quality standard at all times by carrying out CI/CD normal system tests.

In terms of its functions, the AI's automatic correction works well for minor adjustments for a better style, which is extremely convenient, and since Store is a web app for iPad, I feel that being able to make use of an iPad emulator is also crucial.

QA members are in charge of modifying existing test cases and creating new ones in line with new functions. It's wonderful that the learning cost is kept low, and maintenance is easy even for non-engineer members.

Akagawa) Productivity is especially the top concern for our Store team and sometimes, we do more than 10 pull requests in one single day. I’m convinced that only MagicPod can accommodate this, nothing else.

Ito) 10 cases a day! That’s quite a lot!

Jimbo) We enable and disable repeatedly using feature flags when developing new functions, so it is about 3 to 4 requests in one day if they don’t affect users directly, but sometimes it’s as many as 10. Unit tests are run at the pull request stage, merged into the main branch at the interval of CD, and MagicPod is run when we launch things. If everything’s fine, it’s then the official flow of deploying. For such a scale, MagicPod is close to essential.

Ito) I feel like you guys are taking the usage of MagicPod to new heights. What about the tests for deployment decisions? How long do they take?

Jimbo) It could be as long as 6 to 7 minutes. We’re trying to make it under 5 minutes thanks to our QA members who take care of the adjustments.

Ito) Oh, 5 minutes…

Jimbo) Is it too…long?

Ito) No, not at all. It’s VERY SHORT!

Jimbo) Shortening the time is always our priority when we launch things, so we try hard to keep everything minimal. All test cases are watched by regular executions every 3 hours.

Ito) 3 hours? Your regular executions do come much more frequently when compared with other clients! It’s an ideal usage sample! You can enjoy more and more advantages of automation with such a usage weight. We’re pleased to support you guys to fit in your heavy usage!

A test tool to keep creators focused

Ito) I’m impressed as you clearly understand the importance of testing. Is this test-centric value part of your engineering culture?

Jimbo) It’s vitally important to eliminate failures, especially in the operation phase of Store, but I think you’re right- it’s our company culture that we all prioritize tests. We do a lot of in-house development, and we launch things every single day, so we do a lot of tests and all our engineers take an interest in increasing coverage.

Akagawa) Previously, we didn’t consider the importance of maintaining test cases this much. We then underwent a change in our engineering organization so now, members of our team all have the fundamental mindset to deliver “things with no bugs to clients”. We only have one QA member hence the competition is fierce. Some teammates then use MagicPod to create first and share that with the member.

Ito) That’s cool! Can I say you enjoy the merit of engineers also taking the initiative to test?

Jimbo) The investigations are smooth when there are technical problems. Testing has become a compulsory step in our development process in a good way. We can speed up our development as we know “MagicPod is watching at the end”, it’s a sense of security.

Akagawa) Creators all want to stay focused so things like AI automatic correction and passing things to QA without using codes made MagicPod a great tool.

Takuma JIMBO, front-end engineer, Development Team III

Conclusion

Akagawa) I believe that CI/CD must also be optimized in order to maintain high development productivity. Still, no matter how high the productivity is, the organization won’t earn anything if CI takes up high costs and labor costs. If you are thinking about MagicPod, take a look at its features and its different packages!

Jimbo) MagicPod is reliable also for QA members who can’t write code. The operation cost is unbelievably low as test cases can be created without code. Automatic execution is another attraction so engineers can concentrate on the development of their products as they don’t have to worry about manual testing. Test coverage is also amazingly high. If your productivity is being held back by manual tests and code-based E2E test usage, try MagicPod!