Pour accompagner la phase d’implémentation, De Lijn recherche un test architect. Le test architect peut élaborer, évaluer et présenter de manière autonome un plan et une stratégie. Le test architect travaille en étroite collaboration avec l’intégrator concernant la coordination et le suivi des différents cycles de test et évalue les rapports de test (progression des tests, état des défauts, couverture des tests, …). Le test architect vérifie si l’intégrator applique les best practices nécessaires en matière de test automation. En outre, il définit la répartition des responsabilités entre De Lijn et l’intégrator.

Les attentes pour le test architect (TA) sont les suivantes :

• Le TA est responsable de l’élaboration d’une test strategy et d’une test governance dans le contexte d’ITaB.
• Le TA est responsable de la rédaction d’un master test plan, incluant des detailed test plans dans le contexte d’ITaB (par work package/phase/release et implementation plan).
• Le TA est responsable de la définition des exigences d’implémentation de la (semi-)automated test platform du système ITaB.
• Le TA définit un système permettant d’effectuer des integration tests (fonctionnels), acceptance tests, physical tests ainsi que des performance tests.
• Le TA définit une procédure pour tester les composants physiques en laboratoire et/ou une procédure pour tester certains éléments sur un véhicule physique en circulation, et supervise sa mise en œuvre.
• Le TA définit et détaille une plate-forme/application permettant aux testeurs de soumettre des tests et une plate-forme/application permettant de définir une situation de test spécifique. Pour cela, le TA doit définir le contenu de toutes les bases de données nécessaires pour télécharger et installer des software components sur une test platform, sélectionner des vehicle types, sélectionner des test conditions, sélectionner des test types, …
• Le TA standardise le test reporting et l’utilisation des test tools et les relie aux prescriptions de sécurité auxquelles De Lijn doit se conformer.
• Le TA définit la méthode de documentation et l’outil dans lequel tous les tests effectués sont documentés.
• Le TA collabore avec le test engineer responsable de l’implémentation effective des exigences définies par le TA.

Le TA n’est PAS responsable de l’implémentation effective, de l’exécution des tests, etc.

Le candidat-exécutant doit être disponible à temps partiel pour la totalité de la mission durant la période demandée, à savoir 100 jours-homme entre le 1er avril 2026 et le 31 mars 2027, cette implication étant répartie sur les mois.

Contexte/Exigences

Un transport public efficace et orienté client nécessite une “digitalisation” du parc de véhicules. La digitalisation du parc présente également des avantages pour l’opérateur de transport public : l’accompagnement des chauffeurs peut être amélioré, par exemple via des applications de navigation avancées et des outils de communication flexibles entre le chauffeur et le dispatch center, les services de maintenance peuvent être planifiés de façon plus efficace grâce à l’utilisation créative des motor data du véhicule, la satisfaction des clients augmente grâce à une bonne real-time vehicle information, etc.

C’est pourquoi un projet de digitalisation du parc de véhicules est en cours chez De Lijn, à savoir : “IT à bord du véhicule”. Dans ce projet, une nouvelle vehicle platform, orientée vers l’avenir, est implémentée sur les véhicules. À cet effet, des hardware et software components off-the-shelf sont achetés. Pour le développement de la nouvelle vehicle platform, basée sur ces nouveaux components mais aussi avec des legacy components présents sur le véhicule et dans le backoffice, un fournisseur a été désigné, appelé l’‘integrator’.

Pendant toute la durée du projet et la vie de la platform, des éléments devront régulièrement être livrés et testés. Nous visons une (semi-)automated test platform qui permette de tester facilement différentes vehicle configurations, tant dans un simulated environment que sur des physical devices/test setups.

Il existe une distinction claire entre deux types d’environnements de test :

• Environnement de développement virtuel : Celui-ci dispose de sa propre test pipeline et de sa test software associée, permettant de valider les fonctionnalités dans un contexte simulé.
• Environnement de test physique : Celui-ci se compose principalement de hardware, sous forme de quelques test benches avec des components SIL (Software-in-the-Loop) lorsque nécessaire.

En outre, quelques test vehicles seront également équipés (HIL – Hardware-in-the-loop), nécessitant un suivi de test approfondi afin de surveiller et valider précisément les résultats.