In software outsourcing, “tested” leaves an important question unanswered: correct for which business process, and with which data? For SIers, CTOs, PMs and DX leaders in Japan, one practical preparation step is to agree test data and expected results before user acceptance testing (UAT).
1. Start with business decisions
Rather than listing screens to check, identify the decisions users need to make: which request to approve, which report to reconcile, or whom to pass a case to. Each scenario should specify the person performing it, the initial state, the actions and the acceptable outcome. The customer confirms the business meaning; the development team clarifies how the system will present that outcome.
2. Prepare a shared test pack that can be reconciled
Both teams should review a test pack containing:
- Input data with identifiers and a version.
- Test accounts with agreed roles and permissions.
- Expected results for each scenario, with their business rationale.
- The preparer, the reviewer and the point at which the data is agreed.
Synthetic data can reflect the relevant business conditions. If real data is needed, agree beforehand what may be shared and how sensitive information will be handled. Avoid independently changing data and then comparing results produced under different conditions.
3. Preserve the conditions needed to repeat the check
Record the software version, environment, filters and execution time alongside test evidence. For workflows that change state, establish a way to return the test data to the agreed starting point. When results differ, compare the conditions first. Then determine whether the issue is a defect, an unclear expectation or unsuitable data. This gives the Japanese and Vietnamese teams concrete evidence for their discussion.
4. Hypothetical example: accepting a monthly order report
Suppose a company is reviewing a monthly order report. Its synthetic dataset contains 34 orders, including three cancelled orders. Both teams agree that the report should include only the 31 active orders, using the order month and an account authorised to view all orders.
If the report shows 30 orders, the reviewer records the scenario ID, data version, filters and missing-order list. If the account can view only one department, permissions should be checked before treating the discrepancy as an aggregation defect. This example does not describe a real TECHNEST project or result.
5. Assign responsibility for acceptance decisions
Each discrepancy should have an owner, a proposed action and a retest date. The customer appoints the business-result reviewer; the development team appoints the person coordinating corrections. Record unresolved points separately rather than marking them as passed to complete a checklist. Where items remain open, document their impact, any temporary workaround and who has authority to accept or reject them under the conditions agreed by both parties.
6. Build a basis for acceptance with TECHNEST
TECHNEST brings years of experience serving the Japanese market, designing and developing business systems, modernising legacy systems and working with Japanese consulting partners. Drawing on that experience, we propose discussing data, review responsibilities and the evidence to be handed over early, rather than waiting until the end of the project.
Explore our DELIVERY services or contact TECHNEST to discuss UAT preparation for your system.
