MagicPod CEO Ito spoke with RecoChoku Co., Ltd. about the deciding factors for choosing MagicPod and how they have utilized the platform from implementation to the present.

---

RecoChoku Co., Ltd.

Founded in 2001, RecoChoku provides and expands advanced services tailored to the needs of the music industry under the mission of "Maximize Music Market." The business is broadly divided into the "Music Digital Distribution Business," the "Solution Business," and the "Indie Artist Support Business" operated by its subsidiary, Eggs Co., Ltd. In the Music Distribution Business, the company launched the "Chaku-uta" (ringtone song) service in 2002 and has led the domestic music digital distribution business by developing download and streaming services for both individuals and corporations. In 2025, they began providing karaoke equipment manufacturers with "RecoChoku play," a licensing scheme that presupposes singing along with master recordings. In the Solution Business, they provide "murket," a platform specialized for music businesses to open EC stores, as well as consulting and business support services for music digital distribution businesses for rightsholders. Through their subsidiary “ Eggs," they provide a platform that supports the growth of indie artists.

---

---

---

---

From left:
- Kiyosaki (QA Promotion Group, IT Infrastructure Department)
- Kurashige (Manager, Product Development Group 2, NX Development Promotion Department)
- Nozomi Ito (CEO, MagicPod)

---

Kiyosaki: I belong to the QA Promotion Group within the IT Infrastructure Department, where I am in charge of quality assurance for company-wide system development. Currently, the QA Promotion Group is a team of eight people, including external contractors.

Since joining RecoChoku in 2006, I have primarily worked as a Project Manager. During that time, I began to think, "How can we improve quality after release?", but because my work up to that point was unrelated to QA, I spent my days struggling how to tackle this matter. It was then that I was transferred to the existing QA organization, and I became involved in quality improvement efforts as a member of that team.

Initially, we conducted manual testing using human testers, but as no-code and low-code E2E tools began to appear on the market, I became interested, thinking, "Perhaps we can implement this ourselves." Currently, incorporating E2E testing into the QA team and deploying it horizontally across the entire company has become my main responsibility.

Kurashige: I joined the company in 2022 and have been responsible for the development of "d hits® powered by RecoChoku" and other services as a mobile app engineer. Currently, I serve as a manager in the department known as the NX Development Promotion Department. I was also thinking about "how we should operate testing to improve mobile app quality," so together with Kiyosaki, we are promoting initiatives for quality improvement through collaboration between engineers and QA.

---

Challenges Before Introducing MagicPod

Ito: What kind of challenges did you initially face regarding quality?

Kiyosaki: The challenge was that within the release cycle, we had a rule that "manual regression testing must be performed after fixes," which ensured quality assurance; however, every time the number of devices or OS versions to verify increased, the test patterns grew due to the combinations, leading to a shortage of manpower, so we had to secure external personnel to conduct manual testing each time.

In that situation, the final QA phase of the release took a long time, so calculating backward meant the development period became shorter, and if we tried to cut testing, the adjustments were difficult. The biggest issue was that the burden of testing was too great to keep up with the release speed, and it was something I worried about daily. We considered introducing in-house test automation, but due to the many difficulties involved, such as environment setup, finding personnel to maintain and operate it, and maintenance resources, we gave up on it.

Kurashige: As a result, at that time, significant man-hours were also being allocated on the development side, with development engineers performing unit tests, creating and executing visual regression tests, and manually conducting smoke tests for every build.

Kiyosaki: For QA as well, adjusting resources was incredibly difficult when multiple test requests came in simultaneously. Therefore, around 2020, we introduced a no-code/low-code automated testing tool for browser testing.

---

---

Reasons and History of Selecting MagicPod

Kiyosaki: In our company, there is a higher demand for mobile app testing than for browser testing, so I felt that we could not achieve true efficiency unless we automated mobile testing. It was at that time I happened to learn about MagicPod, and I felt it had the highest affinity with what we were seeking. The biggest deciding factor was the point that we "can test on real devices." Actually, that was a mandatory requirement for us.

