What UAT Actually Taught Me About Software Quality

I'd written unit tests before. I'd done manual testing in a browser. But running User Acceptance Testing with actual healthcare staff — people who had strong opinions about workflows and zero patience for software that didn't behave exactly as expected — was a different experience entirely.

At Geri Care, UAT wasn't a formality at the end of development. It was the moment where the gap between "what I built" and "what they needed" became very visible. Here's what I learned.

What UAT actually is

UAT is testing done by the people who will actually use the software, against real business scenarios, to decide whether it's ready for production. It's not about finding code bugs — it's about validating that the software solves the right problem in the right way.

For the GeriCare DNB Portal, the UAT sessions involved:

The medical director walking through the trainee assessment workflow
Supervisors testing the case review process they'd use daily
Trainees submitting logbook entries and checking their own progress pages

The thing that surprised me most

The bugs UAT found were almost never the bugs I expected. The code was functionally correct — data saved, queries returned results, permissions worked. What broke was the flow.

One example: after a supervisor approved a logbook entry, the page showed a success message and stayed on the same entry. The medical director pointed out that in the real workflow, after approving one entry, you immediately want to see the next pending one. My implementation was technically correct but interrupted the actual work pattern.

The most useful UAT feedback is never "this button doesn't work." It's "this is not how we actually do this." That distinction matters enormously.

How I ran UAT for the DNB Portal

I prepared a set of test scenarios based on real workflows, not technical test cases:

Scenario 1 — Trainee submits a logbook entry
  1. Log in as trainee
  2. Navigate to New Entry
  3. Fill in patient details, procedure type, notes
  4. Submit
  Expected: Entry appears in 'Pending Review' list for supervisor

Scenario 2 — Supervisor reviews and approves entry
  1. Log in as supervisor
  2. Open pending entries list
  3. Open the trainee's submission
  4. Add feedback note
  5. Click Approve
  Expected: Entry moves to 'Approved', trainee notified

Running scenarios this way — rather than "click this button, check that field" — revealed workflow problems that checklist-based testing would have missed.

What I changed after UAT

Three categories of changes came out of UAT sessions:

Workflow fixes — navigation changes, adding "next" shortcuts, reordering form fields to match the order staff actually think in.

Missing states — edge cases that hadn't come up in development. What happens when a trainee submits an entry for a procedure type that requires a mandatory second supervisor review? I hadn't handled that state.

Language mismatches — the terminology in the UI didn't always match the medical terminology staff used. "Case entry" became "Logbook entry." Small changes, but they affected how quickly staff could find things.

Regression testing after changes

After fixing UAT issues, I ran a structured regression pass across all modules before re-presenting to stakeholders. The checklist was straightforward:

All three roles (admin, supervisor, trainee) can log in
Role permissions are enforced correctly at the API level
All CRUD operations on core entities work correctly
All changed workflows function as updated
No regressions introduced in unchanged areas

Keep a regression checklist in your project. It takes 20 minutes to run and prevents the embarrassment of a UAT session where a fix you made last week broke something from two weeks ago.

UAT changed how I approach development. I now think about user workflows before I think about data models. The question "what does the user do after this action?" shapes more architectural decisions than most purely technical questions do.