MagicPod CEO Nozomi Ito interviewed UPSIDER Inc. regarding the key factors behind their selection of MagicPod and their utilization from introduction to the present.

---

UPSIDER Inc.

With the mission of “Building a global financial platform to empower challengers,” UPSIDER Inc. develops and provides various services, including the corporate card “UPSIDER,” the invoice card payment service “Shiharai.com,” the AI chat-based business tool “UPSIDER Coworker,” and the debt fund “UPSIDER BLUE DREAM Fund” specializing in growth-stage startups.

---

---

---

---

From left:
・Kitazawa
・Eri

---

Eri: I'm Eri, responsible for promoting automated regression testing. I joined UPSIDER in June 2024 as a QA engineer. I began my career as a software engineer at an SIer, worked on CG and medical device development, then gained experience in the semiconductor industry before returning to the IT sector as a QA engineer.

Kitazawa: I mainly handle automated regression testing after incidents occur. Specifically, I support Eri by creating test cases using MagicPod and automating tests for features related to past incidents. I've been in QA for about eight years and have been involved in test automation for the past two. I also used MagicPod in my previous job.

Naoki: I'm Naoki, the QA team manager. My career started at an SES testing company before I became a freelance QA engineer. Since then, I've worked in FinTech companies and e-commerce sites. I joined UPSIDER as a contractor in October 2023 and became a full-time employee in February 2024.

Ito (MagicPod CEO): You all have extensive experience as QA engineers. What is the current structure of your QA team?

Eri: Currently, our team consists of six full-time employees (including the manager), three part-time staff, and two contractors. The QA team belongs to the common foundation organization within the development department, but each QA member works closely with a product development scrum team and gets involved from the early stages of development.

Our development teams follow an agile methodology with two-week sprints, and releases are aligned with that cycle. QA is involved from the upstream processes such as refinement and planning, where we confirm and adjust specifications in preparation for releases.

Kitazawa: We also conduct retrospectives with the development teams. For example, The main product team holds a one-hour review session on Thursdays after each release, with both development and QA participating.

Ito: So you closely collaborate with the development team on QA activities.

Eri: Being involved from the early stages of development helps us catch ambiguities in the specifications or overlooked considerations. As a result, we gain deeper insights into the test cases. This enables the entire development team to discuss questions like, “Should we really test this thoroughly?” or “Is this test unnecessary?”—leading to more efficient and effective testing overall.

Naoki: Thankfully, the entire development team shares a strong awareness of quality, which also raises expectations for the QA team. We've established a system where any member can stop a release if they sense something might be wrong.

---

The Process and Key Factors Behind MagicPod’s Adoption

Kitazawa: Prior to adopting MagicPod, regression testing was not conducted on a regular basis, and we often addressed issues only after incidents occurred. Moreover, there was no well-established system for thoroughly verifying the behavior of existing features before a release, which resulted in psychological unease around deployments. In fact, another automated testing tool had been introduced before MagicPod, but it was not maintained and eventually became obsolete.

Amid these circumstances, discussions began around the need to implement proper regression testing, particularly before releases. This initiative involved not only the QA team but also members of the development team, who worked together to actively create regression test cases.

Ito: What caused the previous automated testing tool to become ineffective?

Naoki: It was the result of several overlapping factors. As the organization evolved, the structure of the QA team was reviewed and adjusted, which led to periods when the automated testing system wasn’t fully utilized. When I joined, the tool was still in place, but since it operated on a pay-per-execution model, it was rarely used.

Kitazawa: At the core, I think there was still a lack of strong awareness around quality within both the development and QA teams. But since we provide a payment service, any malfunction can have a serious impact on our customers.

For instance, UPSIDER offers a feature to set daily spending limits. If a transaction exceeding that limit were processed incorrectly, the customer could receive an unexpected charge—leading to a loss of trust. To ensure users can rely on our service, we pushed for automation to maintain high quality.