The choice was between "building a real-device environment in-house" or "using a SaaS solution," and considering the effort required for environment setup and maintenance, building it in-house was not realistic for a small QA team. Therefore, relying on a SaaS platform was a prerequisite, but just when I thought there were no tools capable of realizing this, the tool I found was MagicPod. We confirmed there were no issues during the trial and decided to introduce it immediately.

Ito: You mentioned that testing on real devices is important; specifically, what kind of testing are you performing?

Kiyosaki: It is testing on devices that cloud simulators cannot handle. Specifically, based on our quality standards, we need to ensure that the app —even when no changes have been made—works properly on new devices and the latest OS/firmware, so testing this manually every time is very difficult. In that regard, MagicPod was extremely helpful because it allowed us to perform checks equivalent to manual testing using locally connected devices, and we could also automate the process.

Kurashige: The introduction of MagicPod happened right around the time I joined the company and started working on my first product development. Kiyosaki told me, "There is a tool like this," and when I tried touching it, I thought it was revolutionary. I felt, "This is something all mobile engineers should be able to use," and began evangelizing it within the company.

Development engineers also possess a sense of responsibility regarding quality, but balancing what to prioritize while advancing development can be difficult. I feel that having MagicPod has deepened the collaboration with the QA team, leading to successfully striking that balance.

Now, a natural flow has been established where we issue accounts to newly joined members, saying, "We automate with this, so please learn to use it."

Kiyosaki: Previously, when we introduced the browser test automation tool, QA took the lead, so we had regretted that it ended up being viewed as "something QA does." Since mobile app testing requires development engineers to build a dedicated app, the cooperation of development engineers is indispensable. Therefore, I thought it would be faster to have them see it working first, so I had Kurashige watch a demo.

---

---

MagicPod Utilization Status

Ito: You signed up for the mobile app plan in 2022, and in 2024, you migrated your browser plan to MagicPod as well.

Kiyosaki: When tools are separated, the management effort, such as learning costs, becomes significant. When we tried using MagicPod's browser testing, the usability was almost the same as the mobile version, so we decided to unify them. Since the scenarios used in the previous tool could be handled by MagicPod, the migration was extremely smooth.

Kiyosaki: Currently, we basically run daily executions across all services. Since there are more than 10 products, we stagger the execution times by 10-minute intervals while considering device resources. We distinguish between the main branch and feature branches; we run the main branch late at night with an image close to external service monitoring, while feature branches are executed during the day to link with development.

When there are dependencies in the execution order, such as tests spanning both browser and app, we utilize MagicPod's label management and schedule functions to ensure they run in the intended order, such as "execute browser at 15:00, execute app at 15:30."

The results are notified to Slack, distributed into two types: a channel summarizing all products and distributed channels viewed by each product representative. When an NG (failure) occurs, QA first isolates the issue, checking "is it a server-side problem?" or "is it caused by an app fix?", before escalating it. We are always conscious of test stability so as not to become "The Boy Who Cried Wolf."

Ito: How is the collaboration between Development and QA conducted?

Kiyosaki: We hold a meeting once a week to track KPIs and discuss testing for new features. For example, regarding the issue that "tests are unstable," we sometimes ask engineers, "Please fix this so the locator can be specified uniquely."

Communication has increased dramatically with MagicPod as the hub, and the development side has started to show concern, asking, "Won't this fix break the scenario?", allowing us to grasp the future development status earlier, which enables QA to prepare in advance.

As a result of these improvements, we initially aimed for a pass rate of 80% at the time of introduction, but now we are able to maintain about 90%. The remaining 10% is mostly flaky tests due to communication environments or server response states, rather than product defects.

