Learn About the "Project Quality" that Our QA Engineers Create! Ten Facts about the QA Engineering Department

Have you heard of the "QA Engineering" field? Some of you may have heard the words QA or engineer, but don't really understand what they actually do. Our theme for this post is the QA Engineering Department and the QA engineers that support service growth from a project quality perspective.

New services and features go through several stages (such as planning, development, release, and operation) in order to reach the hands of users. This time we sat down with three members of the QA Engineering Department to ask them when they come into the process and what they do.

This time we sat down with...

Fact 1: "Preventative" work is the key to creating and maintaining healthy services (updated version)

 

Ueda: We create the "project quality" needed to make an appealing service that is safe and secure together with the other project members.

If you imagine a safe, secure, and appealing service as a healthy and attractive body, then the project is the body's parts and organs.

This is just how I imagine it because I don't actually have any expertise in the medical field, but let's say there's a body with too much fat on it. Examining the body and finding those kinds of issues are what the QA engineers in our department do.

From there, we look for the cause. If we know that it's due to a lack of exercise or a bad diet, we prescribe treatment like a fitness plan or diet. So as a result, the work we do is "preventative" so that healthy bodies don't get sick or stray from their ideal figure.

Ueda: As for where we get involved in projects...

First of all, the work we do is called "quality assurance work." In every project process (from planning to release and operation), this work is split up into three categories: Quality Management, Quality Assurance, and Quality Control (Testing). Among these, the QA Engineering Department primarily focuses on Quality Assurance (QA). 

 

Many people imagine that the work we do is testing a service to see if there are any bugs, but that's actually a part of Quality Control Testing (QC). QC treats "sicknesses" that are already there, so it's easy to think of it as "treatment."

Fact 2: The QA Engineering Department was born from a department that handled service testing work

Ueda: If we go back to the beginning, the start of the QA Engineering Department was in QC. LINE Fukuoka has handled service testing work since 2011, and it's currently the largest testing organization within the LINE Group.

Note: Please see here for information about the Test Center, which is in charge of Quality Control (Testing) at LINE Fukuoka. (Sorry, this post is only available in Japanese.)

LINE FukuokaでQuality Control（Test）を担うテストセンターについてはこちら

In terms of quality, QC is a product, so by improving the quality of the project that is creating that product, we believed that we could contribute more to our services, and expanded as QA engineers from within QC.

Then in 2020, the QA Engineering Department became an independent department. We split our departments to clarify our roles, but QC is a part of QA and they can't be thought of separately, so while our work is separate our departments are still strongly related. 

Fact 3: QA engineers play a role in almost all LINE-related services

─ How many services is the QA Engineering Department currently involved in?

Ueda: Right now we're working on projects in ten different fields, including the LINE platform, O2O, FinTech, and entertainment.

Nakagawa: There are departments that play a role in QA engineering at LINE Corporation in Tokyo and LINE Plus in Korea as well.

Fact 4: QA work has no defined shape; anything goes if it's quality-related

─ Please tell us about what you do here specifically.

Ikeda: Hmm...it's actually hard to say, "This is the work that QA engineers do." For service developers, you could say things like design or programming, but it's hard to clearly indicate the work that QA engineers do.

Within the LINE Group, there are a lot of services and a lot of projects to create those services. There are projects for services that haven't been released yet, and there are projects for services that were released several years ago. The issues they face, their priorities, and their circumstances are all different.

 

QA engineers work to solve issues within these projects. First, they identify the problems and issues that need to be solved in their project, then decide what to do and when to do it, and finally create an improvement plan based on what they're aiming for. That's the first step.

Next, they start working on the improvement plan within the project. Naturally, since each project has different issues and circumstances, the work that each engineer does is also different. That's what I meant when I said it's difficult to tell you what we do specifically.

The target for QA engineers is to achieve project quality that will create a service. We'll do anything if it's related to quality, and while what we all do is different, I think there are fundamentals that we all share.

─ Please give us an example of what a QA engineer does.

Ikeda: If we're working on ten projects, then our engineers will be doing ten different kinds of tasks. That's how varied the work we do is, so I'd like to give one example.

 

First, to give a general explanation of the development process, requirements are defined and then documented as specifications or designs, gradually becoming more detailed and concrete. Next, someone other than the creator reviews the documentation and revises it as necessary. This is repeated until the development is completed, and after that the building and testing processes begin. That's the general flow of development.

 

This is an example of one project. A lot of bugs arose during the testing process, and reworking the program and redoing testing required more time than we expected, so it seemed like we would have to re-think the release date. As we were unravelling the cause, we learned that the project went forward without a sufficient review of the design, so we worked to improve the overall review process.

Next, we presented the issues so that all of the project's members could be on the same page, and readjusted the timing and content of reviews as well as the reviewers. After that, we tried to raise the quality of the project as reviewers by establishing lines of communication through proactive questioning and making efforts to check or improve things from a quality perspective.

For the quality-related work that we do (including reviews like the one in the example I just gave), it's important to work on the project as a whole. That's why it's absolutely essential to foster overall awareness and work to build a proper environment.

As a basic premise, QA engineers need to have a thorough understanding of the service or business they're working on. I believe that the mission of QA engineers is to take a variety of service or business factors - such as speed - into consideration, then search for and put into practice better ways of doing quality-related work. 

Fact 5: QA engineers go out of their way to achieve overall project balance

─ In the sense of facing project issues, it seems like you're in a management position similar to a service planner or project leader, but are there any differences?

Nakagawa: I think the differences are our standpoint and perspective.

