Introduction

My name is Endo, and I am the leader of the QA group at KINTO Technologies. In this article, I'd like to give you a look into our daily QA work especially through our daily efforts on subjects that anyone involved in QA may have encountered in the course of their daily tasks. There are already a couple of articles about QA work:

• Manager Zume's Quality Assurance Group Introduction
• Team Member Okapi's Increased Awareness of QA

So I hope you will read them as well.

I hope this article sparks conversations like, 'Here’s how we do it at our workplace,' or 'How do you usually handle this kind of task? I'd love to hear your thoughts!

QA Workflow and What We Focus On

Our QA work mainly involves:

• QA for development projects
• QA for maintenance and updates
• Test Automation
• Internal QA improvements
  • QA work improvement activities
  • Study sessions

In this article, I'll walk you through the QA workflow for projects and share the key perspectives we keep in mind.

Different Views on QA

The outline of QA work is explained during the orientation when joining the company and at the kickoff of each project. However, since all project members are experienced professionals, they have their own ideas and expectations of QA based on their past experience. Because of that, we sometimes run into misunderstandings like, "Isn't QA supposed to check things down to this level?" Such gaps in understanding can even pop up among team members. However, despite differences in what people expect from QA, I think we're mostly aligned on one key point:

"We want to identify and resolve any lingering quality concerns during the QA phase."

I think the key is to figuring out how to address those concerns, ease that uncertainty, and make sure the release goes smoothly.

To start, we go over the following three main points during the project kickoff, so everyone involved has a clear understanding of QA.

(1) Let's build quality together!
(2) If you have any concerns about quality, don't hesitate to reach out.
(3) QA's feedback isn't absolute, so let's consider whether it can be addressed as a project.

Quality is something we build together!

Point (1) might go without saying, but quality can't be improved by QA alone. As a result of the aforementioned misunderstandings, we sometimes get requests that lean more toward white-box testing, like:

• Checking the details at the unit level
• Checking with a focus on source and data flow

And more. QA work mainly focuses on black-box testing, so when it comes to white-box testing, we usually explain that it's more suited to be performed by the development side.

These requests often come from past experiences where QA helped before, or from a hope that QA will "definitely" catch issues they might have missed.

While there's generally a shared understanding that QA handles things like system tests, acceptance tests, and checks at each phase, people's expectations can still vary depending on their past experience. Some may expect QA to dig into system-level checks like source and data flow, while others expect a more user-centered checks. In general, though, I think QA is widely seen as a team that supports and checks quality control using its own indicators, including the standardization of all development processes.

While we in QA want to meet all those expectations, there are limits to what we can catch, and the testing time is not endless. So, it is necessary for everyone to approach quality as something we build "together," especially when working under tight timelines to achieve our quality goals. However, it's not just about QA verifying requirements, pointing out issues, and having them fixed as a routine task. We believe better results come when we're aligned on QA specifications, test plans, and test timing by matching requirements together, aligning test perspectives together, and considering improvements together. And through those thorough discussions, we can apply those insights to test design.

Developer Concerns Are a Goldmine of Tips for Improving Quality

In reviews from a testing perspective, we can usually identify specific concerns that the development team has. But sometimes, the feedback is more vague, like simply feeling risky about a certain process. Even if those concerns aren't clearly articulated, they're incredibly valuable for QA when defining test perspectives and designing tests. That vague sense of unease often comes from things like complex code, unclear requirements, or uncertainty about whether all the finer details were fully nailed down. Even when everything seems to be working fine, so it's hard to put into words, but developers still have that gut feeling that something might be off. Surprisingly, testing these areas can sometimes reveal unexpected issues, so these instincts shouldn't be taken lightly.

As QA, we review the requirements and plan and design tests to address specific concerns. These instincts offer valuable hints that help us strengthen our testing and apply deeper coverage than originally planned. In the QA phase, our goal isn't really to catch unit- or integration-level bugs. Instead, it's about executing hundreds of test cases based on requirements and catching that one critical or fatal bug. That's where QA really shows its value. So, rather than worrying about whether a developer's gut feeling might lead to wasted effort, we try to create an environment where those instincts and hints can be freely shared. By encouraging open conversation, we can uncover areas to strengthen beyond the test perspectives which helps us design better tests and ultimately improve quality.

For example, instead of ending a test perspective meeting like, "Here's how we plan to proceed. Please let us know if anything comes up." We try to add a simple question like, "Is there anything in this spec that makes you feel uneasy?" By adding this, the conversation can turn into something like, "Now that you mention it..." Even if you have concerns but can't put them into words, you may feel there's nothing worth sharing. But let's talk to QA anyway! By taking the aforementioned together approach, we can strengthen our test coverage and often uncover a goldmine of valuable insights in the process.

