DEV Community: Sicily Labs

We Almost Shipped Software That Wasn't Ready

Sicily Labs — Fri, 18 Sep 2026 13:57:21 +0000

UAT had passed.

The tests were done.

The obvious bugs were fixed.

Everyone was getting ready for go-live.

So why did we stop and ask:

“Wait... are we actually ready?”

Because we realized something important.

UAT was telling us about the software. It wasn't telling us everything about the rollout.

What Was Missing?

Passing UAT doesn't automatically tell you:

Whether all critical blockers are closed
Whether the right stakeholders have signed off
Whether users are trained
Whether important feedback has been resolved
Whether remaining risks are understood
Whether handover is ready

The software can be tested and accepted while the rollout itself still has gaps.

That's the Dangerous Part

The dangerous assumption is:

UAT Passed
     ↓
Ready to Go Live

But real rollouts are more like:

UAT
 ↓
Defects & Retesting
 ↓
Sign-off
 ↓
Training
 ↓
Feedback
 ↓
Blockers & Risks
 ↓
Readiness
 ↓
Go-Live
 ↓
Handover

The more disconnected these activities are, the harder it becomes to answer one simple question:

“Are we actually ready?”

This Is Why We're Building Verixa

Verixa connects the activities between software delivery and rollout readiness — from UAT and defects to sign-off, training, feedback, blockers, readiness, and handover.

Because we don't just want teams to know that their software passed testing.

We want them to know what still stands between tested software and a successful rollout.

We're opening the waitlist for early users.

Join now and get your first month free.

https://verixa.today

What does your team check before going live?

Is “UAT passed” enough, or do you have a separate rollout-readiness process?

The UAT Checklist: 10 Things to Check Before You Sign Off

Sicily Labs — Thu, 17 Sep 2026 13:15:37 +0000

User Acceptance Testing is almost complete.

The test cases are executed.

Most results are passing.

The team is asking for sign-off.

Before you approve the release, stop for a moment.

Do you actually have enough evidence to sign off?

A successful UAT process is more than getting users to click through test cases and mark them as passed.

Here are 10 things I would check before treating UAT as complete.

1. Are the Requirements Covered?

Start with the requirements.

For every important requirement, you should be able to answer:

Where was this requirement tested?

If a requirement has no corresponding test, you may have a coverage gap.

A simple traceability chain looks like:

Requirement
    ↓
Test Case
    ↓
Test Result
    ↓
Evidence

The goal is to know what was tested and why.

2. Were the Right Users Involved?

UAT should involve people who understand the actual business process.

Ask:

Who performed the testing?
Which roles were represented?
Were the relevant workflows tested?
Were real-world scenarios considered?

A technically successful test doesn't necessarily mean the system works well for every intended user.

3. Do You Have Test Evidence?

A result saying PASS is useful.

Evidence makes it stronger.

Depending on the project, evidence might include:

screenshots
documents
recorded results
comments
other supporting information

The important thing is being able to understand what happened during the test.

4. What Happened to the Failed Tests?

Don't only count the passes.

Look at the failures.

For every failed test, ask:

Was it fixed?

Was the fix retested?

Is the issue still open?

Is it blocking the release?

A failed test that has been fixed but never retested is not the same as a successfully verified fix.

5. Are Critical Defects Closed?

Not every defect has the same impact.

A minor UI issue and a failure in a critical business workflow should not necessarily be treated the same way.

Before sign-off, identify the defects that could prevent the organization from successfully using the system.

Then make their status visible.

6. Has Retesting Been Completed?

Fixing a defect is only part of the process.

You also need to verify the fix.

The flow should be:

Failed Test
    ↓
Defect
    ↓
Fix
    ↓
Retest
    ↓
Verified

Without the retest step, the team may be assuming that the fix worked.

7. Is the Sign-Off Coming From the Right Stakeholder?

UAT results provide evidence.

Sign-off represents acceptance.

Those aren't exactly the same thing.

Make sure the person approving the release is the appropriate stakeholder for the project or business process.

And make the approval traceable.

8. Are Users Ready?

Passing UAT doesn't automatically mean users are prepared for production.

Consider:

Has training happened?
Have users received the necessary information?
Do they understand the new workflow?
Are additional training sessions needed?

Software can be ready while users are not.

That is still a rollout risk.

9. What Feedback Remains?

Users may have questions, concerns, or issues that don't fit neatly into a test case.

Don't lose that information.

Track important feedback and determine whether it is:

resolved
still being investigated
planned for later
a blocker
an accepted risk

The important thing is that it has a visible status.

10. Can You Explain Why You Are Ready?

This might be the most important question.

If someone asks:

“Why are we ready to go live?”

Can your team answer with evidence?

You should be able to point to:

Requirements
     +
UAT Results
     +
Evidence
     +
Defects & Retesting
     +
Sign-Off
     +
Training
     +
Feedback
     +
Remaining Risks

That is much stronger than:

“Everyone thinks we're ready.”

UAT Sign-Off Should Be a Decision, Not Just a Checkbox

