Nozomi Ito is the Founder and CEO of MagicPod, a No-code end-to-end software testing startup.
However, he didn't set out to become a tester.
Before founding MagicPod, Nozomi worked at a startup where poor testing led to broken features, unsatisfied users, and stressed-out developers. This led him to build an internal tool that was adopted company-wide, earned him the CEO award and led to his current role.
In this interview, we asked him five questions about software testing practices, what it takes to be a great tester, and the future of software testing in the AI Era.
Here’s what we covered:
Let’s dive in.
I didn’t start out interested in software testing. But about a year into my role at a startup, I realized the biggest bottleneck in the company’s development process was testing.
Due to insufficient testing time, the quality of the applications was poor. Bugs made it to production, complaints would follow, and developers had to abandon new features to fix issues.
This created a bad cycle, even with hundreds of QAs and developers, once product quality was already poor, they couldn't fix it. QA could report bugs, but there were too many, and fixing one often broke something else.
Manual testing alone wasn’t enough to break this cycle. I realized we needed test automation to catch bugs earlier, before they reached QA or users.
At the time, there were no good tools for testing our system, so I built a recording and playbook tool that both our developers and QA could use.
Initially, the reaction was quite negative. The tool’s quality wasn’t good, and people were too busy with manual testing to try something new, so it was hard to convince them. But after a couple of years, with consistent promotion and improvements, up to 300 people were using it. After three years, I received the CEO Award. Only three people out of 3,000 got that! That was how my journey into software testing began.
One mistake is automating tests even when release cycles are long. If you only release software once every three or six months, automation often doesn’t pay off. But if you ship weekly or monthly, automation makes sense.
At that startup, our release cycle was about three months. Today, in hindsight, I might suggest more unit or API testing instead of just UI automation. My approach back then wasn't perfect, but it helped a lot of QAs understand the importance of automation.
Unit Testing – Historically, QAs haven’t written unit tests, but in the future, they’ll need to. Learning how to read or write code will become more important.
API Testing – These are critical for efficient and robust backend testing.
End-to-End Testing – This has become much easier thanks to no-code platforms. Many companies attempt to use code-based tools but often give up due to time constraints and difficulties in sharing. No-code solutions like MagicPod support team collaboration and are easier for non-developers to use.
Developer Skills - QAs should learn developer-like thinking: loops, conditions, and variables. Not every QA has a technical background, but that mindset makes you more valuable.
A critical mindset. Good testers don’t just accept what they see, they doubt it. They ask, “Is this really correct?” That instinct to question things helps them catch issues others miss.
Curiosity also matters. Great testers like to try different behaviors and think about edge cases. We could assess this through interviews involving real-world tasks, such as restoring a sample app or testing a broken one.
More AI.
Developers are shifting to AI-supported development, and the same is true for testing. Although manual testing is still dominant in many companies, AI will change that, and repetitive work will be automated.
Testers who continually learn and develop key skills, such as automation, exploratory testing, understanding the customer’s perspective, and test design, will remain relevant. These are human tasks that AI can’t easily replace.
To create meaningful test cases, QAs would need to understand the why behind the product, not just what it does. That includes the user, the use case, and the context, which is why sometimes, product managers make great QAs because they see the full picture.
And as AI takes over routine work, the boundaries between roles would blur. Developers might need to do testing. QAs might need to write code. PMs might think more like engineers.
Someday, AI may be able do almost everything. But that day’s still far.
Until then, we keep adapting.
Key Takeaways:
Thank you, Nozomi, for sharing your journey from frustrated developer to successful testing entrepreneur and your insights on the future of software testing. You can connect with Nozomi on LinkedIn to continue the conversation.
For more insightful interviews with software testing professionals, make sure to subscribe to TestingPod and get it delivered to your inbox every week.