System Validation Flow
Go to Playbook Main Page
Prev: Implementation
Next: Launch
Go to Playbook Main Page
Next: Launch
System Validation and Acceptance#
Key Ideas
- System verification is a systematic approach that ensures that the system, with or without critical aspects, has been installed, operates and performs as intended.
- System verification is an umbrella term that encompasses all types of approaches to assuring systems are fit for use, which may also be known as commissioning and/or qualification.
- The system verification process flow consists of:
Planning of Verification Activities - >
Installation Verification (Did we install it right?) - >
Operational Verification (Does it work the way it should?) - >
Regression Testing (Did anything break after our latest change?) ->
Performance Verification (Can it consistently perform in real-life conditions?) ->
UAT (PQ) (Does the system meet the business needs?) ->
System Acceptance and Release - Align on and adhere to branching, review, release, and other SDLC strategies; stick to best practices.
- End-to-End Testing - Rigorously test integrations across different environments to ensure correct functionality..Validate the entire integration flow from source to MDM and back to connected systems.Test integrations using a representative sample of real-world master data to simulate actual scenarios.Revalidate integrations whenever updates are made to the MDM platform or connected systems.
- TIMS (HP ALM) s the testing tool used to manage requirements, test scripts, test execution, deviations/defects, test reporting, audit trails, and requirement traceability.
- Leapwork is the automation testing tool used in MDM projects.
Roles Involved#
- Accountable:
- Product Owner
- Data Governance Lead
- Responsible:
- Validation/Test Engineers
- Data Steward
- Consulted:
- Data Engineer
- Business Analyst
1. Input#
All resources and components needed to begin validation.
| Category | Input |
|---|---|
| Build Artifacts | - Configured ingestion and publish pipelines -Configured MDM Hub (base objects, match/merge, rules) - Workflows and APIs - Integration jobs |
| Test Plans and Scenarios | - Test cases (functional,non functional data quality, performance) - UAT scenarios |
| Test Data Sets | Source system records - Cleansed/uncleansed data - mastered records - Publish records - Regression test bed |
| Business Requirements | - URS, FS, STTM - Data governance rules - Security and access control specs |
| User Roles and Environment | - Test user accounts - QA/UAT environment - Simulated production config - Access to TIMS - Access to Leapwork |
2. Process#
Activities that validate the system’s correctness, performance, and business readiness.
| Step | Description | Know More |
|---|---|---|
| Installation Validation | - Verify that MDM software and dependent components are installed correctly in the target environment | Installation-Verification |
| Operational Validation/Functional Testing | - Validate data flows as per STTM, match/merge rules, survivorship logic, workflows - Check cleansing, standardization, duplicate resolution via CDQ |
Operational-Verification |
| Regression Testing | - Validate scalability of match jobs, ingestion volume, response times | Regression-Testing |
| Integration Testing | - Verify CAI/CDI/CDQ jobs, APIs, Events publish, Mulesoft MAP ,and downstream data flows | Integration-testing |
| Product Validation/Acceptance Testing (UAT) | - Business users test against real-world scenarios | UAT |
| Performance Validation/Performance and Load Testing | - Validate scalability of match jobs, ingestion volume, response times | Performance-Verification |
| Security Testing | - Role-based access validation, data access boundaries | Security-Testing |
| Issue Logging and Resolution | - Log defects, track resolution, retest until all critical issues are closed | Defect-logging |
| Test Reporting | - Daily reports, defect summaries, exit criteria tracking | Test-Reports |
3. Output#
Results and documents that confirm readiness for deployment.
| Output | Description | Templates |
|---|---|---|
| Test Results and Logs | - Pass/fail status of all test cases, open defects and deviations - Match accuracy and data quality scores |
Test-Report-Template |
| Defect Logs | - List of identified bugs, including severity level and resolution status | Test-Reports |
| Validation Summary Report | - Coverage of tests, key findings, risk areas | |
| UAT Sign-Off | - Formal approval from business stakeholders | |
| Verified Access Controls | - Validated user role permissions and stewardship actions | |
| Performance Metrics | - Record counts, job timings, system throughput results | |
| Deployment Readiness Checklist | - Go/No-Go decision determined based on validation outcomes and success criteria |
What happens next?#
After validation, the MDM solution officially launches — moving from dry-run to daily business impact, with live data, live decisions, and full governance in motion.
- Go/No-Go Decision Meeting All stakeholders (IT, business, compliance, data governance) review validation outcomes, sign-offs, and readiness checklists — and give the final green light.
- Production Environment Cutover: MDM configurations, validated workflows, and approved data are promoted to the live environment. Integration points (e.g., APIs, Kafka events, consuming apps) are activated.
- Stewardship Goes Live: Data stewards start managing real requests — adds, updates, merges — using live workflows and dashboards. Approvals now have real-world impact!
- Communication and Enablement: Users are notified, business teams are trained, and reference materials (quick guides, SOPs, FAQs) are shared. The launch is socialized across teams.
- Monitoring and Early Support: DQ rules, audit trails, and usage logs start populating. A hypercare or post-launch support team monitors for issues and resolves them fast.
Go up- System Validation and Acceptance
Go to Playbook Main Page
Next: Launch
Installation Verification (IV)#
Installation Verification (IV) is the documented confirmation that the system, as installed or modified, complies with the approved design specifications.
Components Covered#
| Layer | Component |
|---|---|
| Infrastructure | OS, servers, databases, file systems |
| Software | Informatica MDM, Informatica CDI/IICS, DB clients |
| Configuration | Environment variables, connectivity, ports |
| Licensing | License keys, expiration checks |
For Informatica IDMC (Intelligent Data Management Cloud) — a cloud-native platform — IQ looks a bit different than on-premises systems, because the infrastructure is managed by Informatica, not by your internal IT.IQ in IDMC refers to verifying and documenting that: The cloud environment (IDMC) is correctly provisioned, All required services (CDI, DQ, RDM, CAI, etc.) are enabled, The platform is configured per vendor and project specifications, The environment is deployed in a qualified state, ready for operational qualification (OQ).
Test Examples#
- Verify MDM Server & Hub Console installation(in case of on prem)
- Validate DB schema creation (in case of on prem)
- Check if required services are running
- Test connectivity from CDI to MDM
Operational Verification (OV)#
Operational Verification (OV) is the documented confirmation that the system, as installed or modified, operates as intended across the anticipated operating ranges. It ensures that all modules and services perform correctly under controlled test conditions.
Components Covered#
| Layer | Component |
|---|---|
| Core MDM | Landing, Staging, Base Object, Match/Merge, Trust |
| Data Quality | Parsing, cleansing, validation |
| Ingestion | Source ingestion via CDI, batch jobs |
| Workflow | Taskflows, approvals (if enabled) |
Test Examples#
- Run a job that loads customer data and verifies expected match and merge behavior
- Test data quality rule application (e.g., email format)
- Ensure trust rules apply as configured
- Validate record lifecycle (landing → golden record)
Product Verification (PV)#
Product verification (PV) is the documented confirmation that the system can perform effectively and reproducibly in accordance with the approved process methods and product specifications. This verification is typically carried out by Data Stewards and Business users.
Performance Verification (PfV)#
Performance verification (PfV) is the process of validating that the system meets defined non-functional requirements, such as volume handling, processing speed, and concurrency.
Components Covered#
| Layer | Component |
|---|---|
| Scalability | Match/Merge logic validated on datasets containing millions of records |
| Throughput | Batch ingestion jobs |
| Response Time | API calls, hub search |
| Resource Usage | CPU, memory, database load |
Test Examples#
- Load 1 million records and validate job runtime < target SLA
- Match 100,000 records with acceptable latency
- Concurrent ingestion and search without timeouts
Regression Testing#
Ensure that existing functionality remains intact and performs as expected following enhancements or patches.
Components Covered#
| Area | Examples |
|---|---|
| Match & Merge Rules | Are previous match rules still working? |
| Trust & Survivorship | Is data correctly surviving across sources? |
| Workflows / Approvals | Custom workflows remain unaffected |
| API Contracts | JSON/XML response structure is consistent |
| Data Quality Rules | Existing parsing or cleansing logic holds |
Test Examples#
- Re-run use cases from OQ
- Verify golden records still have correct survivor fields
- Run older API clients against upgraded MDM
The final step in the system verification process is system acceptance and release, which evaluates whether the system is qualified and fit for its intended use.
Integration Testing#
Integration testing in a Master Data Management (MDM) solution validates the seamless data flow between the MDM system and upstream and downstream systems, ensuring data consistency, accuracy, and compliance. It plays a critical role in identifying issues related to data quality, synchronization, transformations, and error handling.
Key Ideas#
1. Align Testing with Business Rules
- Ensure match/merge logic, data validation rules, and survivorship rules align with business requirements.
- Avoid deviations from pre-defined business rules, as they can lead to incorrect golden records and data conflicts.
2. Maintain a Dedicated Test Environment
- Set up an isolated environment replicating production for testing with controlled data.
- Mask or anonymize sensitive test data to ensure compliance.
3. Validate Across Systems
- Test end-to-end workflows across all dependent systems (e.g., sources, MDM, consuming applications).
- Ensure testing does not stop at the boundaries of the MDM . Validate upstream ingestion and downstream publishing.
4. Monitor Data Lineage
- Trace the flow of data from source to target to validate transformations and lineage transparency.
- Use source-to-target mappings to avoid mismatches or misalignments across systems.
5. Enforce Error Logging and Root Cause Analysis
- Ensure error scenarios are captured in detailed logs and routed appropriately.
- Do not suppress errors silently; raise alerts for every failed record or integration point.
6. Ensure Test Coverage for Each Domain
- Validate all domains (e.g., customers, products, employee) based on their unique business rules and scenarios.
- Avoid generalizing one domain's tests for others; each domain has distinct matching and governance requirements.
7. Test for Scalability and High Availability
- Validate the system can handle large amounts of data and remain operational during maintenance or node failures.
- Stress test large batch jobs and real-time pipelines to identify bottlenecks.
8. Validate Change Data Capture (CDC) - Test incremental data updates and ensure only modified/new records are pulled or pushed during integrations.
9. Standardize API Contracts
- Define clear data exchange formats and API contracts between systems, and validate adherence during the test.
- Never allow breaking changes in APIs without backward compatibility or proper downstream impact analysis.
10. Schedule Regression Tests Post-Change
- Any system configuration change (e.g., survivorship rule updates) should trigger revalidation of end-to-end integration workflows.
- Always validate full systems after rule, API, or schema changes.
Test Report Template#
1. Header Information#
| Field | Description |
|---|---|
| Project Name | Master Data Management System |
| System Name | Informatica MDM SaaS / IDMC |
| Version | v1.0 |
| Report Type | IQ / OQ / PQ / Regression |
| Prepared By | |
| Date of Execution | YYYY-MM-DD |
| Environment | QA / UAT |
2. Test Summary#
| Field | Description |
|---|---|
| Objective | Brief summary of what this test report covers (e.g., Validate Customer Match/Merge configuration) |
| Scope | Functions, modules, and components tested |
| Exclusions | Items not covered in this test cycle |
| References | Test Plan ID, FS Document IDs, Risk Assessment references |
3. Test Execution Summary#
| Test Case ID | Description | Status (Pass/Fail) | Tester Initials | Execution Date | Comments |
|---|---|---|---|---|---|
| TC-OQ-001 | Load customer records into Staging | Pass | 2025-05-22 | N/A | |
| TC-OQ-002 | Verify Trust rules for email field | Pass | 2025-05-22 | N/A | |
| TC-PQ-003 | Batch load performance for 1M records | Fail | 2025-05-22 | Exceeded SLA by 15% | |
| TC-REG-010 | API response format check | Pass | 2025-05-22 | - |
4. Open Defects and Deviations#
| Defect ID | Severity | Description | Status |
|---|---|---|---|
| 2351 | High | Merge logic not applied to duplicate contacts | Closed |
| 2392 | Medium | Phone number is not standardized | Open |
5. Metrics Summary#
| Metric | Value |
|---|---|
| Total Test Cases | 40 |
| Passed | 37 |
| Failed | 3 |
| Severity 1 Defects | 1 |
| Retests Required | 2 |
| Execution Coverage | 95% |
6. Approval & Sign-off#
| Name /Initials | Role | Signature | Date |
|---|---|---|---|
| QA Analyst | [signed] | 2025-05-20 | |
| MDM Lead | [signed] | 2025-05-20 | |
| Product Owner | [signed] | 2025-05-20 |