Why did a QA veteran with 10 years of experience in the gaming industry dive into the unfamiliar world of AI and edutech? Ryan from LUXROBO's P&O division chose the "path of growth"—building systems and setting quality standards himself, rather than staying in a perfectly established, massive system. From designing an efficient issue management system from scratch to creating healthy synergy with related departments in a complex product environment encompassing both hardware and software.

Discover Ryan's definition of true QA and his know-how for uncompromising quality management.

Read Ryan's interview if you are:

✅ A junior or mid-level QA professional experiencing growing pains.
✅ A practitioner facing a career move or challenge in a new domain.
✅ A member of a startup-sized organization needing initial system setup.

Part 1. A gaming industry veteran's introduction to AI

Please briefly introduce yourself and the main tasks and roles of the current QA team.

Ryan, QA Leader, MODI Factory

Hello. I am Ryan, in charge of QA at LUXROBO's P&O division.

I am currently responsible for overall QA for SW/HW products across various projects, including MODI Factory, which is currently serviced by LUXROBO, the all-in-one educational service MODI, AIoT services applied to residential spaces, and an integrated parking system.

My main tasks include analyzing requirements for each project, planning and designing tests, verifying functions, managing issues, and reviewing quality risks before deployment. Furthermore, I establish QA processes and operational standards so that consistent quality standards can be applied to each project, and I carry out quality management tasks to provide stable products and services in collaboration with relevant departments.

You have built a solid foundation in QA over a long period of about 10 years in the gaming industry. What was your special motivation or expectation for joining LUXROBO, an edutech and AI-focused company?

Although I worked in the gaming industry for about 10 years, the work I experienced was not actually limited to game QA. Due to the nature of the team I belonged to, I was in charge of various fields of work, including game-related HW/SW QC, web QA, PC cafe management program QA, and esports-related work. Especially during the 5 years, which accounts for half of my 10-year career, experiencing these tasks allowed me to encounter various products and services without being confined to a single domain.

Meanwhile, I learned about LUXROBO, which develops businesses centered on AI, AIoT, and edutech fields, and I thought it would be an opportunity to experience new technologies and domains while utilizing the various QA experiences I had accumulated so far. Of course, games, AI, AIoT, and edutech have different product characteristics and usage environments, but I thought the fundamental purpose of QA—providing stable products and services to users—would not be significantly different.

I wanted to see for myself if I could utilize the experience I had built up in a new environment, and at the same time, I applied to LUXROBO with the expectation that I could further broaden my capabilities as a QA professional by experiencing unfamiliar technologies and products.

Part 2. Achieving uncompromising quality

What was LUXROBO's QA environment like when you joined? The process of introducing new test standards and a systematic process must not have been easy.

Even when I joined, QA work was being carried out according to LUXROBO's internal processes.

However, QA policies, processes, issue management methods, and operational standards for each project were scattered in several places, making it difficult to grasp the overall operational system. Above all, there was no space set up where these standards could be checked and referenced in one place.

Therefore, the first task I proceeded with after joining was establishing QA processes and operational standards that could be commonly utilized across LUXROBO's various projects.

I reviewed the existing operational processes and policies and carried out the task of organizing the scattered or differently applied standards into a single system. What I considered important in this process was not simply creating new standards, but understanding the existing work methods as much as possible and providing a process that could be seamlessly utilized in actual projects.

For about a month, I reconstructed the QA process and re-established operational standards, and then presented and shared the details with members of relevant departments for the MODI Factory project.

To this day, we are conducting work based on the established QA process and operational standards. I believe that a QA process should not simply exist as a document, but should be a standard that anyone can understand and utilize in actual work. I think this experience was also a process for preparing such an environment.

You built the process yourself and ported it to the current system. After this process was established, what positive changes were there in collaboration with relevant departments or actual work efficiency?

Since I am currently in charge of QA work for multiple platforms and projects, situations sometimes arise where it is difficult to perform QA directly due to overlapping test schedules for each project or business trips.

Previously, if the person in charge changed in such a situation, separate explanations or handovers might have been necessary to continue the work, but after establishing the QA processes and operational standards, I prepared an environment that could reduce this dependency.

If the test environment and necessary information are ready, I structured it so that even if I don't perform it myself, another person in charge can continue the QA work based on the set process and test cases. To achieve this, I prepared an issue report writing guide and a test case template, and I also regularly update the QA process and operational policies.

Also, by structuring it so that related content can be checked in one place, relevant departments can refer to the document without separate inquiries when they need to check the QA progress method or issue management standards. These changes are meaningful in that they provided an environment where collaboration is possible based on common standards without depending on the experience or memory of a specific person in charge, rather than simply documenting the work.

I heard that you built a bug tracking system (BTS) yourself to effectively manage issues across multiple projects. I'm curious about the background of planning this system and its actual utilization results.

At that time, there was no environment established to systematically manage and track issues that occurred per project. As a result, issue histories and unresolved issues were scattered in several places, making it difficult to grasp problems that occurred in the past or the status of issues currently remaining.

