Quality Assurance Testing

This topic is part of the SG Systems Global regulatory & operations glossary.

Updated December 2025 • System & Product Verification • QA, QC, Validation, IT, Operations

Quality Assurance testing is the structured verification work that demonstrates your quality system, processes, and tools are fit for purpose—not just that individual batches pass QC. It spans process-level testing (e.g., cleaning validation, line clearance checks), system-level testing (e.g., computer system validation for QMS/MES/WMS/LIMS/ERP), and workflow testing that proves SOPs, forms, and electronic workflows behave as QA expects. It overlaps with QC and validation but is ultimately aimed at answering a single question: “Can we trust this QA-controlled process or system to protect quality every day?”

“QA testing doesn’t just ask ‘does this sample pass?’—it asks ‘does our system make it hard to fail without noticing?’”

1) What Quality Assurance Testing Covers—and What It Does Not

Covers (examples):

• Testing QMS workflows for deviations / NC, CAPA, change control, and document approval.
• CSV-style testing of electronic systems (QMS/MES/WMS/LIMS/ERP) that underpin QA and batch records.
• Process simulations (e.g., mock recalls, mock inspections, mock batch releases) to test readiness.
• Verification of rule sets and configurations (e-signature rules, access controls, QA status logic, label controls).
• Testing updates to SOPs, forms, and checklists to ensure they work in context before go-live.

Does not only cover: routine product QC testing (assay, sterility, dimensions) or development-only “software QA” in isolation. Those are inputs; QA testing pulls them into a wider check that the whole quality system behaves as designed.

2) QA Testing vs QC Testing vs Validation

These terms are often mixed, so a clear contrast helps:

• QC testing: tests samples of product or materials against specifications; typically lab or in-process tests.
• Validation (process/cleaning/CSV): planned study work (protocols & reports) that demonstrates a process or system can consistently deliver intended results under defined conditions.
• Quality Assurance testing: blends both—using test cases and mock workflows to verify that QA-controlled processes and systems (QMS, MES, WMS, release flows, exception handling) are correctly configured, integrated, and used.

In practice, QA testing leans heavily on validation practices but focuses on QA workflows and decision logic, not just equipment or software alone.

3) Where QA Testing Lives in the QA System

Quality Assurance testing shows up in several places inside your QA Systems:

• Before go-live: as part of system introduction (new QMS/MES/WMS/LIMS, new QA workflows, major process changes).
• After changes: as part of Change Control (MOC) to verify changed logic and integrations.
• Periodically: as part of internal audits and data integrity reviews (e.g., testing search, filtering, or audit-trail behavior).
• During incident response: verifying bug fixes and CAPA on QA-related systems and procedures.

It should be explicitly referenced in QMS/CSV/SOP documents, not left as “informal testing” that nobody can reconstruct in an audit.

4) Examples of Quality Assurance Testing Activities

Concrete examples in a regulated plant include:

• Creating a test CAPA in the QMS and verifying routing, approvals, mandatory fields, and e-signatures.
• Simulating a deviation raised from MES and verifying automatic batch hold, QA notification, and correct QMS record linkage.
• Testing WMS logic for “QA hold” status: materials on hold must not be issued to production or shipped, regardless of user or location.
• Running a mock recall using batch/UDI data, WMS movements, and eDHR/eBR to ensure rapid traceability.
• Testing that access roles prevent untrained users from performing QA-critical actions (e.g., batch release, deviation approval).
• Validating that audit trails capture and display all critical field changes in QMS, MES, and WMS according to Data Integrity expectations.

These are QA-owned tests, even if IT or operations executes the clicks under QA’s protocol and oversight.

5) Test Design – Risk-Based QA Testing

Like everything else in QA, QA testing should be risk-based:

• Focus test design on high-risk workflows (batch release, labeling, NC/CAPA, change control, supplier approval, logins and e-signatures).
• Use Risk Matrices and risk registers to prioritize scenarios and edge cases.
• Design “negative” tests (e.g., missing required data, invalid user, out-of-spec condition) to show the system fails safely.
• Include integration tests (QMS ↔ MES ↔ WMS ↔ LIMS ↔ ERP) where decisions or records cross system boundaries.

Testing only the happy path is how you end up with “validated” systems that fail on the first real deviation or recall exercise.

6) QA Testing & Data Integrity

Quality Assurance testing plays a big role in verifying ALCOA(+) in digital systems:

• Testing that time, user, and reason-for-change fields are captured on critical operations.
• Verifying that audit trails record original and changed values and cannot be altered.
• Checking that filtered views, exports, and reports are accurate and complete.
• Ensuring backup/restore and archival processes maintain integrity of QA-critical data.

These tests are often documented under CSV / Annex 11 / Part 11 validation, but they are fundamentally QA tests—because QA will rely on this data in deviations, CAPA, release, and audits.

7) Documentation of Quality Assurance Testing

To be defendable in audits, QA testing should follow a structured pattern:

• Plan / protocol: scope, objectives, test cases, acceptance criteria, roles, and environments.
• Execution records: test case results, screenshots, logs, defect reports, and deviations raised during testing.
• Summary / report: pass/fail status, open issues, and justification for go/no-go decisions.
• Traceability: mapping from requirements (SOP/URS/risk controls) to test cases and outcomes.

