SQCpack upgrades need reproducible calculation evidence
PQ Systems maintains separate SQCpack version 7 and version 8 release paths, release history, validation resources, and a way to identify the installed version. Quality teams should preserve the application build, configuration, formulas, data, limits, filters, output, exception, and approval needed to reproduce every relied-on control chart or capability study after an upgrade.
Editorial figure by Quality Systems Index. Source context: PQ Systems SQCpack latest releases.
Freeze the analytical context with each output
The direct answer is that a chart or study should retain enough context to be recalculated independently of the current workstation. Preserve SQCpack major, minor, and build version; licensed modules; workstation and database context; configuration and template versions; source data and import mapping; characteristic, units, subgroup method, sampling order, filters, exclusions, transformations, constants, control-limit method, specification limits, and generation time. The rendered report alone is not a reproducible analysis.
Specification limits, control limits, targets, and calculated statistics should remain distinct. A user-entered customer tolerance is not a statistically derived control limit, and a stable chart is not proof that a process meets specifications. If the application recalculates historical charts after opening them in a new version, store the original output and inputs before migration. Reviewers need to know whether a displayed difference came from new data, configuration, algorithm, rounding, display, or software behavior.
Translate release notes into impact tests
Release history should be reviewed against the organization's actual uses rather than accepted as a generic upgrade record. Classify changes affecting calculations, data storage, imports and exports, permissions, audit history, reports, graphics, integrations, database compatibility, performance, and defect correction. For each relevant item, document the affected intended use, risk, regression test, expected result, tester, discrepancy, resolution, and release authority.
Validation resources from the provider can support planning, but the site must establish its installed environment, configuration, data paths, procedures, roles, backups, and decisions. A vendor test cannot show that a locally customized template maps the right column or that an operator uses the correct subgroup rule. Conversely, a release note that does not mention a function is not proof that the function is unaffected; use risk-based testing and representative production conditions.
Reproduce trusted studies before cutover
Select a regression set containing stable and unstable processes, variable and attribute data, missing and out-of-order observations, small and large subgroups, manual exclusions, recalculated limits, imported specifications, and boundary values. Run the same frozen inputs and settings in the old and new versions. Compare intermediate values, limits, signals, capability statistics, labels, export files, and rounding against predefined tolerances rather than checking only that the charts look similar.
Any difference needs a disposition: expected documented change, corrected defect, configuration change, data conversion issue, unexplained variance, or test error. Record which historical conclusions require reassessment and which remain valid. Do not overwrite the old study or silently regenerate certificates and reports. Approved cutover should also include backup, rollback, access, training, support, and a period of heightened monitoring for data or calculation anomalies.
Test a study that changes after upgrade
A representative evaluation should migrate one process dataset from version 7 to version 8, include a custom import, stored limits, an excluded point, a capability calculation, and a report template. Change one default and introduce one out-of-sequence observation. Reviewers should reproduce the pre-upgrade and post-upgrade results, isolate every difference, verify audit and export behavior, resolve the discrepancy, and demonstrate rollback without losing the original analysis.
PQ Systems' official SQCpack page supports the attributed facts about maintained version 7 and 8 release paths, release history, version identification, user guides, and validation resources. It does not establish installed configuration, calculation correctness, data integrity, statistical appropriateness, process stability, capability, product conformity, validation, or release approval. Qualified quality, manufacturing, metrology, statistical, validation, information-technology, customer, regulatory, and legal owners retain their decisions.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Quality Systems Index will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.