Why Unrelated Production Drift Does Not Automatically Invalidate a Test

QCUL 1.01.14 intentionally avoids treating every unrelated live-site difference as a reason to throw away a completed test.

Why broad drift alone is not enough

Real Joomla sites keep changing while an administrator reviews a laboratory: content editors publish articles, users submit data, cache/log files change, and unrelated extensions can update. Invalidating the exact-package test for every unrelated difference would make the workflow impractical and would not necessarily improve safety.

What QCUL still enforces

• Expected starting version for the selected target.
• Exact tested package identity/hash.
• Correct production site/root.
• Permissions and operation locks.
• Storage/environment readiness.
• Human lab review.
• Production-protection selection.

Administrator judgment

If an unrelated production change could interact with the selected update—for example a new template override or extension integration—you can still choose to refresh/retest. “Not automatically invalidated” does not mean “ignore meaningful context.”

Production change rule

For Why Unrelated Production Drift Does Not Automatically Invalidate a Test, the live site should change only through the explicit tested-item production workflow after current readiness checks pass. Do not substitute a new package, skip the review/protection decision, or run a second production action while QCUL already owns an active push/rollback state.

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.