Use user acceptance testing to prove that a Java-to-Clojure migration still supports real workflows, business decisions, reports, approvals, and operational handoffs before cutover.
User acceptance testing (UAT) validates that the migrated system still works for the people and workflows that matter. Automated equivalence tests can prove outputs match. Performance tests can prove budgets are met. UAT proves that the migration still supports real business work.
For Java-to-Clojure migration, UAT should focus on stable workflows, not on explaining Clojure to stakeholders. Users care whether orders are approved, reports reconcile, errors make sense, and handoffs still work.
| UAT area | What to prove |
|---|---|
| Core workflows | Users can complete the same tasks after migration. |
| Business decisions | Rules, statuses, warnings, approvals, and denials still make sense. |
| Reports and exports | Totals, filters, sorting, and formatting remain acceptable. |
| Error paths | Users see useful messages for expected failures. |
| Operational handoffs | Support, audit, reconciliation, and rollback procedures still work. |
Do not use UAT to discover basic equivalence defects that automated tests should catch earlier. UAT is expensive human attention; spend it on workflow confidence.
Strong UAT scenarios are written as user workflows, not implementation tasks.
| Scenario | Acceptance signal |
|---|---|
| Approve a normal account update | Status, audit entry, and user notification match expectations. |
| Reject an invalid import row | User sees the correct error and can fix the row. |
| Generate an end-of-day report | Totals reconcile with known examples. |
| Process a high-risk case | Manual review workflow is triggered and tracked. |
| Roll back a migrated path | Operations can return traffic to the Java path safely. |
Each scenario should include test data, user role, expected result, and evidence to capture.
Users should not need to know whether Java or Clojure produced the result. But the migration team needs enough evidence to debug differences.
1(defn acceptance-result [workflow-id status evidence]
2 {:workflow/id workflow-id
3 :workflow/status status
4 :workflow/evidence evidence
5 :migration/path :clojure})
The :migration/path marker is for the team, not for the user interface unless it is part of a controlled pilot. It helps support staff connect UAT feedback to the migrated path.
| Stakeholder | Useful UAT role |
|---|---|
| End user | Executes realistic workflows and reports confusing results. |
| Business owner | Approves rule behavior and acceptable differences. |
| Support or operations | Confirms errors, logs, alerts, and rollback steps. |
| QA engineer | Structures scenarios, evidence, and retest cycles. |
| Migration engineer | Triage differences and map feedback to code or data changes. |
Keep the group small enough to move quickly. Add stakeholders when their workflow or approval authority is needed.
UAT feedback needs enough detail to reproduce the issue.
| Feedback field | Why it matters |
|---|---|
| Scenario ID | Connects feedback to a known workflow. |
| User role | Explains permissions and expectations. |
| Input record | Lets engineers replay the case safely. |
| Expected outcome | Separates defect reports from preference changes. |
| Actual outcome | Shows the visible effect. |
| Severity | Helps decide whether cutover is blocked. |
Avoid vague tickets such as “Clojure report looks wrong.” Capture the report, filters, input data, expected total, actual total, and whether the Java path differs.
Use UAT results to make a release decision.
If stakeholders find a real behavior mismatch, route it back to equivalence tests. UAT should improve the automated safety net, not remain a one-time manual memory.