A Singapore Government Agency Website
How to identify
Auto-generate test cases from data contracts. Validate faster, ship with confidence.
View product linkDirect users: 50-100 staff in HPB’s CDOO and CIOO divisions who generate, review, and run data validation test cases. Within this group, the favoured user class — those bearing the heaviest manual workload — are 30–60 Data Engineers and QA/Data Quality Analysts.
These staff need to validate underlying datasets before releasing dashboards, reports, and data products, where data quality and reliability are critical. To do so, they manually create and run test cases by cross-referencing disparate artefacts such as data dictionaries, profiling outputs, and validation rules.
This challenge recurs at multiple points in the data lifecycle: during data source onboarding, when data schemas or business rules change, and at every pre-release quality check before downstream consumption.
The core issue is that validation logic is fragmented across multiple documents and not standardised within a single workflow. During each release cycle, staff must manually translate these scattered artefacts into test cases — cross-referencing documents, reinterpreting rules, and updating tests whenever sources or business rules change. This drives rework and inconsistent test coverage. Compounding this, even small upstream data changes can trigger significant downstream disruptions, leading to repeated cycles of root cause analysis, cross-team communication, and remediation.
If unresolved, HPB risks spending up to 4,000 man-hours per month on manual data checks and test-case generation — estimated at 25% of 160 working hours across 100 staff — diverting capacity away from higher-value work such as pipeline engineering, analytics and model development, dashboard delivery, and stakeholder support.
Beyond staff capacity, inconsistent or inaccurate data outputs risk undermining critical operational functions at HPB, including programme resource allocation, public health trend analysis, and evidence-based policy recommendations. A single data quality failure propagating to a downstream dashboard, for instance, could affect decisions that have real impact on health promotion programmes and the populations they serve.
What user research methods did you adopt to validate that this solution is needed and what were the key insights from real users?
User research was conducted through an internal pilot with 10 staff from HPB's CDOO and CIOO — data engineers and data quality analysts who are directly responsible for maintaining data accuracy, completeness, and reliability.
Participants were observed during a live release cycle task in which they reviewed data dictionaries, profiling outputs, and validation rules, then manually created test cases for pre-release validation. Observations were supplemented with informal feedback discussions and retrospective sharing sessions after the task.
Four key insights emerged:
What market risks are there and how did you mitigate them?
Three market risks were identified:
Adoption risk: Staff may perceive the tool as replacing their professional judgement rather than supporting it, leading to low uptake or disengagement. Mitigation: To address this, the solution is designed to be assistive — users retain full control to review, modify, and approve all outputs before use.
Accuracy risk: Users may not entirely trust the generated outputs to fully capture complex or context-dependent business rules. Mitigation: Generated test cases were validated against existing test suites and historical datasets during the pilot, and iterated based on user feedback.
Integration risk: The solution may not align cleanly with existing validation workflows and tooling. Mitigation: The solution was designed to fit within existing pre-release validation workflows and is being scoped for compatibility with CI/CD pipelines used by CDOO and CIOO teams.
Which agencies or departments did you reach out to and did they express interest or commitment?
Engagement has been focused on data engineers and data quality analysts within HPB's CDOO and CIOO, who are the primary users of the solution. These staff expressed strong interest in reducing manual effort and improving test coverage, particularly around edge cases and negative scenarios that are currently deprioritised due to time constraints.
Preliminary discussions with HPB data governance stakeholders indicated alignment with organisational priorities around data standardisation and quality assurance. There is expressed interest in expanding the solution to additional teams, subject to demonstrated improvements in efficiency and output reliability. Formal commitment is pending the outcomes of the current pilot phase.
How does your product specifically address the pain points identified?
The solution addresses the identified pain points through a two-stage AI-assisted workflow: first generating a structured data contract from existing documentation and datasets, then using that contract as the authoritative basis for test case generation.
This approach directly tackles the core problem of staff spending significant time manually interpreting fragmented artefacts. By automatically synthesising data dictionaries, profiling outputs, and validation rules into a single data contract, the solution eliminates the need for manual cross-referencing and reinterpretation. The data contract then serves as a standardised, shared source of truth from which test cases are generated consistently — addressing the uneven coverage that previously resulted from individuals creating test plans independently, without a common template or workflow.
Because test case generation is driven by the contract rather than individual judgement under time pressure, edge cases and negative scenarios are included by default rather than deprioritised. This improves the robustness and completeness of validation coverage across the board. Finally, by anchoring validation to a versioned data contract, the solution enables early detection of upstream schema or business rule changes — reducing the repeated cycles of rework, root cause analysis, and cross-team coordination that currently follow even minor upstream changes.
What are your key user flows/features?
The Test Suite Generator is designed to work in conjunction with a Data Contract Generator being developed by a separate hackathon team. The data contract — a machine-readable YAML file synthesised from datasets, data dictionaries, and supporting documentation — serves as the input to our solution.
The Test Suite Generator workflow has two main steps. First, the user uploads a validated data contract along with any relevant testing templates. Second, the solution generates a comprehensive set of test cases and synthetic test datasets, covering schema validation, business rules, edge cases, and negative scenarios. Users can then refine the outputs or adjust coverage.
How did you make the experience seamless/intuitive for the end user?
The Test Suite Generator is designed to be simple and accessible for both technical and non-technical users. The upload interface is straightforward, and guided prompts are provided throughout the workflow to reduce onboarding time and help users provide useful context to the AI.
Once a data contract is uploaded, the solution generates test cases with minimal manual effort. Users can review, edit, and iteratively refine outputs through a user-friendly interface, ensuring that generated test cases reflect their specific validation requirements before use.
What feedback did users give about the product? What worked well and what required improvement?
The Test Suite Generator is extremely extensive, covering both deterministic standard test cases and more complex test cases generated by the AI. Users complimented the AI-generated test cases, including cross-column validation cases. They also praised the feature of identifying possible edge test cases which revealed contract gaps that they can then refine in the Data Contract via the Data Contract Generator, improving the extensiveness of testing.
However, users mentioned that the lack of a seamless integrated link between products could be an area for improvement. In the current workflow, users will need to repeatedly import and export inputs and outputs from different products. For example, the contract gaps identified from the Test Suite Generator cannot be directly applied to the Data Contract Generator and vice versa. In the future, integrating and combining all the products into 1 unified product could be explored.
What is your "North Star" metric?
Our North Star metric is the reduction in time spent per release cycle on manual test suite creation and validation — measured in hours saved per data engineer or QA analyst. This directly captures whether the solution is delivering on its core promise of reducing manual effort and freeing staff for higher-value work.
Supporting metrics include: improvement in test coverage (proportion of schema, business rule, edge case, and negative scenarios covered per release), reduction in downstream data quality incidents attributed to gaps in pre-release validation, reduction in turnaround time for dashboard and report releases, and adoption rate across CDOO and CIOO teams over time.
What outcomes do you expect this to be able to deliver in the short/medium/long term if your product is launched to users?
In the short term, data engineers and QA analysts are expected to spend significantly less time writing test cases manually. Our solution should recover a meaningful portion of the 15–25% of workflow time currently lost to documentation interpretation and translation to test cases. Data validation coverage becomes more consistent across teams, with base cases and edge cases recommended by the solution rather than left to be added manually by each data engineer.
In the medium term, earlier detection of schema and business rule changes should reduce downstream disruptions and the repeated cycles of root cause analysis that follow. Teams also build familiarity with contract-driven validation, supporting better alignment with HPB's data governance standards over time.
This comprehensive coverage of data test cases is also expected to directly improve the quality of the produced datasets. By systematically validating schema, business rules, edge cases, and positive / negative scenarios, the solution reduces the likelihood of data defects propagating downstream. In turn, this strengthens the reliability of reports and analytics outputs built on top of these datasets, enabling more accurate insights and more confident decision-making across HPB.
In the long term, a standardised data testing and validation framework can be scaled across HPB, reducing reliance on individual knowledge and disparate documentations. This will in turn enable a more efficent and more reliable delivery of data products, and ultimately, higher-quality data that supports more confident public health decision-making.