How the "Test Automation Launch Support Plan" Enabled In-House Quality Assurance — The Secret to Cutting Testing Man-Hours by 50% and Achieving 24/7 Monitoring with Zero Programming Experience and a One-Person Team
4COLORS Co., Ltd.
We spoke with 4COLORS Co., Ltd. about what led them to choose MagicPod and how they have been using it since implementation. The interview was conducted by MagicPod CEO Nozomi Ito.
4COLORS Co., Ltd.
Under the brand message "Creating value that communicates," 4COLORS has spent 20 years since its founding as a pioneer in avatar video production, deeply committed to the act of "conveying" itself. The company provides PIP-Maker, a video production service that enables anyone to create videos easily — not just in terms of technical simplicity, but in a way that genuinely helps customers solve their challenges through the act of communication.
KEY POINTS
- Through the Launch Support Plan, users with no programming experience reached an independently operational level in approximately 3–4 months
- Testing man-hours reduced by approximately 50% (from 4 hours manually to approximately 2 hours), while coverage expanded
- A near-single-person QA setup achieved continuous video playback monitoring every 3 minutes, 24 hours a day, 365 days a year
- A clear division between development and QA enabled engineers to focus fully on feature development
- AI features streamlined bulk corrections during UI changes and made it easier to identify the root causes of errors
From left:
- Iori Kinoshita, Information Systems Team
- Toshio Fujiwara, Head of Development Department
- Nozomi Ito, MagicPod CEO
Iori: In my previous role, I spent about three years as a tester handling test execution and test design. I joined 4COLORS in April 2025, taking over QA responsibilities from my predecessor during a migration from the old system to a new one. Since MagicPod's implementation happened to be decided right around that time, I ended up taking on test automation responsibilities in addition to my regular testing work.
Our PIP-Maker service allows users to create avatar and voiceover videos in as little as five minutes simply by uploading a PowerPoint file. It makes video production — which previously required significant cost — accessible to anyone, quickly and affordably, for use cases like e-learning, product introductions, and manual creation.
I handle quality assurance for PIP-Maker, covering everything from validating new features to checking for display issues caused by OS and browser updates, and verifying video playback stability. The Information Systems Team has three members in total, but I am the only one responsible for quality control on PIP-Maker. I essentially cover all verification work on my own, and currently run automated tests in MagicPod every day.
Toshio: I joined the company in 2019 and currently serve as Head of the Development Department, overseeing team management and acting as PM for PIP-Maker. The Development Department has five members on the books, but the total number of people involved in PIP-Maker development and product work on a project basis is around ten.
We originally handled all testing manually, and introduced MagicPod with the goal of automating quality control. Last year in particular, we were in the middle of migrating from the old system to the new one, and we used that as an opportunity to shift to a more efficient testing approach — conducting manual testing for new features and other verification, while automating daily monitoring and regression testing.
Why We Chose MagicPod
Nozomi: Before the QA function was established within the Information Systems Team, how were you handling quality control?
Toshio: At the time, members of our internal support team were doing a minimum level of external monitoring — manually checking every morning to confirm the service hadn't gone down. There was already a general sense internally that we should automate as much as possible, but the core challenge was: how do we reduce testing man-hours while still maintaining quality?
PIP-Maker converts slides into video by nature, which means there's a large volume of visual verification items — not just UI button operations, but things like "is the video rendering correctly?" and "are the avatars and text positioned without layout issues?" We had been manually playing back each video one by one to verify, but checking every combination of OS and browser was approaching its limits. The risk of human error and the growing testing man-hours for regression testing had become significant challenges.
In principle, the development team recognized that we should have been building and running our own E2E testing infrastructure, but the reality was that we simply couldn't allocate the man-hours. Seeing this situation, my predecessor started looking for an automation tool around 2024.
Nozomi: Before you introduced MagicPod, were there cases where defects caused by missed checks actually surfaced?
Iori: Based on what I heard from my predecessor, there were apparently a few close calls. For example, I was told there were several cases in the past where a function stopped working as expected after a release, and it was caught internally before customers noticed. The manual verification scope had limits, and there were always gaps in what could be checked.
From those experiences, the push for automation began — the goal being to move away from "we happened to catch it internally" toward "we want to monitor consistently and at a high level of accuracy every day."
When evaluating options, it sounds like they compared various no-code tools from Japan and overseas, as well as Selenium. In that process, they found MagicPod, tried it out, and concluded it was the best option — so they moved forward with adoption. Since the handover to me happened right after the selection was finalized, I was already involved from the trial stage before the official implementation.
Toshio: The deciding factors in choosing MagicPod were the low barrier to entry and the cost performance.
With no time available for development engineers to write test code, MagicPod allows tests to be created and executed intuitively with no-code, meaning operations could begin immediately with almost no learning cost. Another appeal was its flexibility to handle the kinds of specialized tests unique to our company — not just screen button operations, but tests that reproduce user viewing behavior to verify whether viewing logs are being accumulated correctly.
Given the nature of our product, the highest-impact issue for users would be "not being able to watch a video," followed by "not being able to edit a video." These two are overwhelmingly the most critical areas, so the core functions — "can videos be watched without issues?" and "can videos be edited reliably?" — are what we currently have automated and running.
Using the Test Automation Launch Support Plan
Nozomi: You used the Launch Support Plan when implementing MagicPod — how was that experience?
Iori: At the time, I was in the middle of the handover from my predecessor and had a heavy workload, so I felt that learning a new tool entirely on my own would be a significant burden and decided to ask for support. I had already started building tests before the plan began, but having the practical, applied know-how explained to me in detail through the support plan allowed me to smoothly transition into a daily automated test operation.
We started with foundational concepts — what is XML, what is XPath — and then moved into a hands-on format where I could get direct guidance on parts I had built but couldn't get working. I could also request topics ahead of the next session, such as "I'd like to learn more about this feature," which meant the time was structured around two axes: resolving things I didn't understand, and picking up new capabilities. It was a very effective use of time.
Without the support plan, I think I would have spent an enormous amount of time trying to understand the specs and troubleshoot on my own. Having the underlying logic explained in detail meant I understood how tests actually work at a fundamental level — and from there I could think, "if this works this way, then I should be able to apply it like this next." Even for simple tests I can now build on my own, the deep understanding I gained through this plan has been the foundation when I need to build something more precisely to my specific requirements.
Nozomi: When did you feel genuinely confident that you could run tests on your own?
Iori: The support plan wrapped up after about 15 hours over 3–4 months, and by that point I had a solid grasp of how to apply things. When someone internally said "I'd like to try this kind of test," I was at a level where I could immediately think of a specific approach — "I could combine those features in that way to build it."
At first, honestly, 15 hours felt like a long time. But as my understanding grew, the questions I wanted to ask kept multiplying. We progressed through a very clean cycle: building foundational understanding in the early sessions, clearing up day-to-day questions in the middle, and resolving more advanced topics toward the end. In hindsight, 15 hours was exactly the right length.
Nozomi: From the development side, how did you perceive Iori's skill development and the sense of "having let go"?
Toshio: She has been operating independently at a level that far exceeded our expectations. She has built tests that genuinely surprised me — I hadn't anticipated such a sophisticated automation setup initially, and I found myself thinking, "MagicPod can really do this much." The work has fully left our hands on the development side, and we can confidently rely on her for high-quality verification. I really believe we made the right call in using the support plan.
How MagicPod Is Being Used
Iori: We have automated everything for PIP-Maker, from operations on the video editing screen through to preview playback of the generated video. When a specific slide is converted into video, the system automatically checks whether avatars and graphics are positioned and displayed as expected. In the production environment, we run basic operation tests including peripheral features every day for early defect detection, and in the development environment we run broader, scheduled tests on a weekly basis. We currently operate a total of 32 test cases.
In terms of specific execution timing, we run a full feature check in Chrome twice daily — once around 8:00 AM before the workday begins, and once before end of day. We also have the same tests running in Edge and Firefox during late-night hours. Separately from those, we run a one-hour self-contained test every hour around the clock that monitors video playback every 3 minutes, providing continuous 24/7 coverage.
Nozomi: Is the every-3-minute test running stably?
Iori: It took some effort at the start, but after iterating on the setup it now runs very reliably. When a video playback issue occurs, it's detected immediately, and the notification is sent to a company-wide channel so the relevant person can be contacted right away when needed.
Nozomi: That's an impressive operation. Overall, how far along would you say the automation of your testing is at this point?
Iori: For the core areas we want checked automatically every day, we've reached a state that's close to 100%. That said, the product's features are continuously being updated, so there's no true "100% done." As I've been with the company longer and my understanding of the product deepens, new ideas for tests keep emerging — "we should probably have a test for this too." So I'd put overall progress at around 70% at this point.
Toshio: The significance of being able to verify — through MagicPod — whether users can actually watch videos properly is enormous. Since MagicPod itself is stable, I'm currently comfortable leaving baseline monitoring in Iori's hands.
Nozomi: You're running scheduled tests across multiple time slots and browsers — so you're also monitoring the impact of browser updates?
Toshio: Exactly. Chrome in particular has frequent unexpected specification changes, and in the past there were incidents where a spec change caused videos to become unwatchable. By running scheduled tests regularly in the development environment as well, our ability to detect issues during browser updates has improved dramatically. Beyond the obvious quality benefit, the psychological peace of mind — "we can prevent playback issues before they happen" — has taken hold across the team, and being able to catch regressions early during development has been a major outcome as well.
Iori: There's also been a significant impact in terms of reducing testing man-hours. We have releases almost every week, and previously regression testing done manually would take about 4 hours. With automation, it now takes around 2 hours.
Beyond that, while MagicPod is running, I can now perform more detailed manual testing in parallel. Running manual and automated testing simultaneously has allowed us to cut the actual time commitment in half while substantially expanding test coverage.
Nozomi: It sounds like you've found a very effective rhythm of balancing daily automated tests with manual verification. I also heard you're running quite advanced test operations using data patterns and variables — can you walk us through that?
Iori: We actually use MagicPod not just for screen testing, but as a tool for accumulating viewing data.
PIP-Maker is built to collect data in the background on who watched a video, when, and how far they got. Customers who use it for internal training, for example, use that data to check whether attendees understood the content through quizzes, or to follow up with people who haven't completed the training yet.
For that reason, we need to internally verify the report feature — specifically, how the system performs when customers generate large-scale viewing reports from the admin dashboard. Originally, preparing the necessary data required manually playing back videos many times to accumulate the required number of records, and there were limits to how much data could be realistically prepared this way. Solving this — building a mechanism to automatically pre-accumulate logs — was something I wanted to achieve from the very beginning of the implementation.
So now, every day MagicPod automatically accesses videos and uses carefully combined data patterns and variables to generate realistic viewing logs. For example: if a user ID ends in 2 or 5, the behavior is set to "exit the video partway through." For in-video quizzes and surveys, the answer selection depends on the viewing time at that moment — even-numbered minutes select Option A, odd-numbered minutes select Option B. Through these conditional branches, a single test case can efficiently collect varied, natural-looking viewing data in the backend — without it being uniform or artificial.
This initiative started with gradual experimentation around August 2025, and by around autumn I was able to combine data patterns and variables freely and operate the system confidently. Being able to ask specific questions during the Launch Support Plan sessions — on topics like "how to embed variables within data patterns" — was what made it possible to turn the idea into reality. That led to a deeper understanding of how to build far more diverse patterns.
Nozomi: Are you also using the AI features?
Iori: Yes — I use MagicPod Autopilot when it's time to update test cases. Recently there was a fairly large UI change, and for that I manually corrected the first instance myself, then instructed Autopilot to "rewrite all elements like this one in the same way," and it handled the bulk update. I expect the range of uses to expand even further as we accumulate more operational know-how.
I've also been finding the AI failure analysis feature very useful lately. When a test fails due to an unexpected alert screen or similar issue, it can be difficult to trace the technical root cause all the way down to the code level on my own — but I can't report a defect to the development team with an unclear cause. With the failure analysis AI, it explains things clearly — "this failure occurred because an alert with this content was displayed" — which has made defect reporting to the development side much smoother. I've genuinely felt the power of AI not just in fixing things, but in making the reporting process more efficient as well.
Closing
Iori: Right now we're focused primarily on regression testing by feature, with verification across a variety of data patterns. Going forward, I'd like to build out "user scenario tests" that trace the full flow from initial account registration — tests that simulate real customer behavior end to end. Until now I've focused heavily on individual feature verification, so I want to shift toward more scenario-based tests and continue raising the quality bar.
For non-engineers taking on test creation, there will likely be moments early on where things don't work as expected or the root cause isn't clear. But MagicPod offers a very thorough and thoughtful support structure, and the Launch Support Plan covers everything from basics to advanced application. Going in with the mindset of "let's try building it ourselves first, and actively ask questions when we hit a wall" means even someone with no programming experience can move forward with test automation confidently. The ability to reach out for support easily and with a low psychological barrier — right from within the interface — is another thing I'd highlight.
Toshio: On the development side, we're looking to strengthen CI/CD integration. Since our current operations are primarily centered on the production environment, we want to move toward running automated tests earlier in the verification environment so that the development team can take ownership of defect detection.
For companies where development engineers don't have the bandwidth to write test code, MagicPod delivers significant cost-effectiveness — covering this much test coverage at this price point. The solid sense of reassurance it creates within the team — "as long as we're running these regression tests, we have a reasonable level of quality covered" — is a major mental benefit that genuinely helps accelerate development.
4COLORS Co., Ltd.
- Product site：https://www.pip-maker.com/
- Corporate site：https://www.4colors.jp/
