Deze documentatie wordt actief uitgebreid — kom regelmatig terug.

ADR-00020: Test Data Handling Strategy

Approval Status

Status flow: Proposed → Accepted → Reviewed → Approved (or Rejected), or Not Required. A superseded ADR keeps its file; only its status changes to Superseded by NNNNN.

Governance body	Status	Last update
CTN Project Team	Proposed	2026-06-15
CTN Technical Advisory Board	Pending	—
CTN Steering Committee	Pending	—
BDI Conformance Team	Pending	—
BDI Framework Team	Pending	—

RdN: EB please chime in, what has been used earlier as test data?

Context and Problem Statement

As the CTN implementation and with it, the BDI (Basic Data Infrastructure) ecosystem grows, we need a consistent strategy for handling test and mock data across different environments. We currently have a mix of real-world company data (CTN) and various synthetic entries. Using real company data in development and early testing phases can lead to privacy concerns, confusion with actual production entities, and difficulty in remembering specific test cases.

Considered Options

Option 1: Use Real-world (CTN) Data Everywhere

Description: Use a copy of the actual CTN company list in all environments (Dev, Test, Acceptance).
Pros: Data is realistic and covers all production edge cases.
Cons: Privacy concerns; risk of accidental actions against real entities; hard to manage specific test scenarios.

Option 2: Use Fully Synthetic Data Everywhere

Description: Generate random or semi-random data for all environments.
Pros: No privacy risks; clean separation from production.
Cons: Might miss realistic data patterns; Acceptance testing feels “fake” to stakeholders.

Option 3: Tiered Approach: Actual Data for Acceptance, Synthetic Personae for Dev/Test (Chosen)

Description: Use a static set of actual CTN companies for the Acceptance environment, and a neutral, synthetic set based on memorable personae for Dev, Test, and BDI contexts.
Pros: Acceptance remains realistic; Dev/Test is safe, neutral, and easy to navigate using memorable names.
Cons: Requires maintaining two sets of test data.

Decision Outcome

Chosen option: Option 3: Tiered Approach.

Rationale

Business alignment: Acceptance environments need to demonstrate value to stakeholders using familiar real-world entities (CTN companies).
Technical considerations: Development and automated testing benefit from predictable, memorable data. Using personae with alliterative names (e.g., “Anneke the Admin” for “Company A”) makes it easier for developers and testers to communicate and remember specific scenarios.
Risk assessment: Reduces the risk of using PII (Personally Identifiable Information) in non-production environments while maintaining a high-fidelity environment for final acceptance.

Consequences

Positive: Clearer communication during development; safer handling of data; realistic final validation in Acceptance.
Negative: Overhead in maintaining the persona-based data set and ensuring it stays synchronized with schema changes.
Neutral: Shift in mindset for developers to think in terms of personae rather than random strings.

Implementation Plan

Phase 1: Define the standard set of alliterative personae and their associated companies/roles (e.g., Anneke the Admin, Barend the Buyer).
Phase 2: Update the dev-seed SQL scripts (onboarding-demo-data.sql) to use these new personae.
Phase 3: Establish a process for refreshing the Acceptance environment with a curated, static set of actual CTN companies.