How QCUL Automated Evidence Works
QCUL automated evidence records objective before/after signals around one exact update so the administrator has more than a simple “installer succeeded” message.
Evidence layers
| Layer | Examples |
|---|---|
| Package identity | Filename, byte size, SHA-256, selected target. |
| Version | Starting and resulting extension/Joomla version. |
| HTTP/routes | Frontend and administrator responses, redirects, blank/fatal output. |
| Page structure | Expected content/selector checks where configured by the evidence engine. |
| Browser | Console errors, failed resources, screenshots, viewport evidence where captured. |
| Files/database | Affected file hashes plus schema/table/index/data-scope differences. |
| Logs | New Joomla/PHP log entries appended during the operation. |
Compact UI, detailed report
The tested row stays concise. A clean result can show “No problems found”; detailed evidence lives in the per-update report. When QCUL detects a focused concern, the row exposes a View Problems/issue report so the administrator can investigate quickly.
Evidence supports—not replaces—review
Automated evidence is strongest at detecting technical breakage and documenting change scope. Human review remains responsible for business-critical workflows and site-specific expectations.
Read evidence in context
Use How QCUL Automated Evidence Works together with the other evidence for the same tested item. A version check, route check, log message, screenshot, or file/database diff is strongest when it agrees with the surrounding evidence and your own reproduction in the private laboratory; no single signal should be treated as universal compatibility proof.
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.