Test data service for a bank's integration environment

Six delivery teams shared one integration environment with a fixed pool of about two hundred test customer accounts, each in a particular state — overdrawn, dormant, restricted, and so on. Teams reused accounts, mutated them, and did not reset them, so a suite that passed in the morning failed in the afternoon for reasons that had nothing to do with the code. The workaround had become a spreadsheet where teams booked accounts, which is exactly as effective as it sounds. Roughly a fifth of failed builds were traced to test data rather than defects.

Senior QA engineer on the platform enablement team. I proposed the service, built the first version alone, and then handed it to a two-person team while staying as the reviewer.

I owned the account minting logic — the part that composes a customer, an account, a transaction history and whatever state the requester asked for, in a way the downstream systems accept. I built the lease model, where a team requests an account with a set of properties and holds it for a bounded time, and the reaper that returns leases when a build finishes or crashes. I wrote the client library the suites use and the documentation, which I treated as part of the deliverable rather than an afterthought.

I made accounts disposable rather than reusable — mint fresh, use once, discard — which the environment team resisted because it grows the database. The alternative is cleanup logic, and cleanup logic is the thing that is wrong when everything else is fine. We settled on disposable accounts plus a weekly purge, which has held for two years. I also chose to describe the desired account declaratively — the caller says what must be true about it, not how to build it — so that when a downstream system changed its onboarding rules, one service changed and no suite did. That decision paid off within four months when exactly that happened.

The integration environment mirrors production systems I had no control over, several of which are mainframe-era with batch windows, so minting an account with a settled transaction history genuinely takes overnight for some states. I had to model that honestly rather than pretend it was instant, which meant pre-minting a warm pool for slow states. Everything was subject to the bank's change process, so each release had a two-week lead time and I learned to batch changes.

Test-data-related build failures went from about twenty percent of failures to under two. The booking spreadsheet was abandoned within a month, which I count as the real adoption signal. Suites got faster too, because teams stopped writing defensive setup code to cope with dirty accounts — one team measured their integration suite dropping by eleven minutes. Six teams use it, and two others outside the original scope adopted it without anyone asking me.

The two engineers who took it over rewrote my minting logic properly and added the warm pool. An environment engineer explained the batch windows to me in enough detail that I stopped designing around a fantasy. One team lead ran the first pilot and wrote the honest feedback that reshaped the client library.