To solve this problem, I wanted to build an issue management environment based on my operational experience with Jira and Confluence that I had used previously. However, introducing a separate BTS would require not only additional costs but also resources to adapt to and operate a new tool, so I reviewed a plan to utilize Notion, which the company was already using. By utilizing Notion's database feature, I judged it would be possible to register issues, assign personnel, change statuses, and manage modification progress and history in a manner similar to Jira.

Accordingly, I directly designed and built an issue report board based on the Notion database.

Afterward, going beyond simple issue management, I configured Notion pages for each project to expand the operational environment so that everything from the project's start phase to QA progress status, issue management, and final completion phase could be checked on a single page.

As a result, I prepared an environment where previously scattered issues could be managed in one place, and the person in charge, progress status, and change history for each issue could be continuously tracked. Also, by utilizing the existing collaboration tool without introducing a separate BTS, I was able to reduce the burden of introducing and learning additional tools.

I think this experience is meaningful in that it did not simply build an issue management tool, but identified inefficiencies occurring in existing QA work and directly prepared improvement measures within the given environment and resources.

When dealing with complex products where hardware and software intertwine, you must sometimes encounter issues not found in simulations. If there is a dizzying moment or a dramatically resolved issue that you remember most while conducting tests at LUXROBO, please share one.

Actually, I still frequently encounter these aspects while conducting QA. There is a difference I feel every time I test a product where hardware and software work together, rather than a software-centric product. In the case of software, the process of reproducing a problem in a development environment, analyzing the cause, fixing it, and then verifying it again can be carried out relatively flexibly.

However, the situation is slightly different for products where hardware is interlinked. While it is important whether the software and hardware are interlinked normally and whether each function operates as intended, it is also necessary to consider the possibility that the cause of the problem might be a defect in the hardware itself, not the software.

If it is a problem that can be solved by modifying the firmware, I can receive the modified version and proceed with re-verification, but if there is a defect in the hardware itself, situations can arise where parts must be replaced or new equipment must be provided through a partner company. In such cases, the fact that not only QA but also the development schedule and the partner company's response schedule could be affected felt quite different from the software-centric QA I had previously experienced.

A particularly impressive part was that a problem found during the QA process does not end with a simple function modification, but can lead to a problem requiring hardware replacement or a response from an external partner company. Experiencing this, I felt that I shouldn't only consider a normal verification period when establishing a test plan. I learned that it is important to calculate the schedule by considering the possibility of unexpected situations such as equipment replacement due to hardware defects, partner company responses, and re-verification, and to identify risks in advance.

Ultimately, I felt that in the QA of integrated HW/SW products, not only the capability to verify functions, but also the ability to consider the necessary response process and the impact on the schedule when a problem occurs is important.

QA is a position that delivers feedback to the development team for quality and sometimes has to coordinate opinions between schedule and quality. I'm curious about your unique communication know-how to maintain the uncompromising standard of "quality" while creating a healthy synergy with the development organization.

Since it is an outcome created by colleagues putting in a lot of time and effort, I try not to judge or deliver the discovered issues lightly.

First, I check if the problem is reproduced based on the environment prepared in the test planning stage, and I analyze the location and situation where the issue occurred to verify the conditions and process required for reproduction.

Afterwards, I write an issue report, and there are a few principles I consider important in this process.

The first is that other people should be able to grasp what the problem is just by looking at the title.
The second is to always attach a video or image where the moment the problem occurs can be checked.
The third is to write the reproduction steps concisely, preferably within 5 steps.

I believe anyone finds it easier to understand concise and clear information rather than long and complex explanations. Of course, exceptions are necessary for complex issues, but I try to reduce unnecessary explanations as much as possible and deliver only core information. I think just keeping these principles can reduce the content developers need to additionally check to understand and reproduce the issue, and it helps prevent repeating unnecessary communication with each other.

Also, when opinions on an issue differ, rather than simply asserting that QA's judgment is right, I try to explain based on objective evidence under what conditions the problem occurs and what impact it can have on users and services. Ultimately, good communication as I see it is not simply persuading the other party, but helping each other understand the problem based on the same information and make a rational judgment.

Part 3. "True QA" defined by a generalist without limits

From a QA perspective, when comparing the past game domain and the current MODI Factory, what is the biggest difference you experience, or conversely, the point where you feel they are "essentially the same"?

At first, I thought there would be many differences in the way QA is conducted because games and MODI Factory are different domains.

However, while actually conducting QA work for various projects including MODI Factory, I felt that although there are differences in the characteristics of the platforms and products, the fundamental purpose of QA—providing stable services to users—is the same.

Of course, there is a difference in that gameplay flow and user experience are important in games, whereas in MODI Factory, not only the operation of core functions but also the accuracy and stability of work results are important. However, the basic QA process of analyzing requirements, predicting possible risks, and designing and verifying tests based on this was not significantly different.

