At a glance
- Client: a governmental fund that registers physical bodies in the insurance system and issues the supporting documents
- System under test: the enterprise service bus (ESB) connecting the fund's internal IT systems so business processes can reach several of them at once
- Why it matters: when there are defects in the ESB, the business process cannot execute even though every subsystem works correctly - which is precisely the failure that unit-level testing never catches
- Hard requirement: send batch requests to the ESB with up to 50 parallel threads, imitating format and logical control (FLC) - the process that helps people fill in tax forms and fans out into multiple systems and business processes
- Constraints: Python (the customer's maintainers work in Python), a web interface usable by test specialists with no automation experience and no UNIX administration knowledge, frequent quick redeployment with minimal load on customer infrastructure, and it had to run on Windows
- Solution: the whole instrument - interface, test data storage, execution system and components - packaged with Docker, deployable with one command, even without an internet connection
- Result: deployment and update of the testing infrastructure from scratch in one click; a task that used to take a day now takes less than half an hour
- Also removed: manual test-data preparation - the unique part of each test's data is now generated automatically, where previously the customer updated it by hand for every run
An integration layer nobody can test in pieces
Modern governmental IT infrastructure runs operations that touch a large number of internal systems, and an enterprise service bus is what lets a single business process reach across them. That architecture has a specific and awkward property: correctness is not additive. Every connected system can pass its own tests and the citizen-facing process can still fail, because the defect lives in the bus between them.
For a fund that registers people in the insurance system and issues their supporting documents, that failure is not an internal inconvenience - it is a document that does not get issued. So the fund came to PFLB with exactly this request: test the ESB.
The difficulty was never really the tests. It was who would run them afterwards. The bus is updated regularly, and so are the systems it reaches, so any testing automation built here would need redeploying constantly - by people whose job is testing, not Linux administration.
What the customer specified
The project was demanding because the criteria for the testing instrument were fixed in advance, and each one closed off an easy option:
- Batch requests to the ESB with up to 50 parallel threads. This imitates FLC - information format and logical control - during which the system makes multiple requests to other systems and business processes.
- Python as the implementation language, because the instrument's maintainers on the customer side mostly work in Python. A tool in a language the client cannot read is a tool with an expiry date.
- A web interface understandable to test specialists with neither automated testing experience nor UNIX administration knowledge, allowing auto-test development, execution and update, plus selection of the test environment.
- Frequent, quick deployment with minimal workload on customer infrastructure and on the system developer - driven by the regular ESB updates and the updates of the systems it reaches.
- It had to work on Windows.
What was built
To assemble a cohesive product - interface, test data storage, test execution system and the other components - into something that satisfied all of the above, the team chose Docker.
The deployment approach is based on the DevOps container virtualisation method: Docker packs the application together with its environment and dependencies into a virtual container that can be ported to and executed on any system with Docker installed.
That one decision resolved the awkward part of the specification. The instrument became portable, and can be deployed with one command even without an internet connection - which matters in a government network where pulling dependencies on demand is not a given.
On top of it:
- A specialist on the customer side selects the desired tests and the test environment in the web interface, then starts the run.
- All tests are developed and updated through the graphical user interface - not by editing files on a server.
- The unique part of each test's data is generated automatically. Previously the customer updated test data manually before every run, which cost several hours of manual work each time.
Results
- The full automated testing instrument and all required components deploy from scratch in one click.
- A task that used to take a day now takes less than half an hour.
- Test data preparation stopped being manual work - several hours per run of hand-updating test data were removed.
- Costs down and human error eliminated in deploying and updating the customer platform's testing infrastructure.
- Customer specialists can deploy and update that infrastructure by running a few simple scripts, without writing or editing administration instructions.
- The testing process itself was optimised through automation and central test management rather than through adding people.
Questions this engagement answers
Why test an ESB separately when every connected system already has tests?
Because a defect in the bus stops the business process while every subsystem still reports healthy. Integration testing at the bus is the only place that failure is visible.
How do you hand an automation tool to testers who are not administrators?
By making the deployment a single command and the day-to-day work a web interface. Here the testers had neither automation experience nor UNIX administration knowledge, and the specification treated that as a design input rather than a training problem.
What does containerisation actually buy a test tool?
Portability with no environment negotiation: the instrument, its dependencies and its environment travel together, deploy on any Docker host, and come up without an internet connection. That is what turned a day of setup into under thirty minutes.
What was the biggest hidden cost before automation?
Test data. The unique part of every test's data was being updated by hand before each run - several hours of work that generation now absorbs entirely.
Testing an integration layer your own team has to keep running?
The build is the easy half. The half that decides whether the suite is alive in a year is whether the people who own the systems can redeploy and update it themselves - which is a packaging and interface decision, made at the start.