Ad-hoc, undocumented “we tested it” is useless in regulated QA: if it’s not in a protocol/report or captured in your eQMS, it didn’t happen.

8) Common Weaknesses in QA Testing

• Confusing QC and QA testing. Calling routine lab tests “QA testing” while ignoring system and workflow verification.
• Relying only on vendors. Accepting vendor “test evidence” without site-level, intended-use QA testing.
• Happy-path only. No testing of exceptions, failures, or cross-system data breaks.
• No integration scope. Testing QMS, MES, WMS, or LIMS independently but never verifying how they work together.
• Weak documentation. Test activities not formally planned, executed, and summarized under QA oversight.
• No linkage to risk and CAPA. QA testing not updated when risks, CAPA, or regulatory expectations change.

These are exactly the gaps regulators and customer auditors push on when they probe CSV, data integrity, and readiness for recalls or serious incidents.

9) How Quality Assurance Testing Fits with V5 by SG Systems Global

QMS workflow testing in V5 QMS. The V5 Quality Management System (QMS) module provides configurable workflows for documents, training, deviations, CAPA, change control, audits, and risk. QA testing uses these workflows in a controlled test environment to prove that routing, approvals, mandatory fields, e-signatures, and permissions behave exactly as defined in SOPs and validation protocols.

Process and eDHR/eBR testing in V5 MES. With the V5 MES, QA can design test batches or “dummy” work orders to verify that updated recipes, in-process checks, exception handling, and batch status behavior match requirements. Quality Assurance testing verifies that deviations, holds, and sign-offs flow into structured eDHR/eBR records for QA review.

Inventory- and status-based testing in V5 WMS. In the V5 WMS, QA testing focuses on status logic and traceability: confirming that QA holds from QMS/MES really block issue and shipment, that lot/UDI scanning is enforced where required, and that kitting rules prevent incompatible or expired materials from being used.

End-to-end QA test scenarios in the V5 Solution Overview. Using the full V5 Solution Overview, QA testing can execute end-to-end scenarios—new SOP rollout, batch with deviation → CAPA → change control → updated routes and labels → successful batch and release—that touch QMS, MES, WMS, and integrated LIMS/ERP. These integrated tests generate audit-ready evidence that the quality system works as a whole, not just as isolated modules.

Test automation & analytics via V5 Connect API. With the V5 Connect API, organizations can integrate V5 with automated test frameworks, pull real-time logs for QA test evidence, and analyze how often workflows are updated, how quickly defects found in QA testing are resolved, and how QA testing correlates with lower deviation/CAPA rates in production.

Bottom line: V5 gives QA a practical platform to design, execute, document, and leverage Quality Assurance testing across QMS, MES, and WMS—so you can prove that the system preventing defects is at least as well-tested as the products themselves.

10) FAQ

Q1. How is Quality Assurance testing different from routine QC testing?
QC testing checks samples of product or materials against specifications. Quality Assurance testing checks that the systems, workflows, and tools around those tests—QMS, MES, WMS, approval flows, exception handling—work correctly and reliably to prevent and control quality issues.

Q2. Is QA testing the same as computer system validation (CSV)?
Not exactly. CSV focuses on demonstrating that computerized systems meet their intended use and regulatory requirements. QA testing uses CSV methods but has a broader focus on QA workflows and cross-system behavior (e.g., how deviations, CAPA, and release decisions move across QMS, MES, and WMS).

Q3. Who is responsible for Quality Assurance testing?
The Quality Unit (QA) is accountable for defining and approving QA testing, including test scope, protocols, and acceptance criteria. IT, operations, and system owners often help execute test scripts, but QA owns the decision on whether the system or workflow is acceptable for use.

Q4. Does every change require full QA testing?
No. QA testing should be risk-based. Minor, low-risk changes may need only targeted checks; high-risk changes (e.g., release logic, deviations/CAPA workflows, label/UDI rules, audit trail functions) normally require more extensive QA testing and documentation under change control.

Q5. How do we document QA testing in a way regulators will accept?
Use validation-style documentation: requirements or user stories mapped to test cases, written protocols with pre-defined acceptance criteria, executed test records (with evidence), and summary reports that justify go/no-go decisions. Store all of this under document control in your QMS or validation repository.

Q6. How do digital platforms like V5 help with Quality Assurance testing?
V5 provides configurable QA workflows in QMS, realistic test environments in MES and WMS, and APIs for integration and analytics. QA can design and run test scenarios directly in V5, capture evidence (e.g., screenshots, logs, eDHR/eBR excerpts), and link test results to change control and validation records—making QA testing much easier to execute and defend.

Related Reading
• QA & QMS: Quality Assurance Process | QA Systems | Quality Management System (QMS)
• Validation & Risk: Computer System Validation (CSV) | Risk Management (QRM) | Risk Matrix
• Events & Data: Deviation / Nonconformance (NC) | CAPA – Corrective & Preventive Action | Data Integrity | Audit Trail (GxP)
• V5 Platform: V5 Solution Overview | V5 QMS | V5 MES | V5 WMS | V5 Connect API