IVU Traffic Technologies
Delivering the next generation of public transportation solutions, tested with Ranorex
IVU Traffic Technologies AG delivers IT solutions for more than 500 public transport operators worldwide. The flagship product, IVU.suite, addresses processes for bus and rail companies from planning, dispatching, and fleet management to ticketing, passenger information, and settlement of transport contracts.
For this case study, we spoke with the Senior Test Architect, Ms. Silke Reimer, about the experiences of the development team in the Berlin office of IVU Traffic Technologies.
Developers in this office are organized into 10 to 12 teams, with one or two testers per team. The testers have a range of test automation experience, including some who need to use no-code tools as well as those with programming skills.
These development teams are working on a collection of applications to support companies in the public transport area, such as bus lines and train operators. The applications support critical functions such as resource planning, staffing, and time-tabling. While some of these applications have an API with can be tested without using the graphical user interface (GUI), others can be tested only with the GUI.
A broad range of technologies created a demanding testing environment, including some applications that could only be tested through the GUI.
Broad range of technologies
Applications include C++ modules, Java modules using both Swing and Eclipse RCP, and a few web modules implemented with Angular. There are also several GUI technologies like QT, as well as older technologies such as the ISA framework or VX/VA. The testing strategy needed to cover all of these technologies.
Frequent third-party code updates
Increasingly, the team found that companies that deliver third-party modules were updating their versions (i.e. JBOSS) more often than than the in-house team was updating. As a result, the team needed a way to quickly perform integration testing on these third-party modules before releasing the new version to their customers.
Time-consuming smoke testing
The team wanted to do a smoke test for all modules for every software version, to ensure basic functionality such as the application opening, libraries loading, successful printing, etc. However, in some cases, this might mean hundreds of modules: a time-consuming and cumbersome process.
“I recommend Ranorex because it’s really easy to use in the beginning with the recording modules. But afterwards, if it’s necessary to adapt and go deeper for your needs, you can do all this with Ranorex. You have the RanoreXPath which you can use in a way that’s more flexible, and the user code. And I like the support and the documentation. You get a lot of help when you start using Ranorex.”
Development teams can release more often and identify defects earlier, due to more frequent testing and shorter test cycles.
To identify the right test automation solution for their situation, the team initially conducted a series of web searches to identify candidates. “We chose Ranorex as the first one, and then we spent one or two weeks trying it out: accessing all the different technologies, end-to-end, to see how it runs, and in what environments. [We investigated] how it behaves, what happens if we change the O/S from Windows 10, to make sure we can develop in one version and that doesn’t break the solution. We tested all this out, and then calculated the price, and checked again if we could find another solution which could do the same things. But we didn’t find a better solution. Then we asked for reference customers, and we found one in Berlin. We spent one day with them and this was also very helpful.”
Although feature releases happen on a quarterly schedule based on customer preference, there may be daily releases to the internal environment. Now, the team saves significant time by automatically running smoke tests of all modules in a release — even when this may include hundreds of modules.
“Now we run the Ranorex solution every day, and when we find a problem we can fix it quickly. The next thing we want to implement is performance tests with Ranorex to check several times whether the application is available, has done the next step, and then check execution times required to run the operation.”
When it comes to adopting test automation, Ms. Reimer made the following suggestions: “One thing to know that it takes time — maybe more than you think in the beginning. You have to know that you need to really get into it and have time to implement and maintain. You need to think about the process — what you want to do with the automation, when to run it, what to do if there is a finding, what if the solution is not running anymore. It takes time for the company to get used to the new process.”
To learn more about how Ranorex Studio can help solve your testing challenges, contact our sales team.