Does the data match
the promise?
A fictional onboarding flow, tested from the rule to the record. This sample illustrates a structured approach to validation across requirements, API behavior, and stored data.
A duplicate request replaced an existing record in the seeded model. A second defect ignored a review flag. After correction, all eight Java model checks passed. The API and browser integration still need separate execution.
A small scope with explicit rules.
A fictional product accepts an onboarding request and stores a record. The first question is whether “accepted” means the right values were saved and the right business rule was applied.
| Rule | Acceptance criteria | Evidence |
|---|---|---|
| R01 / Valid input | A nonblank identifier, basic email format, and an allowed country are required. Invalid input creates no record. | T01–T04, T08 |
| R02 / Unique identifier | A duplicate identifier is rejected without changing the existing record. | T05 |
| R03 / Review routing | A flagged request enters manual_review. Other valid requests enter pending. | T01, T06 |
| R04 / Data fidelity | Submitted identifier, email, and country are preserved. | T07 + SQL fixture |
Write behavior before implementation.
Scenario: Route a flagged request for review Given a valid request with the review flag enabled When the request is processed Then the stored status should be "manual_review"
Two seeded failures. Eight corrected checks.
The Java reference model deliberately includes two failure modes: duplicate records can be overwritten, and the review flag can be ignored. The same eight checks run against the seeded and corrected modes.
SEEDED BASELINE T01 | PASS | valid request is pending T02 | PASS | missing id rejected T03 | PASS | malformed email rejected T04 | PASS | unsupported country rejected T05 | FAIL | duplicate id rejected T06 | FAIL | review flag routes to manual review T07 | PASS | submitted fields preserved T08 | PASS | rejected request creates no record 6 passed / 2 failed CORRECTED MODEL T01 | PASS | valid request is pending T02 | PASS | missing id rejected T03 | PASS | malformed email rejected T04 | PASS | unsupported country rejected T05 | PASS | duplicate id rejected T06 | PASS | review flag routes to manual review T07 | PASS | submitted fields preserved T08 | PASS | rejected request creates no record 8 passed / 0 failed
Inspect the runnable Java source ↗
Eight checks in Java 17 against an in-memory model. No browser, TestNG runner, Cucumber runner, or production API was involved in this execution. The source runs without external libraries.
Run it yourself
java OnboardingChecks.java
A successful response is one checkpoint.
The proposed API sequence creates a record, retrieves it, compares the returned fields, and checks that a duplicate request is rejected. Stored data is validated separately with a SQL comparison.
| Request | Check | Sample status |
|---|---|---|
| POST /customers | 201 response, identifier and fields preserved, initial state pending | Postman design sample |
| GET /customers/{id} | 200 response and returned fields match the submitted values | Postman design sample |
| Duplicate POST | 409 conflict | Postman design sample |
| SQL comparison | Detect submitted / recorded field mismatches | Executed on SQLite fixtures |
Download the Postman collection ↗
-- Independent synthetic fixture: returns rows where submitted and stored fields differ.
SELECT s.id, s.email AS submitted_email, r.email AS stored_email,
s.country AS submitted_country, r.country AS stored_country
FROM submitted s LEFT JOIN recorded r ON s.id = r.id
WHERE r.id IS NULL OR s.email IS NOT r.email OR s.country IS NOT r.country;
SQL result: one mismatch detected in the seeded fixture; zero mismatches in the corrected fixture. This is a separate data-quality check, not an end-to-end integration test of the Java model.
A defect someone can act on.
D01 — A duplicate identifier overwrites a record
| Impact | Existing customer information can be replaced. High severity under the sample’s rules. |
|---|---|
| Reproduce | Create C01 with sample@example.test. Submit C01 again with other@example.test in seeded mode. |
| Expected | Reject the second request and preserve the first record. |
| Observed | The seeded model accepts the second request. T05 fails. |
| Correction | Check identifier uniqueness before writing. |
| Retest | T05 passes on the corrected serial model. Concurrent-write behavior remains untested. |
Ready to review.
Not ready for production.
The corrected model satisfies the included checks. A live release would still need evidence for:
- Authentication, authorization, and appropriate handling of personal data.
- Persistent storage and protection against simultaneous duplicate writes.
- Real API integration, browser interactions, accessibility, and recovery behavior.
- Stakeholder-approved rules and completed UAT.
My recommendation for a client would identify these gaps explicitly. Passing a small test suite is useful evidence, but it is not a blanket release approval.