Introduction

My name is Endo and I am the FE team leader of QA Group at KINTO Technologies.
I mainly check QA cases from multiple products and projects for the frontend of the Japanese KINTO website developed by KINTO Technologies, and allocate and manage tasks to each of the QA team members.
While working, I often engage in conversations with people from both the development side and QA. This time, when we were chatting, a question came up: "Why do we even do QA? ". Since I've been given this opportunity, I would like to share my own thoughts on this.

Is QA Necessary in Development?

Before writing about the role and necessity of the QA team on the theme, "Why do we do QA?", I would like to consider whether QA itself is necessary in the first place.
In some seminars and articles on quality, there is a discussion about the necessity of QA. I have heard someone say that in Agile development, QA is unnecessary if each team has a QA role within the team, rather than having a separate QA team outside of it.
For example, if there is a separate QA team from an Agile team, the following concerns may arise:

• Trying to be flexible in responding to specification changes in a sprint is likely to affect the subsequent QA process.
• The separate lead time for QA to understand the specifications lengthens the QA process.
• When a problem occurs, it is not addressed during the sprint, leading to significant rework.
  From these points, I think the main idea of the discussion was that Agile development can be managed without these concerns as long as there are members in the team who can handle everything from development to testing, including the role of QA.
  Here, I believe it is important to note that the role of QA itself is not being denied, even though a QA team may not necessary.
  On the contrary, those who argue that a QA team is necessary may believe that:
• By having a QA team independent from the development who can make objective judgments, quality can be improved from a different perspective.
• Knowledge from different specifications can be easily centralized in the QA team and information can be obtained across projects.
• Based on this conjunction of knowledge, the QA team can provide missing considerations and necessary information for other projects running in parallel.
  On the other hand, challenges of inserting a QA role within an Agile team include:
• The difficulty to include highly skilled team members who have the knowledge to oversee everything testing-related, from development to system testing
• If that is not the case, then it will be necessary to train team members, but acquiring the appropriate skills takes time.
• Knowledge pools easily around skilled members, and when those leave the team, it becomes difficult to handle QA.
  I have come across an article in columns of other companies that they do not have a department or group called QA, yet they do QA work for their service users. In other words, whether to create a QA team as an organization is a choice based on development methods and organizational culture. However, I feel that everyone has a common understanding that the role of QA is necessary to check the overall quality for users based on system requirements.

The Role of QA Beyond Testing

When conducting confirmation and verification, QA is often seen as a specialized testing team, leading to a common misconception that QA is synonymous with testing. However, the role of QA is not only limited to testing. Here are three major aspects on this point.

(1) Confirm the correct understanding of specifications

When designing test scenarios, QA has to confirm system requirements and will ask questions when needed to the development and operations sides. From the point of conducting testing, QA first confirms what the “correct answers” are to the specifications, based on the requirements. Through this process, QA can point out details in the specifications, helping prevent requirement omissions and to refine the information given in the specifications.
The following is an example of a case where the "Screening Application Process" section of the KINTO website was revised.
In this case, the expected test result is that the design of "What is required for the application" and "Screening application steps" will match the screen specification. What is required in case of a regular web application is to upload a driver's license image. However, as KINTO services are also offered via dealerships where driver's licenses can be verified on the spot, the system should be created so that the dealership staff could skip the image upload (as indicated by the red box below). When we consulted this point with the development side, they realized that it was necessary to take it into consideration.

While it may be a minor detail, we consider the expected use cases and conditions, ensuring that the correct answer aligns with the expected test results. In this way, the specifications that should be in place are confirmed by making specifics for ambiguous expressions or omissions.
As mentioned above, through specification checks from the QA team, it is sometimes possible to point out requirements that the development side was not aware of.
In addition, by aligning test perspectives in parallel with the development process, although not at the requirements definition stage, we can enhance quality earlier, before testing is conducted.

(2) Organize documentation during test design

Working on tight deadlines during development can pose challenges to organize documentation effectively.
Even if each specification is available, there are cases where it may not be listed or the operating procedures may not be organized. In QA, while confirming the correct answers to the specifications mentioned in (1) above, the following aspects are identified as necessary in test design: scenarios, function confirmation, and display confirmation.

In this case, the original information is in the development side, so basically the materials are used as they are, but if necessary, QA lists procedures and organize the information to facilitate what to check during tests. We sometimes receive positive comments from members outside of the QA team, such as how they were able to gain a bird's-eye view of the overall functionality by referring to the materials created by QA, or how helpful it was in confirming certain processes. Since the information is consolidated within the project, the contents of the materials compiled by QA are not necessarily the latest, but they are organized for the purpose of understanding the current specifications. In addition, since QA can observe projects running in parallel from a horizontal perspective, they can provide information on concerns to the development side while organizing specifications, which can be helpful in terms of quality.

(3) Feedback from defect analysis

After a project is completed, a defect analysis will be conducted based on the results of the QA testing. The following is mainly done on a project-by-project basis. Depending on the characteristics of each project and product, we offer feedback which may include requests for additional consideration during the requirement definition stage or for stronger emphasis on unit testing.

By providing feedback to the project at review meetings, they will be able to use it as a reference for the progression of the next project tasks.
When analyzing defects, we collaborate to clarify the defect trends for each product and identify project-specific issues that need to be addressed.
It is important to report not only the weaknesses of the project but also the effects. For example, sharing a different approach to fulfilling requirements from a different project to provide insight; or if the portion of a unit test was successful it is crucial to communicate what has been effective. Our reports are to guide the initiative towards a positive direction and strengthen it further, so we are cautious to address not only negative aspects when giving feedback.
Consequently, the role of QA is significant not only in testing, but also in building quality.

So Why Do We Practice QA?

For us who provide web and app services, for example,

• Design is consistent, but buttons are in different positions on different screens
• Screen transitions take time
• While there are no issues on a PC, the text becomes challenging to read on a smartphone due to changes in display size.
  If these issues persist, users may choose not to use the service, finding it difficult to use or view before even experiencing the appeal of the service. I believe that performing QA work is meaningful not only to confirm that the requirements are met, but also to improve a website so that visitors can use it comfortably.
  In addition, since system requirements can be checked horizontally through QA work, it also plays a role in discovering unexpected project risks by obtaining a certain level of specification information.
  As KINTO Technologies has multiple projects running concurrently for each product,
• Are there any risks associated with the timing of project releases?
• If a common specification changes, are other products that may be affected aware of the changes?
• By conducting a series of tests, are there any issues with the functionality, including linking data across products? Even in areas where the project side has already considered risks, we check them again during QA to identify any remaining risks and ensure built-in quality.
  In this way, I think it is necessary for QA to confirm the requirements from an objective viewpoint for our customers who actually use the service, and provide support for the creation of quality aspects.
  I believe that this mindset of "for our customers" is important. Our services are used by the majority of people. However, the customer faces the service as an individual. We must prevent a situation where the customer never visit our website again due to minor difficulties in use or view. Therefore, I believe that the mindset of “for our customers” plays an important role in creating a positive cycle. It effectively communicates the appeal of the services we aim to convey, ultimately leading to the acquisition of more customers.

Conclusion

In this article, I wrote my thoughts starting from the point of why we do QA in the first place. As mentioned earlier, the role of QA varies from organization to organization. If you agree with this content or if you have different opinions and are interested in QA, please feel free to contact me.
Moreover, If you find the idea of doing QA together enjoyable, or if you want to make QA more exciting and better, you are always welcome! Please apply from the recruitment page below. We can start with a casual interview.
https://hrmos.co/pages/kinto-technologies/jobs?category=1783696806032474116