Test a release before operations depend on it

Why does a green build still fail on Monday morning?

Automated checks prove the code ran. They do not prove an operator can finish the job the business hired the software to do. The failures that hurt are usually ordinary: a status that cannot be corrected, a permission that blocks the person on shift, or an import that accepts a file and drops a row.

What should you test before a release operations will depend on?

Test the path a real user takes, not only the happy path in the ticket.

1. The main job. Complete the workflow with the data shape the team actually has, including the messy fields.
2. The correction. Change a record after it has moved forward. Most operations work is correction, not first entry.
3. The handoff. Confirm the next person can see the result without asking the person who entered it.
4. The failure. Disconnect a dependency, submit a bad file, or use an account with the wrong role. The screen should say what happened and what to do next.
5. The rollback. Know how to return to the previous version if the release cannot stay up.

Write the expected result before you run the case. If the expected result is "it should work," the case is not ready.

Who needs to be in the room?

A developer can prepare the build. The person who will run the workflow on a normal day should accept it. If that person is absent, the release is a demo, not an acceptance.

What is enough evidence to ship?

Enough evidence is a short list of passed cases tied to the acceptance criteria, plus an owner for anything deferred. A large unprioritized defect list is not a release decision. A named list of what must work on day one is.

Checklist

• Cases written from the operating workflow, not only from the ticket
• Correction and permission cases included
• Operator available to accept the path
• Rollback owner named
• Deferred items written down with a date

---