Testing Legacy Healthcare Software Without Drowning in Test Cases

Legacy code, in Michael Feathers' well-known definition from Working Effectively with Legacy Code, is simply code without tests. Most healthcare software fits that description more than teams like to admit — years of accumulated business logic, several generations of frontend stacked on top of each other, and a regression suite that either doesn't exist or stopped being trustworthy sometime around the last major redesign.

That's a hard enough problem for a typical B2B app. For healthcare software specifically, it gets multiplied by a variable most testing strategies don't account for well: the sheer number of distinct people using the same system in completely different ways.

The permutation problem: personas × workflows × clients​

A single care-coordination or patient-engagement platform might serve:

• a patient checking lab results on a phone
• a family caregiver managing medication schedules for a parent
• a physician reviewing charts between appointments
• a front-desk coordinator rescheduling visits
• a billing specialist reconciling claims

— all inside the same application, often the same day.

Each of those personas sees a different slice of the UI, has different permissions, and follows a different workflow through the same underlying services. Now add the layer most healthcare software vendors deal with that a typical SaaS product doesn't: every hospital system or clinic client usually runs a customized configuration — different branding, different enabled modules, different intake fields, different approval chains.

Multiply personas by workflows by client configurations and you get a combinatorial test matrix that grows far faster than any team's capacity to hand-write scripts for it. That is the same reason personas in testing matter far beyond marketing research decks: without them, automation validates "the button works," not "this user can finish the job."

Why "just write more Playwright/Selenium tests" breaks down here​

The standard advice runs into a wall specific to legacy healthcare codebases. Locator-based scripts are brittle by nature; they break when a selector, a DOM structure, or a UI library changes. Legacy applications are exactly where that risk concentrates, because the frontend is rarely a single coherent codebase — it's several eras of decisions layered together.

Teams that try to hand-author full persona-by-workflow-by-client coverage end up spending more engineering time maintaining flaky specs than writing new ones, and coverage still lags behind what actually ships. We've covered the broader pattern as the quiet death of the test script — healthcare just turns the volume knob up.

There's also a bootstrapping problem specific to legacy code that doesn't get talked about enough: writing your first meaningful test suite for an untested legacy system is its own project. You can't do textbook test-driven development — write the test, then the code — on code that already exists and was never written test-first to begin with.

What legacy teams actually need is closer to Feathers' characterization testing idea: get coverage around what the system currently does, safely, before you touch it. That's a different problem than greenfield TDD, and most E2E frameworks assume you're starting from a blank test file.

Where O2 fits: diff-scoped, persona-aware testing​

This is roughly the gap DevAssure's O2 agent is built to close, and it's worth being specific about what it actually does rather than taking marketing at face value.

Diff-scoped generation, not a blank test file​

O2 reads a pull request's diff, maps which user flows the change could affect (blast radius), and generates and runs targeted tests against just those flows — without requiring a pre-existing script library to start from. For a legacy app with sparse or no prior coverage, that matters: you're not blocked on writing an initial suite before you get any safety net at all.

DevAssure's comparison page against Playwright claims a setup difference of about two minutes for a GitHub Action versus hours-to-days of playwright.config, fixtures, and first specs. That's DevAssure's framing, not an independently verified benchmark — but the underlying architectural claim (diff-scoped generation vs. hand-written specs you own end to end) is a real and meaningful difference, not just copy. See also how to automatically test every pull request.

Personas built into the agent, not bolted onto specs​

This is the part that maps most directly onto the healthcare permutation problem. DevAssure builds persona definitions into its agent through a personas.yaml file — you describe who's using the app (age range, technical familiarity, device, behavioral tendencies) and the agent adapts how it explores the application accordingly, rather than clicking through every element like a generic script would.

In Why Personas Matter in Testing, DevAssure CTO Santhosh Selladurai walks through a children's educational site (ages 6–12) where hover-only actions and unlabeled icons meant roughly 30% of available actions went unused by the intended audience — and shows how a personas.yaml entry for kids on tablets (limited exploration, prefers visual cues, avoids complex interactions) changes agent behavior versus an admin on desktop.

The same logic transfers directly to healthcare: a caregiver who won't explore hover states versus a physician who navigates a chart review flow fluently. Modeling that difference is exactly what a hand-written Playwright spec typically doesn't do, because someone has to think to write persona-specific assertions rather than just "does the button work."

# Example shape — adapt fields to your product
patient:
  description: Outpatient checking labs and messages on a phone
  technical_familiarity: low
  device: mobile
  behavior:
    - limited exploration
    - prefers clear labels
    - abandons confusing multi-step forms
physician:
  description: Clinician reviewing charts between appointments
  technical_familiarity: high
  device: desktop
  behavior:
    - keyboard-heavy navigation
    - dense screens expected
    - intolerant of extra clicks in chart review
caregiver:
  description: Family member managing meds for a parent
  technical_familiarity: medium
  device: tablet
  behavior:
    - cautious with destructive actions
    - needs confirmation for schedule changes

O2 vs. hand-written Playwright/Selenium, feature by feature​

Neither column is "wrong." Many teams run both: a thin Playwright/Selenium core for compliance-critical golden paths, and O2 on every PR for change-scoped coverage across personas the golden path never modeled.

The honest caveat: this doesn't remove the human from the loop​

None of the above removes the human from the loop, and it's worth being clear about that rather than overselling it. O2 doesn't replace a QA team. Someone still has to:

• define personas accurately
• review what the agent generated in each PR
• catch the genuinely bespoke client customization the agent misreads
• keep compliance-adjacent audit trails where regulators expect them

Call it AI babysitting if you want — it's real work. But it's a materially smaller job than authoring and maintaining a hand-written script for every persona-workflow-client combination by hand, and it shifts human attention to judgment calls (is this persona realistic? did this catch the actual regression?) rather than selector maintenance.

For regulated healthcare specifically: agentic breadth is not a substitute for human-reviewed coverage on safety-critical paths. Treat O2 as the layer that stops the permutation matrix from drowning the team — not as the only gate between a PR and production.

The bottom line​

Legacy healthcare software fails the Feathers test twice: too little coverage, and too many humans sharing one product for generic scripts to represent. Diff-scoped, persona-aware PR testing won't invent a characterization suite for every line of ten-year-old billing logic overnight. It will keep the next PR from shipping a regression for the caregiver path you never had bandwidth to script — without asking your team to drown in cases first.

Links​

DevAssure​

• Why personas matter in testing: https://www.devassure.io/blog/persona-testing/
• Healthcare application testing: https://www.devassure.io/blog/healthcare-application-testing/
• The quiet death of the test script: https://www.devassure.io/blog/quiet-death-of-the-test-script/
• How to automatically test every pull request: https://www.devassure.io/blog/automatically-test-every-pull-request/
• Test-driven development: https://www.devassure.io/blog/test-driven-development/
• DevAssure vs Playwright: https://www.devassure.io/vs/playwright
• DevAssure O2: https://www.devassure.io/o2-testing-agent
• Pricing: https://www.devassure.io/pricing
• DevAssure: https://www.devassure.io

External references​

• Michael Feathers — Working Effectively with Legacy Code (overview): https://en.wikipedia.org/wiki/Working_Effectively_with_Legacy_Code
• Characterization tests / legacy change algorithm (summary): https://understandlegacycode.com/blog/key-points-of-working-effectively-with-legacy-code/