Don't Just Crush Bugs, Prevent Them: Quality Improvement Initiatives

Introduction

Nice to meet you! I am yama from the Quality Assurance Group.
I joined KINTO Technologies in May 2023.
I mainly do QA work for KINTO Unlimited .

About Today's Theme

Today, I will talk about the quality improvement initiative that I have been working on since I joined the company.

The Quality Assurance Group and Its Future Prospects

The figure above shows the future prospects of the Quality Assurance Group as given by our manager zume during a company announcement.
It shows that QA was formed three years ago and the team is now stable, so what will we do next?
I joined the company around that time.
At the system development company where I previously worked, I worked in QA with the goal of contributing to quality improvement by providing high-quality tests, but as I gained experience, I encountered the difficulty of ensuring quality through testing.
There is a limit to what you can do by just fixing bugs. You have to make sure that there are no bugs in the first place.
I wanted to work somewhere I could do this, so I joined KINTO Technologies.

Understanding the Current Situation

After I joined the company, I first tried to understand the in-house development and QA processes and the current state of the project I was in charge of (KINTO Unlimited ).
I found out that waiting time in development was costly (My previous job also demanded speed, but not as much as KINTO Technologies). That was because KINTO and KINTO Technologies are businesses that create new services, and delays lead to lost business opportunities. It made sense.
Therefore, when taking measures to improve quality, I felt that it was necessary to do something that did not slow down development. Also, I knew from my previous job that the manager could not handle everything for long, so I decided to do things as simply as possible.
However, I realized that the current project lacked an objective indicator of current quality. If you can't see the quality of the products you’re making, you can't see what you need to improve so you don't make bugs, so we first made a system that would visually indicate quality.

What We Did

However, even though we went, "Let's do ___ to improve our quality!" it was hard to casually accept that.
So, we first conducted a quality analysis in a slightly more in-depth manner through the development project, and fed the analysis results back to the project.
At that time, the bug report did not have enough quality analysis items, so the QA team investigated the resolution history of each bug report, categorized them, and did a quality analysis.

Analysis Materials (Excerpt)

At the end of the project, we presented analysis results at a review session and said, "We can see the quality and current issues if we have these classification items in the bug report!" By narrowing down the classification items and simplifying the input methods, we also minimized the burden on the person in charge.



Newly Added Classification Items

Thankfully, this proposal was accepted, and we started using the bug report with the above quality classification items added.

What I Want To Do in the Future

Now that we have a starting point for quality improvement, we would like to give feedback regularly to the project of the information we get and consider quality issues that need to be solved together with development and QA. We also plan to continue these efforts to make the progress in quality (improvements) visible. We also aim to expand this trend horizontally to other projects and hope it will be widespread.
We will continue with the belief that it will lead to the Quality Assurance Group's future prospects and overall quality improvement, which I mentioned at the beginning.