CompTIA Data+ DA0-002 · Free study guide

Objective 5.4 — Compare data quality assurance practices

Data quality assurance is the repeatable system that prevents, detects, explains, and corrects untrustworthy data. A one-time cleanup is not assurance. Sources change, code changes, volumes grow, and once-valid assumptions drift.

Requirement testing

Requirement testing verifies that a data product satisfies documented business and technical expectations. Requirements should be measurable: “the report includes every approved region,” “currency is shown in USD using the month-end rate,” or “the daily load completes before 7:00 a.m.”

A test cannot prove a vague statement such as “the dashboard is fast and accurate.” Define acceptance criteria, source controls, tolerances, owners, and expected behavior for missing or late data. Trace tests back to requirements so a change in policy triggers the right review.

Unit testing

A unit test checks a small piece of transformation or calculation logic in isolation using controlled inputs and expected outputs. A revenue function can be tested with a normal sale, a refund, a null discount, a zero quantity, and a boundary date.

Good unit tests include ordinary cases, boundaries, invalid inputs, and known defects. They should be deterministic and quick enough to run whenever code changes.

User-acceptance testing

User-acceptance testing, or UAT, asks representative business users to confirm that the delivered product supports the real workflow and decision. Users validate terminology, navigation, calculations, filters, permissions, and practical usefulness against agreed acceptance criteria.

UAT is not an unstructured demonstration where a senior stakeholder says the colors look good. Record scenarios, expected results, participants, defects, decisions, and formal acceptance. Technical teams may know that a query is correct while business users recognize that “active customer” was defined incorrectly.

Stress testing

A stress test evaluates behavior under high or extreme load: larger data volume, more concurrent users, slower dependencies, limited memory, or rapid event arrival. It finds breaking points, degraded response, timeout behavior, and recovery problems.

Stress testing differs from ordinary performance testing because it intentionally approaches or exceeds expected capacity. Protect production data and services by using an appropriate test environment and representative synthetic or masked data. A test that uses a tiny sample cannot demonstrate that a full-scale dashboard will refresh on time.

Source control and reproducible changes

Source control records versions of transformation code, queries, tests, configuration, schemas, and documentation. A useful commit links a change to its reason and reviewer. Branching and review allow proposed changes to be tested before release, while tags or releases identify what ran in a particular version.

Reproducibility also requires environment and dependency versions, parameters, source-data version or snapshot, and execution metadata. Code alone cannot reproduce a report if the underlying data and configuration have changed invisibly.

Store secrets in approved secret management, not in source control.

Data health checks

A data health check evaluates whether a current data set or pipeline is fit to use. Common checks include freshness, row count, schema, null rate, uniqueness, referential integrity, ranges, category sets, distribution, and reconciliation to a source total.

Health checks should distinguish warning from failure. A slight row-count change may be expected; a missing required partition may require quarantine. Record actual value, threshold, time, affected asset, and response.

Drift detection

Data drift is a change in the statistical properties or composition of incoming data. A model trained on urban customers may receive a growing rural population; average order value, category mix, missingness, or feature ranges may shift.

Drift is a signal to investigate, not proof of a defect. Seasonality, a campaign, or market expansion may explain it, so compare with an appropriate baseline.

Schema drift changes structure, such as a renamed field or new type. Data drift changes values or distributions. Both can break downstream assumptions and require monitoring.

Automated monitoring and profiling

Data profiling measures structure and content: types, counts, distinct values, nulls, ranges, patterns, and distributions. An initial profile establishes a baseline; recurring profiles reveal change.

Automated data quality monitoring runs checks on a schedule or event, records results, and alerts accountable owners. Effective alerts identify the failed rule, severity, evidence, affected consumers, and runbook. Monitoring should integrate with quarantine or fail-closed behavior when publishing bad data would cause material harm.

Thresholds need calibration. Limits that are too loose miss defects; limits that are too tight create alert fatigue. Review false positives, missed incidents, and changing seasonal baselines.

Quality metrics

Quality metrics make expectations measurable.

Every metric needs a denominator, scope, threshold, owner, and response. “99% complete” can conceal that the missing 1% contains all records from one important customer group. Track quality by critical segment as well as overall.

ISO-aligned practices

The International Organization for Standardization, or ISO, publishes standards that organizations can use to structure quality, security, service, and data-management practices. ISO-aligned work emphasizes documented responsibilities, controlled processes, evidence, risk-based thinking, corrective action, and continuous improvement.

Alignment does not automatically mean certification, and certification to one standard does not prove every data set is accurate. In an exam scenario, ISO points toward a systematic, documented, auditable quality practice rather than an ad hoc cleanup.

Scenario: a failing inventory dashboard

After a release, inventory totals drop 30%, one region disappears, refresh time doubles, and users report that a filter returns inconsistent results.

Source control identifies the deployed query and schema change. Unit tests exercise the filter and aggregation boundaries. Requirement tests verify all regions, the approved inventory definition, and refresh target. Source, landing, model, and report health checks compare row counts and totals to locate the loss. Profiling reveals whether category or null distributions changed, while drift analysis distinguishes a real business shift from pipeline damage. A representative full-volume stress test investigates the slower refresh. Business users repeat documented UAT scenarios before acceptance. Monitoring keeps the new checks active, and corrective-action records support an ISO-aligned improvement process.

Exam traps

• Using vague requirements that cannot produce pass or fail evidence.
• Treating unit tests as proof that the end-to-end source is complete.
• Calling an informal demo UAT.
• Stress testing with an unrepresentatively small data set.
• Versioning code while ignoring data, configuration, and dependencies.
• Storing secrets in source control for reproducibility.
• Treating every drift alert as corrupt data.
• Confusing schema drift with a distribution change.
• Building alerts without an owner, severity, or response runbook.
• Reporting one overall quality percentage that hides a failed segment.
• Claiming ISO alignment or certification guarantees accurate data.

Readiness checklist

• I can distinguish requirement, unit, UAT, and stress testing.
• I can write measurable acceptance criteria and controlled unit cases.
• I can explain what source control must capture for reproducibility.
• I can identify freshness, volume, schema, null, key, range, and reconciliation health checks.
• I can distinguish data drift from schema drift and investigate expected changes.
• I can connect profiling baselines to automated monitoring and alerts.
• I can define completeness, accuracy, validity, consistency, uniqueness, and timeliness metrics.
• I can include scope, denominator, threshold, owner, and response for a quality metric.
• I can explain ISO-aligned quality as a documented improvement system, not a guarantee.