Why managing testing becomes the real challenge

Part 2 of the Epic series. Start with Epic I: The Awakening.

Once the scale of a Beaker implementation becomes clear, teams move into execution.

Spreadsheets get assigned, work gets divided up, and everyone starts pushing forward. On the surface, it feels like progress. But this is where the nature of the work changes.

Because Beaker testing is not a single stream of activity. It's dozens of parallel efforts moving at the same time, across different disciplines, all tied to the same go-live date. Each team is working through their portion, often interpreting requirements slightly differently, and moving at a different pace.

Most teams manage this the way they always have: spreadsheets, shared drives, and email threads. That approach works in the beginning. There's enough visibility to stay aligned, and the volume is still manageable.

But it doesn't stay that way.

In many implementations, this is the point where teams are already working through thousands of test scenarios in CCV2, with significantly more still to come in CCV3.

As testing expands, the cracks start to show. Test scenarios multiply quickly across Epic trackers. Teams end up working from different versions of the same files. Evidence is captured inconsistently, sometimes pasted into spreadsheets, sometimes stored in folders, and sometimes missed entirely.

Defects add another layer of complexity. They're usually tracked in a separate system, disconnected from the testing itself. Conversations about those defects happen elsewhere, and retesting is often tracked manually, if at all.

Approvals, which depend on complete and organized documentation, tend to get pushed to the end. By the time approvers are ready to review, they're looking at large volumes of material that have been assembled from multiple sources.

At the same time, the ownership of the work is shifting.

As projects move into CCV3, more of the responsibility moves into lab operations. The same teams responsible for running the lab day to day are now expected to execute and document large portions of end-to-end validation.

And the regulatory burden doesn't change.

The lab is still responsible for demonstrating that everything has been appropriately tested, reviewed, and documented in a way that will stand up to inspection. That responsibility doesn't sit with Epic or the implementation team. It sits with the lab.

At that point, the questions start to change.

It's no longer just about whether testing is being completed. Teams start asking:

• Which version of the file is current?
• What has actually been tested versus what has been marked complete?
• Where is the supporting evidence?
• Have defects really been resolved and retested?

And most importantly, are we actually ready?

This is where things begin to slow down.

Not because people aren't working hard, but because coordination becomes the limiting factor. Testers are balancing project work with day-to-day lab responsibilities. Project managers spend more time chasing status than managing progress. Approvers are waiting for something coherent to review.

The work is happening, but it's no longer easy to see how it all fits together. What started as a structured plan begins to feel fragmented. And that's the part that isn't obvious at the beginning.

Execution is hard. But managing execution at scale, across thousands of scenarios, multiple teams, and disconnected tools, is where most Beaker projects start to fall behind.

And none of this shows up in a status report.

Next in the series: Epic III: The Avalanche