In fact, I was able to apply the QA experience and processes I had built up in previous game projects to MODI Factory, and I was able to perform QA work while adjusting the verification scope and priorities according to product characteristics. Through this experience, I further solidified my thought that what's important in QA is not just experience with a specific platform, but the ability to understand the product, judge quality risks, and design appropriate verification methods.

What do you think is the core competency of a "skilled QA"?

II believe that QA plays a role like a goalkeeper guarding the goalpost from quality risks that could occur before deployment. To perform this role, above all, a high level of understanding of the project and product one is in charge of is required.

Beyond simply checking if it operates according to the requirements, one must be able to judge from the user's perspective what problems could arise and what impact those problems could have on the product and service.

Also, rather than always assuming only the best-case scenario, I think one must be able to predict various possible exception scenarios and risks in advance, and judge what should be verified first within limited time and resources.

Ultimately, the core competency of a skilled QA that I think of is the ability to predict risks based on an understanding of the product and contribute to securing quality through rational judgment. I am also constantly contemplating how to acquire these competencies, and rather than evaluating myself as a skilled QA, I want to be a QA who strives for better quality while silently fulfilling my assigned roles and responsibilities.

Recently, test automation and the utilization of AI tools have emerged as important topics in the QA profession as well. Are there any test automation technologies or trends you would like to introduce to the organization in the future or are currently keeping an eye on?

Test automation is actually an area that has been a constant topic in the QA industry even before the emergence of AI. In the past, there were cases of building and operating test automation environments utilizing Python or Selenium, but utilizing them required an understanding of programming and separate learning.

Also, even after building an automation environment, there was the difficulty that quite a few resources were consumed for code modification and maintenance due to changes in the test environment or product updates. Because of this, automation wasn't unconditionally efficient, and I thought it was realistic to utilize it mainly centered on tasks that have a lot of repetitive execution or where the verification procedures are relatively clear and stable.

However, with the recent development of AI tools, I feel that many changes have occurred in this environment as well. Previously, parts that had to be written and modified as code directly can now be implemented with the help of AI, and I think an environment has been provided where one can attempt and utilize test automation even if their understanding of programming is not high.

I am also trying out test automation tools that I had been interested in, such as Maestro, Appium, and Playwright, together with AI. In particular, I am experiencing that the burden required to implement automation has decreased compared to before during the process of generating or modifying test scripts through AI and analyzing the causes of errors.

Of course, just because it is code written by AI does not mean it can be trusted unconditionally. I believe QA must directly check whether the test operates according to the intended verification purpose and whether it actually judges the correct result. Going forward, rather than automating all tests, I want to apply it in stages starting from areas where there is a lot of repetitive execution and where practical efficiency can be gained through automation.

Ultimately, the part I am paying the most attention to is not a specific automation tool itself, but the fact that it has become possible to more realistically utilize test automation, which was previously difficult to attempt due to time and technical constraints, by utilizing AI.

Finally, if you have any advice you'd like to convey to junior QA professionals who are striving to establish quality standards, please share it.

Ryan, QA Leader, MODI Factory

Since I also still have a lot to learn and am in a position of contemplating how to become a better QA, I am cautious about giving advice to anyone. However, if there is a point I have felt while experiencing various projects so far, it is that a QA professional should not simply be a person who finds many issues, but a person who can judge what the problem is and explain why that problem is important.

To do so, effort is required to fully understand the product and service one is in charge of. Beyond merely checking the contents specified in the requirements, I think one must constantly consider what problems could occur from the user's perspective and what impact those problems could have on the actual service.

Also, I don't think simply following the established processes or standards exactly is the only right answer. Since the environment and resources are different for each project, one needs to make judgments that fit the situation, and if there are lacking standards, an attitude of directly creating or improving them is also necessary. Of course, the judgments one makes cannot always be right. Therefore, I think it is important to leave grounds for judgments, accept other people's opinions, and continuously supplement one's own standards through experience.

Rather than trying to be a perfect QA from the beginning, I hope you understand the purpose and reason of the tests you perform and have a sense of responsibility even for a single small judgment. I believe that as such experiences accumulate, your own quality standards and philosophy on QA will naturally be formed.

🖊 Editor's Note

What left the deepest impression throughout the interview was the "solid essence" of how Ryan treats his profession. The secret to his ability to establish quality standards without wavering, even while crossing domains from games to AI and edutech, lied in his deep sense of responsibility, defining himself not as a simple tester but as a "goalkeeper guarding the goalpost for the users."

In particular, beyond simply conveying the issues that occurred, the way he reduced communication costs with other departments through the clear principle of "writing concisely within 5 steps if possible" and helped make rational judgments with objective evidence revealed his deep respect for his colleagues and the product.

Ryan, who does not settle for the familiar experiences of the past, actively designs work standards, and constantly explores the trend of AI-based test automation. We hope that the story of his proactive expansion of his own QA philosophy without drawing boundaries on his job will serve as a deep resonance and an excellent guide for all practitioners who wish to take another leap forward.

👉 Start using MODI Factory for free today