An efficient and customer-oriented public transport system requires the "digitalization" of the vehicle fleet. Digitalization of the fleet also brings benefits for the public transport company itself: driver guidance can be improved, for example, through advanced navigation apps and flexible communication tools between the driver and the dispatch center; maintenance services can be scheduled more efficiently by creatively using vehicle engine data; customer satisfaction increases due to good real-time vehicle information, etc.

That is why De Lijn is running a digitalization project for the vehicle fleet, namely: "IT on board of the vehicle". In this project, a new, future-oriented vehicle platform is being implemented on the vehicles. For this, off-the-shelf hardware and software components are being purchased. For the development of the new vehicle platform, based on these new components but also with legacy components on the vehicle and in the back office, a supplier has been appointed, called the 'integrator'.

Throughout the duration of the project and the lifecycle of the platform, there will regularly be deliverables that need to be tested. We strive for a (semi-)automated test platform on which we can easily test different vehicle configurations, both in a simulation environment and on physical devices/test setups.

There is a clear distinction between two types of test environments:

• Virtual development environment: This has its own test pipeline and accompanying test software, allowing functionalities to be validated in simulated contexts.

• Physical test environment: This mainly consists of hardware, in the form of several test benches with SIL (Software-in-the-Loop) components where necessary.

In addition, several test vehicles will also be equipped (HIL – Hardware-in-the-loop), which require extensive test monitoring to accurately monitor and validate results.

Context/Requirements

To guide the implementation phase, De Lijn is looking for a test manager. The test manager works closely with the integrator regarding the coordination and follow-up of the different test cycles and evaluates the test reports (test progress, defect status, test coverage, etc.). The test manager monitors whether the integrator applies the necessary best practices regarding test automation. In addition, he determines the division of responsibilities between De Lijn and the integrator.

The expectations for the test manager (TM) are as follows:

• The TM is responsible for developing a test strategy and test governance.

• The TM is responsible for drawing up a master test plan, including detailed test plans (per work package/phase/release and implementation plan).

• The TM monitors the progress, quality, and coverage of the tests and timely escalates quality risks to the Project Manager. This applies to tests performed by both the integrator and De Lijn.

• The TM leads a multidisciplinary team of testers.

• The TM is responsible for working out the implementation requirements of the (semi-)automated test platform of the ITaB system.

• The TM defines a system that enables integration tests (functional), acceptance tests, physical tests, and also performance tests.

• The TM defines a procedure to test physical components in the lab and/or a procedure to test items on a physical moving vehicle, and monitors its implementation.

• The TM defines and details a platform/application with which testers can request tests and a platform/application to define a specific test situation. For this, the TM must define the content and monitor the implementation of all databases needed to download and install software components on a test platform, select vehicle types, select test conditions, select test types, etc.

• The TM monitors the implementation of the simulation data database.

• The TM standardizes test reporting and the use of test tools.

• The TM defines the method of documentation and the tool in which all executed tests are documented.

• The TM monitors the selection and implementation of the test environment and integrates it with De Lijn's development process flow.

• The TM establishes procedures regarding code validation and defines the rules for publishing software to production.

• The TM supports the formal acceptance of implemented work packages.

• The TM collaborates with the DevOps engineer responsible for the actual implementation of the requirements defined by the TM.

• The TM is NOT responsible for:

• The implementation of the images and software components on the simulation platform.

• The implementation of the test toolset.

This concerns a half-time position