Don't Get Distracted by QA Feedback, Stay Focused on the Original Goal

If QA is seen as only working within a limited test scope, it can sometimes lead to misunderstandings such as

thinking QA merely follows the requirements without understanding the code, focuses on overly detailed issues, and causes delays to the release schedule.

However, by providing the above-mentioned explanation in advance, people start to see QA in a completely different light, seeing it as a team that builds quality "together."

On the other hand, with the change in perspective, some people start to worry that everything QA "points out" must be addressed before the release can go live.

What QA "points out" with testing fall into the following three categories:

• Bugs: QA points out behavior (display) that differs from the specifications as understood by QA
• Improvement requests: There is no problem with the specifications, but QA suggests a change to improve the functionality
• Questions: Ask about unclear points in the specifications

For bugs, QA points them out when we notice behavior that doesn't match the expected specifications. The development team reviews the issue, makes any necessary fixes, and then QA rechecks the fix. Improvement requests are suggestions where there is no issue with the specifications, but it might be better to improve them. For example, if most screens have a button in the top right, but one screen has it in the top left, there's no problem with the button's functionality, but QA might propose moving it for consistency. Questions arise when QA finds unclear parts of the specifications while testing. We ask for clarification first, before labeling anything as a bug.

It doesn't mean that all of these points need to be addressed before release. Ideally, every issue should be addressed, and every question answered, but depending on the project's circumstances, it is not realistic to tackle everything before release. If it's difficult to address all of the issues, it's the project, not QA, that decides which ones to tackle before release, based on their importance and priority.

QA's work is to conduct testing based on the idea of how things should be ideally according to the requirements. Naturally, even if the requirements are well-defined, there may be some parts of the specifications that are unclear. Ideally, everything would be addressed, but within the limited time available, it is important not to lose sight of the original goal by checking and organizing the final specifications through QA's feedback.

This leads to point (3), as a project, it's crucial to align on what kind of service will be delivered, and when. With that shared understanding, we can work toward building quality to meet that goal. This is where it's important for QA to provide solid support in terms of quality. Now, this might sound like we're suggesting that, given the time constraints, it's okay to just meet the bare minimum requirements and compromise on quality to release the service, but that's not the case at all.

As mentioned earlier, QA's work is to help the team move toward the project's defined goals by verifying whether the specified requirements are fully met. At the same time, if there are issues that could negatively impact the user experience, we will persistently discuss issues with stakeholders to address them. It's not about making compromises, nor is it about QA forcing our feedback onto the team. Instead, we focus on the project goals and the end users receiving the service, and we work together to decide how the project should respond and take action accordingly.

If a critical issue were to occur after release, the impact could be significant. So, QA stays fully engaged to help ensure quality is upheld. However, in larger projects, potential concerns are typically addressed early through the interviews mentioned in point (2). And given the nature of the development process, it's rare for a critical issue to suddenly appear at the very end. As a result, it’s extremely uncommon for the release date to be delayed due to QA work. Ultimately, what matters most is working together to achieve the target quality by the target release date. So, to repeat the important point: QA doesn't just point out issues and ask for fixes. It's about staying focused on the project's original goal to build quality together. For example, delivering the intended service to customers within the planned timeframe while making sure users aren't affected by any inconvenience or negative impact.

Conclusion

In this article, I focused on our mindset as QA and the communication practices we value, but from a more technical perspective, QA is also the only team that can take a cross-functional, bird's-eye view across all projects and products. If the opportunity arises, I'd like to share how QA provides support along with our approaches to test planning, defining test perspectives, and test design.

Sometimes, people approach us with QA requests a bit hesitantly. But the point is that we're in this together. We want to build a relationship where everyone feels comfortable collaborating without hesitation. After release, we often hear, "It was a huge help!" "Thanks so much!" At those times I always say, "Not at all! Thank you for taking QA's feedback seriously and responding with such care."I'm deeply grateful to everyone involved in the project and have great respect for their commitment. We strive every day to build trust by fully supporting the quality of the services we deliver. And when a service we've built together ends up being truly useful to users, I believe that's the true reward of working in QA. I hope this article has sparked some interest in working in QA. Also, if you're working in QA, I'd love to hear your thoughts and exchange ideas. Feel free to share your feedback on Twitter!

https://twitter.com/KintoTech_Dev/status/1619979941856280577?s=20