Short answer
DAM integration testing is the test phase that proves assets, metadata and renditions move correctly between the DAM and every connected system at production volume. The DAMSelection test template holds 20 cases per integration, covering create, update, delete, rights expiry, rendition changes, error recovery and peak load. Run it before go-live and after every connector upgrade.
What DAM integration testing covers
DAM integration testing covers every data flow between the DAM and another system, in both directions. Typical flows connect the DAM to the PIM, CMS, commerce platform, creative tools, identity provider, CDN and marketing resource management.
Each flow carries four kinds of data: the file, the renditions, the metadata and the relationships. A product image flow, for example, carries the master file, channel renditions, rights fields and the link to a product SKU. A test that checks only the file misses the relationship that tells the storefront where the image belongs.
DAMSelection assessment: DAM and PIM form one product content supply chain, so the DAM to PIM flow deserves the deepest testing. The DAM integrations guide explains the integration patterns. The PIM and DAM Fit Map shows which connector type each combination uses.
Test levels and sequence
DAM integration testing runs in six levels, and each level must pass before the next starts. Skipping to volume tests with broken mappings wastes days on noise.
| Level | Purpose | Data | Typical duration (DAMSelection rule of thumb) |
|---|---|---|---|
| 1. Connection | Credentials, endpoints, network and sign-in work | One asset | 1 day |
| 2. Functional | Each event produces the right result in the target | Test set of 100 to 300 assets | 1 to 2 weeks |
| 3. Data fidelity | Metadata, rights and relationships arrive intact | Test set plus a migration sample | 1 week |
| 4. Failure and recovery | Errors are caught, retried and reported | Test set with forced failures | 3 to 5 days |
| 5. Volume and performance | Throughput and latency hold at peak load | Production-like volume | 1 week |
| 6. User acceptance | Business users confirm results in their own tools | Real tasks | 1 week |
ISO/IEC/IEEE 29119-1:2022 sets out the general concepts of software testing and gives a common vocabulary for test levels and completion criteria. Use its vocabulary in the test plan when the integration partner or IT department works to that standard.
DAM integration test case table
The DAM integration test case table lists 20 cases to run for every integration, with the expected result written before the test starts. Adapt the target system column to each flow and add cases for custom fields.
| ID | Scenario | Action in source | Expected result in target | Priority |
|---|---|---|---|---|
| IT-01 | Create | Upload and approve a new asset | Asset and required renditions appear in the target within the agreed time | Must |
| IT-02 | Metadata update | Change a mapped field value | Target shows the new value, unmapped fields stay unchanged | Must |
| IT-03 | New version | Replace the master file | Target shows the new version, links and placements stay intact | Must |
| IT-04 | Delete or archive | Archive the asset in the DAM | Target removes or hides the asset, no broken image on live pages | Must |
| IT-05 | Rights expiry | Let the rights end date pass | Target withdraws the asset on the expiry date | Must |
| IT-06 | Embargo | Set an embargo date in the future | Target receives nothing until the embargo lifts | Must |
| IT-07 | Rendition change | Change a rendition preset | Target receives regenerated renditions in the new size and format | Must |
| IT-08 | Product link | Link an asset to a SKU and set its role | PIM shows the asset on the right product, in the right position | Must |
| IT-09 | Product link removal | Remove the asset to SKU link | PIM removes the asset from that product only | Must |
| IT-10 | Embedded metadata | Upload a file with IPTC and XMP fields | Mapped embedded fields arrive in the DAM and survive into renditions where required | Should |
| IT-11 | Special characters | Use accents, umlauts and non-Latin script in names and fields | Characters arrive intact in every target | Must |
| IT-12 | Large file | Upload a video above 5 GB | Transfer completes or fails with a clear error, no silent truncation | Should |
| IT-13 | Permissions | Restrict an asset to one user group | Target respects the restriction or never receives the asset | Must |
| IT-14 | Duplicate event | Send the same event twice | Target holds one copy, no duplicate asset | Must |
| IT-15 | Target offline | Stop the target during a sync | Events queue and replay in order when the target returns | Must |
| IT-16 | Invalid data | Send a value the target rejects | Error is logged, alert sent, other events continue | Must |
| IT-17 | Partial batch failure | Fail 5 of 100 assets in a batch | 95 succeed, 5 land in the error queue with a reason | Must |
| IT-18 | Token expiry | Expire the integration credentials | Integration alerts within the agreed time, no silent stop | Must |
| IT-19 | User deprovisioning | Remove a user in the identity provider | DAM access ends within the agreed time | Must |
| IT-20 | Peak load | Push the peak-hour volume through the flow | Latency and error rate stay within agreed limits | Must |
Write the agreed time for each case in the test plan before testing. "Within the agreed time" without a number makes every result a pass. Record pass, fail and defect ID per case, per integration, per test cycle.
Prepare the test data set
DAM integration test data needs a deliberate mix of edge cases, because a random sample of clean assets passes tests that production will fail. Build the test set once and reuse it in every cycle and after every upgrade.
- Every file type in scope: JPEG, PNG, TIFF, PSD, PDF, MP4, MOV and design files.
- Files from the smallest to the largest expected size, including one video above 5 GB.
- Assets with full metadata, minimal metadata and empty optional fields.
- Assets with rights ending tomorrow, already expired and with no end date.
- Assets under embargo and assets restricted to one user group.
- Names and values in every language and script the business uses.
- Assets linked to one product, many products and no product.
- Files carrying embedded IPTC and XMP metadata, including rights fields.
The metadata mapping table defines the expected values for each field. Use it as the oracle for data fidelity tests.
Volume and performance testing
DAM volume testing proves the integration holds at the busiest hour of the year, which is usually a season launch, a catalogue drop or a migration batch. Average daily volume hides those peaks.
- Take the peak-hour asset count from last year's launch or from the migration plan.
- Multiply by a safety factor of 1.5 to 2 (DAMSelection rule of thumb).
- Push that volume through each flow in a production-like environment.
- Measure end-to-end latency per asset, error rate and queue depth.
- Check API rate limits on both sides and confirm the integration backs off without losing events.
- Repeat with two flows running at once, because shared API limits fail under combined load.
Worked example: a retailer launches 4,000 products with 6 images each in one evening. That is 24,000 assets. With a safety factor of 1.5, the test pushes 36,000 asset events through the DAM to PIM flow. The team then confirms the queue drains before the storefront goes live.
The DAM migration plan often creates the largest load the integrations ever see. Run integration tests before the migration batches start, so migrated assets reach connected systems correctly.
Error handling and recovery
DAM integration error handling decides whether a failure costs minutes or weeks. A silent failure leaves wrong or expired assets live until a customer notices.
Every integration needs four recovery features, and the tests prove each one:
- An error queue that holds failed events with the reason.
- Automatic retry with a limit, followed by an alert.
- Replay of queued events in the original order.
- Idempotent processing, so a repeated event produces one result.
Ask the vendor or integration partner to show each feature in the proof of concept where possible. A connector without an error queue needs a custom monitoring layer before go-live.
Monitoring before go-live
DAM integration monitoring must run before go-live, so the first production failure raises an alert. Set alert thresholds during volume testing, when the normal range is known.
| Signal | Alert threshold (example) | Recipient |
|---|---|---|
| Failed sync jobs | Any failure on rights expiry or delete events | IT and integration owner, legal |
| Error queue depth | Above the normal range for 30 minutes | IT and integration owner |
| End-to-end latency | Twice the tested median | IT and integration owner |
| Credential expiry | 14 days before expiry | IT and integration owner |
| Assets withdrawn by rights expiry | Daily summary | Legal and rights |
The thresholds are examples for a worked test plan. Set your own from the volume test results.
Entry and exit criteria
DAM integration testing needs written entry and exit criteria, so go-live depends on evidence. Entry criteria confirm the environment is ready. Exit criteria confirm the result is good enough.
- Entry: mappings signed off, test environment connected, test data loaded, test cases approved.
- Exit: all Must cases passed, no open critical or high defects, volume test passed at peak plus safety factor.
- Exit: monitoring and alerts live, runbook written, support owner named in the DAM RACI.
The exit criteria feed straight into the DAM go-live checklist, which treats a passed integration test as a technical readiness gate. The implementation pillar shows where integration sits in the four phases.
Frequently asked
How long does DAM integration testing take?
DAM integration testing takes 4 to 7 weeks per major integration across all six levels, from connection test to user acceptance (DAMSelection rule of thumb). Packaged connectors with few custom fields sit at the lower end. Custom integrations, multiple targets and complex product relationships sit at the upper end.
What should be tested in a DAM to PIM integration?
A DAM to PIM integration test covers asset creation, metadata updates, new versions, archiving, rights expiry, embargoes, rendition changes and the asset to SKU link with its role and position. Test link removal as well, because a removed link must affect only the product concerned.
Who is responsible for DAM integration testing?
The IT and integration owner is accountable for DAM integration testing. The integration partner or vendor runs the technical cases. The DAM manager supplies the test data and expected metadata. Business users in each connected system run user acceptance and confirm the results in their own tools.
What is volume testing in a DAM implementation?
Volume testing in a DAM implementation pushes the peak-hour asset load, multiplied by a safety factor, through each integration in a production-like environment. The test measures latency, error rate, queue depth and API rate limits, and confirms queues drain before the business deadline.
Do DAM integrations need retesting after go-live?
DAM integrations need retesting after every connector upgrade, platform release that touches the API, schema change in a mapped field and change in a connected system. Rerun the Must cases from the test set at minimum. Keep the test set and expected results under version control for that purpose.