Skip to main content
search results
Sorry, but nothing matched your search terms. Sorry, but nothing matched your search terms. Sorry, but nothing matched your search terms.
Sorry, but we cannot handle your search query now. Please, try again later! Sorry, but we cannot handle your search query now. Please, try again later! Sorry, but we cannot handle your search query now. Please, try again later!
Search suggestions

CASE STUDY

Ticketing Card: Agile Testing for an agile card

Project background

Expleo is the engineering partner of a big travel and transport company.

Passengers have been issued with a card with two electronic RFID chips, which we call a Ticketing Card. The chips are used to store a customer number, so that the customer’s name, season ticket type and validity can be checked using an electronic scanner.

For the public transport (PT) sector, Ticketing Card is creating a uniform standard for displaying and checking electronic tickets. Its introduction is the first step towards electronic ticketing in the PT sector. More ticket types and partner services are now gradually being integrated. For example, access to car and bike sharing can all be loaded onto a Ticketing Card, as well as ski passes for various ski destinations. The aim is to enable PT users to access as many services as possible, along the mobility chain, using a single card.

Challenge

As an independent specialist, Expleo has been assisting with quality assurance during the development of the Ticketing Card system, particularly in the fields of test management, test engineering and test automation.

‘Ticketing Card 1.0’ is particularly challenging because it is being implemented as a hybrid overall project, consisting of multiple subprojects, based on a variety of development and organisational models:

  • Scrum-based development teams for highly specialised and proprietary client/server systems
  • Development of financial systems based on SAP ECC and CRM using the waterfall model
  • Integrated project for purchasing inspection device hardware
  • External projects handled by service partners for card production and photo scanning

The central test team has been organised in accordance with this project structure.

Solution

Agile organisation of the test team

In addition to functional testers, so-called ‘embedded testers’ are used, which serve the dual purpose of linking the conventional and agile worlds as efficiently as possible. As testers within an agile team, they check stories from the current sprint and include the conventional test stages in the test.

Test and defect management have been set up as cross-departmental functions. Test automation, integration and services testing are also coordinated across the various subprojects, as well as all non-functional tests. A test manager is the product owner for the testing process and manages all test resources with scrum elements: sprints, planning, daily and retrospective meetings, backlog.

Release Management

Hybrid projects, such as TicktingCard 1.0, require the release cycle periods to be coordinated across all subprojects:

  • Agile development teams implement user stories in two week sprints, which are tested in the development environment.
  • Using four week iterations, complete features undergo functional testing across all subprojects in an initial common environment that is fully complete.
  • Using six monthly releases, a set of features is deployed in the form of an epic story.
  • The iterations and releases are agreed by means of features in a product backlog, which forms the basis of the sprint backlog for the agile development teams.

Development of a suitable test model

The specific characteristics of the Ticketing Card 1.0 project require certain adjustments to the corporate test model, such as:

  • Requirements formulated on the basis of business processes and independently of any particular system (high level requirements)
  • The solution design must be structured using epic stories (across all subprojects) and features (specific to a particular subproject)
  • The functional capability and level of maturity of internal and external system interfaces/services are a basic prerequisite for a successful functional test (across the entire system and all subprojects)
  • Two-stage acceptance procedure for the overall system:

Acceptance tests focusing on functional requirements conducted internally and as part of the project by Business Analysis; acceptance of iterations for complete epic stories and general acceptance of production releases by specialist departments.

Test environment planning

For hybrid projects, shared management of heterogeneous test environments and test data is vital, as well as the creation of uniform structures for these environments. In practice, this means developing solutions that allow room for compromise, planning how they will be used and taking account of the impact these compromises have on the test activities. In addition, platform dependencies must be taken into account – particularly for test data that is distributed across multiple platforms or test data that is used in conjunction with other systems on the same platform.

Reducing dependencies

For hybrid projects, the virtualisation of services is a tried-and-tested method of reducing technical system dependencies during early development phases, both for different releases that have to be supported in parallel at the same test level and external systems whose availability cannot be guaranteed in the respective test environment.

Systematisation of technical tests

In the case of complex system projects, a business process can be found in all kinds of different ways within the systems that are used to implement it. For this reason, technical requirements – and particularly the load behaviour – have to be tested using functional E2E scenarios rather than within the strict confines of a particular system.

Outcome

The new Ticketing Card system is being introduced on schedule, on budget and to the desired quality standard.

By implementing specific measures in order to create sustainable testware, the necessary conditions have been created for nearshoring and offshoring the test activities during the system’s operating phase. It is the first ever project at the customer side, where the testware has been handed over directly to the nearshoring team. As a result, in-house test activities can focus on functional quality assurance. The nearshore locations are the Expleo test centres in Görlitz (Germany) and Güssing (Austria).

Especially our in-depth knowledge of test management, quality assurance and engineering combined with an agile approach contributed to the success of the overall project.

Global Account Manager, Railway, Expleo

Operators:
Are you ready to meet the challenge of the Railway sector?

INNOVATION MANAGEMENT & SOLUTIONS

E-mobility

To ease the transition from fossil fuel combustion to electric-powered drive, Expleo proposes a powerful electrification offer for automotive, marine and rail systems.