Understanding Updates Already Installed in the Laboratory

“Already installed in lab” appears when the laboratory version already meets or exceeds the currently offered target, so another Test in Lab action would not represent a clean starting transition.

How this can happen

• You previously tested the update and the lab still contains the updated version.
• An administrator manually changed the laboratory outside QCUL.
• A cumulative sequence of tests moved the lab beyond the production starting state.

Choose the correct reset path

If the update was the latest QCUL test and a valid lab restore point exists, use Undo Lab Update. If the lab has accumulated unrelated changes or no trustworthy restore point remains, use Refresh Laboratory to create a fresh production-derived copy.

Why QCUL does not reinstall blindly

A same-version reinstall would blur file/database evidence and undermine the clear “starting version → exact package → resulting version” chain used for later production readiness.

Keep the evidence chain intact

The value of Understanding Updates Already Installed in the Laboratory depends on preserving one traceable transition: known starting version, one selected update, exact captured package/hash, resulting laboratory version, automated evidence, and human review. Avoid manual package installs or unrelated lab changes that make that chain ambiguous before a production decision.

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.