Our efforts around automation and regression testing began at roughly the same time. I focused on automating particularly critical features, such as card issuance, using MagicPod.

Ito: What were the main factors you considered when selecting a new automated testing tool?

Naoki: We did consider continuing with the previous tool, but since it used a pay-per-execution pricing model, we were concerned that costs would increase as the number of test cases grew. So, we paid close attention to the pricing model.

In the end, we chose MagicPod because it offers a fixed-cost plan and a GUI-based interface that makes it easy for anyone to use. The ability to run tests freely without worrying about execution costs was a major deciding factor. I had also used MagicPod in the past, which gave me additional confidence in the choice.

---

---

How UPSIDER Uses MagicPod

Kitazawa: When we first introduced MagicPod, we were under a very tight three-week deadline and had to work hard to create the necessary test cases. I had used MagicPod at my previous job, and thanks to its intuitive interface, we managed to meet the release schedule—something I believe would have been difficult with other tools. By rapidly iterating through trial and error, we were able to steadily improve both the speed and accuracy of our test case development.

Eri: Currently, we've automated 22 regression tests that were previously done manually. These run automatically every night at 2:30 AM. Test results are posted in a dedicated Slack channel for the QA team to review. We've been able to catch issues early—like data inconsistencies in the staging environment, problems with user spending limit settings, and input errors—allowing us to fix them before they affect customers. This has greatly improved both the speed and quality of feedback to the development team. While Kitazawa focuses on automating regression tests derived from past incidents, I support that work and also handle test automation for areas that are difficult to cover manually, such as email notification functionality and visual regression testing.

Ito: Which MagicPod features have been most useful?

Eri: The "Check for image differences" command has been especially helpful for verifying images after file uploads. It's convenient because we can set the tolerance for differences and specify the comparison area. This has been particularly useful for automating checks of uploaded images like receipts and invoices, significantly reducing the burden of manual visual inspections and greatly improving test efficiency. We also make good use of the email testing feature and the shared/common steps functionality.

Kitazawa: The development team has given positive feedback, saying that having automated tests constantly running gives them peace of mind, knowing that any unexpected bugs will be caught. With less need for manual checks by QA, the entire team feels a greater sense of psychological safety when releasing. Recently, there’s also been growing interest in using MagicPod for new products.

Ito: Thank you!

Eri: Moving forward, we plan to use MagicPod as our core tool while also leveraging Playwright for scenarios requiring detailed condition settings, aiming for a hybrid approach to maximize test coverage.

---

Final Thoughts

---

Eri: One of MagicPod’s greatest strengths is its robust support system—you can reach out when you're stuck and get a prompt response. In the user community, there are many shared examples of real-world use cases and creative solutions, which have helped us improve how we use common steps and manage test cases. Thanks to this knowledge-sharing, our test failure rate has dropped significantly, and our operations have become much more stable. We see MagicPod as a strong partner in continuing to improve our product quality.

Kitazawa: MagicPod’s intuitive UI makes it easy to get started with test automation, even without deep knowledge of its internal workings. Of course, there might be some confusion at first, but as you use it more, you naturally get used to it, and test creation becomes much faster. While test automation can feel like a heavy lift at the beginning, once it's up and running, it improves both quality and release speed. For companies on the fence, I recommend starting small—with just a few test cases—and gradually expanding through repeated use.

Naoki: The fact that MagicPod offers unlimited executions for a fixed price is a major advantage. Its GUI-based test creation also makes it easy for anyone to use. This is especially important when driving test automation not only within the QA team but also in collaboration with developers. At UPSIDER, we plan to continue leveraging MagicPod to promote test automation and deliver an even better customer experience.

---

UPSIDER Inc.

• UPSIDER Tech blog：https://tech.up-sider.com/archive
• UPSIDER Official note：https://note.com/upsider_inc/
• UPSIDER Career：https://career.up-sider.com/