A UAT sign-off should represent an informed decision based on the state of the software and the people who will use it.

That's why I think it's useful to separate three ideas:

Tested — the software has been validated against defined scenarios.

Accepted — the appropriate stakeholders have approved the result.

Ready — the broader rollout conditions have been considered.

These states are connected, but they aren't identical.

A Simple UAT Sign-Off Checklist

Before signing off, ask:

[ ] Requirements covered
[ ] UAT completed
[ ] Test evidence available
[ ] Failed tests reviewed
[ ] Critical defects resolved
[ ] Fixes retested
[ ] Appropriate stakeholder approval
[ ] User training addressed
[ ] Important feedback reviewed
[ ] Remaining risks understood

If you can't confidently check several of these boxes, the question may not be:

“Can we sign off?”

It may be:

“What is still missing before we can sign off?”

That's an important difference.

How does your team handle UAT sign-off?

Do you use a formal UAT checklist, or is sign-off mainly handled through spreadsheets, meetings, tickets, and emails?

What is the one thing you always check before approving a release?

[Boost]

Sicily Labs — Thu, 17 Sep 2026 09:12:33 +0000

Sicily Labs for Sicily labs

Sep 16

Your Software Passed UAT. So Why Isn't It Ready for Production?

#qa #testing #productmanagement #softwaredevelopment

3 min read

Your Software Passed UAT. So Why Isn't It Ready for Production?

Sicily Labs — Wed, 16 Sep 2026 08:31:20 +0000

Passing UAT feels like the finish line.

But is it?

Your requirements are implemented.
Your users have tested the system.
Your test cases have been executed.
The critical defects have been fixed.
UAT has passed.

So the obvious question is:

Are we ready to go live?

Maybe.

Because passing UAT and being ready for rollout are not exactly the same thing.

UAT Is Only One Part of Rollout Readiness

User Acceptance Testing answers an important question:

Does the software meet the expected requirements?

Rollout readiness goes further.

It asks whether the software has been tested, accepted, understood by users, cleared of important blockers, and prepared for handover.

That means looking beyond the test results.

For example:

Were the important requirements validated?
Were failed tests resolved and retested?
Are critical blockers closed?
Has the appropriate stakeholder signed off?
Have users been trained?
Has user feedback been addressed?
Are known risks documented?
Is the system ready for handover?

A UAT pass does not automatically answer all of these questions.

The Gap Between Testing and Going Live

A typical software rollout can look more like:

Requirements
      ↓
UAT
      ↓
Defects
      ↓
Fixes & Retesting
      ↓
Sign-off
      ↓
Training
      ↓
Feedback & Issue Resolution
      ↓
Readiness
      ↓
Go-Live
      ↓
Handover

The important part is that these activities are connected.

A defect discovered during UAT should be connected to its fix.

The fix should be retested.

The completed testing should contribute to sign-off.

Training should prepare the people who will actually use the system.

Feedback should continue to inform the rollout.

And all of this should contribute to the final readiness decision.

A High Pass Rate Can Still Hide a Problem

Imagine a release has 100 UAT tests.

95 pass.

It sounds good.

But what if one of the five failed tests affects a critical business process?

The percentage alone doesn't tell you whether the release is ready.

Rollout readiness needs a broader view:

Requirement coverage + test execution + defects + retesting + sign-off + training + feedback + blockers + known risks

The goal isn't to create another complicated metric.

The goal is to make the state of the rollout visible.

The Real Problem Is Often Fragmentation

In many teams, rollout information lives across different places:

Spreadsheets. Tickets. Emails. Chat messages. Documents. Training reports. Meeting notes.

Each tool may be useful on its own.

The problem appears when someone asks:

“Are we actually ready to go live?”

And answering that question requires checking five different systems and asking three different people for updates.

The connection between testing, defects, approvals, training, feedback, and readiness gets lost.

That is where traceability becomes important.

Tested Doesn't Always Mean Ready

This is the distinction I keep coming back to:

Tested means there is evidence that the software has been validated.

Accepted means the appropriate stakeholders have approved it.

Ready means the software, users, risks, blockers, and operational handover have been considered together.

Those are different states.

And treating them as the same can make software rollouts harder than they need to be.

Why We Started Building Verixa

This gap is exactly what led us to build Verixa.

Verixa is designed as a connected workspace for software acceptance and rollout readiness — bringing together requirements, UAT, defects, approvals, training, feedback, blockers, and handover.

The idea is simple:

Build → UAT → Fix → Sign-off → Training → Feedback → Readiness → Handover

Instead of asking only:

“Did the software pass testing?”

teams can ask the bigger question:

“Do we have enough evidence to say this rollout is ready?”

That distinction matters.

Because shipping software isn't always the end of the delivery process.

Sometimes, it's the beginning of the most important part:

making sure people are actually ready to use it.

What Does “Ready for Production” Mean in Your Team?

When your team says a release is ready for production, what do you actually check?

Is it mainly the UAT result?

Or do you also look at defects, sign-off, training, feedback, blockers, and handover?

I'd love to hear how other teams handle the gap between “tested” and “ready to roll out.”