Kurashige: The development side is also building a workflow aiming for a state where scenarios are corrected the moment development is completed. We are still proceeding with improvements to this "development and testing cycle" together with QA, utilizing AI and other technologies. I feel it is a very significant achievement that MagicPod has become a catalyst for development engineers to seriously think about "what quality assurance is" and "how to design tests."

---

---

Eliminating "Manual Double Management" with Branching Features and Accelerating CI Integration

Ito: Within the development flow, are the tests for feature branches integrated with CI/CD tools?

Kiyosaki: Yes, we are gradually advancing the integration. Our test execution triggers generally follow two systems, as shown in this workflow diagram.

---

---

First, the left side of the diagram is the "developer-initiated flow" for each project. At the time when code is merged into the develop branch, GitHub Actions activate and execute the test for the MagicPod feature branch. If the test fails, feedback is sent to the developer, and the correction cycle rotates.

And the right side of the diagram is the "QA-initiated flow." Here, from a separate repository managed by QA, triggers for periodic execution, such as once a week, are set via GitHub Actions. Through this, the test for the feature branch is executed via the MagicPod API, creating a system where the QA side can also periodically check quality.

Kurashige: This is the current workflow premised on the "concurrent development and testing" we discussed earlier. Theoretically, we aim for a state where testing is also completed at the time when development is finished, and code freeze begins.

The branch configuration recommended by MagicPod is highly compatible with our development flow. We also position MagicPod's main branch as the "standard branch for the development environment," which runs automatically every day via CI tools.

If an engineer creates a feature branch for a new function, they can proceed with test preparation for the new UI without affecting the production environment or the test cases of the main branch. Since we can specify the branch even via command line execution from GitHub Actions, it was smooth to incorporate into our process.

Ito: How did you manage things before the branching feature was released?

Kiyosaki: It was exactly "manual double management." We duplicated the entire scenario and applied corrections to the duplicated one as a feature branch. However, this manual duplication management always carried the risk of affecting other people's work. Therefore, thanks to the branching feature, each person can add and verify changes in an "independent workspace," and I feel the greatest benefit is that the team can collaborate safely and rapidly.

In terms of man-hours, it became much easier, and CI integration became easier as well. It was truly a long-awaited feature. Previously, since we only had the single main branch, failures in a feature branch under development would affect the health score. We are also helped by the fact that the stability of the main branch has become easier to visualize now that the branches are separated.

---

---

Conclusion

Kiyosaki: When implementing MagicPod, we tend to make "cost reduction" or "solving labor shortages" the objective. I myself initially focused too much on the point that I "wanted to reduce the cost of manual testing." However, I was made to realize through personal experience that "simply introducing a tool will not achieve that objective."

The most important thing in automation is not just calculating ROI (Return on Investment) first, but first building a "structure where automated testing can be executed stably and repeatedly." I believe this is the most essential first step.

Once that structure is established, tests will run stably, and cost reduction will definitely follow later as a "byproduct." Therefore, I recommend first firmly setting the axis of your objective and starting by involving development engineers to incorporate testing into the development cycle.

Tools that do not fit well will eventually stop being used. It is truly a waste if a convenient tool is introduced but ends up unused.

Kurashige: I have almost the same opinion. Quality assurance is indispensable to manufacturing, and the goal is "to maintain high quality." I think MagicPod is the perfect tool for that. Since I often develop on the front lines, I engage with the mindset of "changing the development process itself for the sake of quality assurance." If you "just put it in" or "just automated it," it won't last after all. I believe it is highly effective for teams that have the resolve to change their entire operation. I definitely recommend it.

---

RecoChoku Co., Ltd.

• Corporate Site: https://recochoku.jp/corporate/
• RecoChoku Engineer Blog: https://techblog.recochoku.jp/

RecoChoku develops music-related services by leveraging the latest IT technologies. This development blog shares knowledge gained from their daily activities.

• Recruitment Information: https://recruit.recochoku.jp/

RecoChoku is recruiting colleagues to work with. If you are interested, please visit their recruitment page!

---