Service planners and project leaders each have their own clear mission in terms of what they need to do, so they can commit to putting everything into sales or service ideals. They need to drive the project forward, and sometimes they might take an approach that's too aggressive. That could lead them to neglect defense or sacrifice the security of their project.

I think the job of QA engineers is to achieve an overall balance so that projects can move forward as quickly as possible while maintaining just enough defense that the services won't collapse. Of course sales and service ideals are necessary, but the perspective of creating a better and more secure service through quality-related work is also important.

Ueda: I think what Mr. Nakagawa said about creating balance is absolutely correct. To put it in terms of jobs from Final Fantasy (one of my favorite games), service planners and developers are like monks or black mages with specialized skills to defeat enemies, whereas QA engineers are more like red mages.

─ What does a red mage do? I'm afraid I don't know much about games...

Nakagawa: I don't think they understand, Mr. Ueda! (Laughs)

Ueda: It's a jack-of-all-trades job that has both fighting and magic capabilities. However, they don't have any specialized skills, and you can defeat enemies with other jobs. To tell the truth, there are other companies that don't have QA engineers.

But if you have a red mage, they can cast "haste" (magic that improves a character's speed) and can take on a supportive role. The red mage job raises the level of what the entire party can do while preserving its overall balance.

Fact 6: QA engineers are both quality specialists and generalists with technical knowledge

─ What skills is a QA engineer expected to have?

Ikeda: The work that we need to do is quite varied, so we're expected to be generalists who have a broad knowledge of technology rather than specialists that excel in one field.

 

For example, from a technology perspective, rather than having a deep understanding of and being able to write code in a specific language, it's better for us to have a grasp of how the code is written and works as well as of the roles that servers and networks play, and understand the overall flow of the development lifecycle. Once you start giving examples, it's hard to stop.

Of course, in addition to development knowledge, we need testing knowledge.

Nakagawa: That's true. In terms of development technology, we need to know how services are developed even if we can't develop them ourselves.

There's a lot of technology we need to learn about within LINE service development, and I think QA engineers who know about a lot of those technologies have the advantage.

Project management skills are also important. For example, if you find issues in a project, it's difficult to solve all of them by yourself. In these cases, you have to get the understanding of other project members and work together to solve them, but in order to do that, you can't just say state the issues; you need to understand them and explain them clearly to the other members in a way they can accept.    

Ueda: We have members with experience as system integration (Sl) developers, and we also have members who gained experience as QC testers.

Our department isn't lopsided, but not much time has passed since it was established and we're a technical group, so most of our members have engineering, test engineering, or project management skills.

Nakagawa: There are a lot of situations where we're expected to have engineering skills, so moving forward, I'd like to hire more people who have engineering and project management experience.

I think this job is rewarding for people who are currently working in development for a specialized service but

want to get involved with more services overall, and are interested in improving project processes or building stronger project foundations/frameworks.

 

Fact 8: QA engineers like taking care of others

─ Please tell us what's difficult and rewarding about being a QA Engineer.

Ueda: If you like supporting people, then as a sort of unsung hero, I think you'd feel rewarded and interested by moving a project in a better direction.

 

Difficulty...I think everything is difficult. We have to work with everyone in the project as a whole, so I think negotiation and communication from a variety of angles is really difficult. We also have to continually study a broad variety of technical skills, as well as brush up on our communication skills.

 

The IT industry is constantly evolving, so you always need to have your eyes and ears open to absorb new information and knowledge. I think the people who are a good fit for QA are those who are curious, and can't resist the impulse to find out why things are the way they are. Those are the kind of people I like working with.

 

Fact 9: "Your general skills being tested" is interesting

Ikeda: I think the fact that your general skills are tested in this field is both interesting and difficult.

As we've told you, the knowledge and activity demanded of QA engineers is broad. Just like "full stack engineers" who can take on a wide variety of engineering work by themselves, we utilize our broad knowledge in each phase of a project (such as planning, development, testing, and operation or service growth after release) and improve project quality using our quality-related work as a base.

We work to solve any and every project issue while taking the unique circumstances of that project into account. It's very difficult, but that and the interesting aspects are just two sides of the same coin.

 

Fact 10: You can be a part of everything you're interested in

Nakagawa: This is similar to what Mr. Ikeda said, but I think that the "breadth" of what we do is both difficult and interesting. There's a lot that we need to look at, so it's not enough to excel at just one thing.

It's not enough to have broad experience, either, if that experience is too shallow. To a certain extent, we're expected to be able to do things ourselves, so we have to expand our knowledge and skills on a daily basis.

On the other hand, being independent means you can take part in everything you want to do. You won't be told "You don't need to do this work," so if you can independently work with an attitude of wanting to expand business or be involved in a service as a whole, I think you can see a lot of things throughout the course of your work.

─ Taking part in everything you want to do

When we first heard that our QA engineers couldn't explain their work specifically, we thought maybe the interview was over. But now we know that every member does anything related to overall quality work without limiting themselves to a certain field or role, which is precisely why the wide variety of work that our QA Engineering Department currently does can't be easily explained.

Thank you very much Mr. Ueda, Mr. Nakagawa, and Mr. Ikeda!

ー Development and QA field recruitment information (including the QA Engineering Department) ー

ー Development and QA field recruitment information(including the QA Engineering Department)ー

ー Find other posts in LINE Fukuoka's "Learn About" content series ー

Follow us on social media to get regular updates about the initiatives LINE Fukuoka is undertaking!

LINE official account (LINE ID: @linefukuoka)
Official Facebook account 
Official Twitter account