Testing One Update at a Time

QCUL 1.01.14 deliberately tests one update at a time so the evidence, restore point, human review, exact package, and eventual production decision belong to one specific change.

Why single-update testing is safer

• File/database changes can be attributed to one selected package.
• Undo Lab Update has a clear latest-operation restore point.
• A production push can require the exact starting version and package identity for that item.
• A failed/warning result is easier to investigate without unrelated package changes in the same test.
• Reports remain understandable months later.

Do not batch by hand

Installing multiple updates manually inside the lab defeats the current QCUL contract. If several updates are required, test them deliberately in sequence and understand that cumulative lab state changes matter; refresh when you need a clean production-derived starting point.

Joomla core deserves extra isolation

Because core updates affect a broad surface, use Undo Lab Update and retest the same core package before production when possible. That exercises the lab restore path and confirms the production candidate is based on the intended current lab state.

Keep the evidence chain intact

The value of Testing One Update at a Time 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.