A North American development team and a Korean QA team worked in different time zones. To prepare the release of global distributed storage company K's product, we spent eight months aligning verification criteria and the reporting system, carried out regression automation and performance testing, and handed over the test assets.
When a defect is reported, the development team has to be able to understand the same problem the next day. How severe it is, whether it blocks the release, and what has to be re-checked after which fix must all be conveyed with the same meaning.
In collaboration across time zones, not every question can be resolved in a real-time conversation. Criteria that let the next piece of work continue from the record alone become important.
Company K's project was set up so that QA for a distributed storage product developed in North America was handled in Korea. From October 2025 to May 2026, IXC worked alongside the team on test strategy and execution, defect management, and release preparation.
Before testing began, we aligned roles and verdict criteria
Bringing in external QA does not automatically make the development team and the verification team judge things the same way. Looking at the same problem, one side may see an immediate fix as necessary while the other thinks it can be handled after release.
At kickoff, the boundaries of responsibility were documented, and defect severity, verdict criteria, and stage release conditions were agreed. The reporting format was aligned at the same time.
These criteria are not merely a format for simplifying communication. They define which checks are needed at which stage and how the remaining problems are to be explained.
The time difference itself cannot be removed. Instead, even when the record is read at different hours, the next action has to be decided with the same meaning.
Defects and remaining risk were delivered in the same format
Verification ran against the agreed criteria, and defects and residual risk were reported in the same format. This kept different recording styles from piling up while the project was under way.
A defect list alone may not adequately explain how ready a release is. If there are conditions that could not be checked, or constraints that remain even after a fix, they have to be readable together.
Consistent records help in comparing this information. The problems of the previous round and those of the current round can be understood by the same standard, and what has changed becomes easier to confirm.
When QA is entrusted to a team in another region, what matters is not only the hours spent testing but whether the development team can act on the results.
Recurring checks moved into automation assets
The critical regression checks repeated at every release were built as automated tests and connected to the deployment pipeline. The work was meant to run the flows that need repeated confirmation against the same criteria.
The target of automation is not to move every feature into scripts without exception. Prioritizing flows that recur often and are worth re-checking on every change better fits the purpose.
Nor does a passing automated test conclude the entire release decision. Judgment on newly added features, conditions outside the automated scope, and remaining problems is still needed separately.
At company K, the automation assets were placed inside the verification system. The direction was to separate the burden of people repeating the same actions from the problems people have to judge.
Performance testing meant separating the causes behind the numbers
Real usage patterns were composed into a load model, and normal and breaking ranges were verified separately. We examined which resource reached its limit first and separated what could be handled by adding capacity from what needed code improvement.
If a performance test checks throughput alone, the next step can be unclear. To make use of the results, you have to know what kind of requests ran for how long and where the constraint first appeared.
The same latency can call for a different response depending on whether the cause is a shortage of resources or a problem in the processing logic. That is why performance test results need not just numbers but an interpretation aimed at improvement.
In this project, that content was organized into a remediation list and the basis for operating capacity decisions.
We left a verification foundation usable after the contract ended
At the close of the project, the test strategy and execution records, defect management materials, automation scripts, and verdict criteria were handed over. What remained were the verification results used in preparing the product's release and assets that can be used again.
If the role of external QA is seen only as running tests on the team's behalf during the engagement, the same work may have to start over once it ends. Only when verification criteria and assets remain can the internal team carry them forward through later changes.
In company K's case, the eight months were both the period of engagement and the time in which a verification system was built up. The condition of development and QA being in different regions was handled by defining the standards for roles and records.
The core of global QA collaboration is not working at the same time. It is being able to explain the state of the product on the same evidence even while working at different times.