Retesting an Update After Undo Lab Update

Retesting after Undo Lab Update creates a fresh evidence chain from the restored pre-update state and is especially useful before a high-impact production push.

Retest sequence

1. Verify undo returned the lab to the expected original version.
2. Select Refresh Updates if the target is not currently visible.
3. Choose the same target and select Test in Lab.
4. Let QCUL capture/verify the package and create a new restore point.
5. Compare the new result/evidence to the first test.
6. Complete human review again before production.

Why retesting matters

A restore cycle exercises both forward and reverse paths and catches state-dependent failures. For Joomla core, the walkthrough explicitly recommends undoing and retesting before a live core push.

Package identity can still change

If Joomla/vendor metadata now resolves different package bytes, QCUL will capture/hash the new artifact and the production candidate becomes the newly tested exact package—not the old test by version name alone.

Preserve a known starting state

Retesting an Update After Undo Lab Update is useful only when the restore point and current laboratory belong to the same latest test operation. If you cannot prove that relationship, refresh the laboratory from current production and perform a new test rather than manually reconstructing a state and reusing old evidence.

Community Discussion

Want to compare update-testing workflows, share practical tips, or discuss how you use this QCUL feature? Visit the QC Update Laboratory Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.