Passenger information from various sources must be reliably processed, updated, and made available to other systems and applications. This is precisely why a railway operator is developing a central platform.
Passenger Information Systems: Reliably Processing and Providing Data
The data chain extends from train and operational data through input interfaces, validation, and APIs to the central platform. From there, it continues through management and approval to display on station screens and digital channels.
Errors can occur at any stage of this chain: incomplete source data, faulty interfaces, incorrect data mappings, manual entries, unclear approvals, or delayed synchronization. This results in contradictory, outdated, or incorrect information being displayed regarding departures, tracks, delays, and connections. For passengers, this means missed connections, unnecessary wait times, and reduced planning reliability—especially in the case of last-minute changes and transfers. If such discrepancies occur repeatedly, they undermine trust in the official information channels.
Some of these errors are not technical in nature but arise from the management of the information. Incorrectly maintained data, erroneous validity periods, or changes that have not been properly approved have a direct impact on the information displayed, especially if they are not fully synchronized across all connected systems and output channels. An incorrect track number is a typical example of this.
The platform does not operate in isolation: Several IT service providers, a development team, and technical and subject-matter experts are involved in its implementation. Quality assurance therefore examines every stage of the data chain: the business-side processing of information, the technical interfaces, the administrative processes involving authorizations and approvals, and the data transfers between the participating organizations. The goal is to detect errors early, track them throughout the course of the project, and enhance the reliability of passenger information.
TestSolutions was involved early on in quality assurance throughout the development process. Test management encompasses the planning and coordination of test activities across all releases leading up to go-live.
Test activities are jointly conducted and coordinated by two test teams from the participating IT service providers, the development team, and the TestSolutions test team.
Quality assurance includes system tests, integration tests, regression tests, acceptance tests, and post-release defect testing. At least 95 percent coverage is achieved for the features included in the scope. The number of test cases is in the four-digit range.
Another key focus is on defect management. Hundreds of tickets are logged, analyzed, prioritized, and tracked.
A typical defect retest goes through several stages. The test team documents the finding in Jira, prioritizes it, and designates the responsible party—either the development team or one of the involved IT service providers, depending on jurisdiction. After the issue is resolved, the corrected version is deployed to the test environment. There, the test team re-tests the defect and either closes the ticket upon a successful retest or returns it with additional information. If there are business-related questions, the utility company’s points of contact are involved to ensure that a finding is evaluated not only technically but also from a business perspective. If a correction affects multiple systems, the retest is combined with the subsequent regression test.
The results are documented in accordance with quality standards and reported regularly to project management and stakeholders. In addition, TestSolutions reviews the final test reports and prepares recommendations for release.
In this phase of the project, the focus is deliberately on manual testing and close-knit test management. With a dense sequence of releases on a tightly scheduled timeline and changing delivery statuses from multiple service providers, manual testing provides actionable insights more quickly than setting up an automation pipeline, which only pays off over the course of several releases. Automation is therefore primarily a matter of timing: it becomes worthwhile when test cases repeat consistently beyond the go-live date.
We use Jira, Xray, and Confluence. Depending on the project area, both Scrum and the waterfall model are used in the project environment.
Until the planned go-live, the focus will be on the remaining release and testing activities, defect retesting, and the final assessment of quality risks.
After the go-live, we will update this post with the results achieved: the completion of testing activities as well as concrete improvements in operations and collaboration among the participating organizations.
Does this sound familiar?
Multiple IT service providers, interdependent systems, and a go-live date that cannot be postponed: Test management in such scenarios is our daily business.
Contact us—we’re here to help.