GUI Testing for Qt: How Teams Test Complex Applications in Practice

How Do Development Teams Approach GUI Testing with Qt QML?

If you develop with Qt, GUI testing usually gets more demanding as the application grows. There are more screens, states, interactions, and edge cases to cover. Hardware may be part of the equation, particularly in embedded development. A change to one feature can affect something that has been working reliably for years. Tests can also become unstable when they depend on fixed timing rather than what the application is actually doing.

These are familiar problems for teams building production software with Qt. What becomes interesting is how different teams solve them once their products reach a certain level of complexity. reMarkable, d&b audiotechnik, Accenture Song, and TEM Innovations (Werfen) work in very different industries, from digital paper and professional audio to consulting and medical devices, but their development and testing challenges have plenty in common.

Their experiences offer some useful answers to the questions Qt developers tend to run into when they need GUI testing to work reliably in practice.

How do you Test a Qt UI that Runs on Real Hardware?

reMarkable builds digital paper tablets designed for writing, note-taking, and working with ideas. The experience on the device is deliberately simple, but the engineering behind that simplicity is not. The company now develops two distinct tablet platforms: the black-and-white reMarkable 2 and the newer reMarkable Paper Pro with a color display. Alongside the devices themselves, the team develops companion applications for desktop and mobile. The interfaces across this product ecosystem are built with Qt, with reMarkable also creating its own components for the experience it wants to deliver.

Hear firsthand from Nuno, Senior Test Automation Engineer at reMarkable

That creates an interesting development problem. The software needs to feel consistent and straightforward for the person using it while supporting different hardware and applications underneath. The team therefore has to think carefully about modularity and reuse. QML helps here because developers can apply familiar concepts across different parts of the product. Someone who has already worked with QML on one application can move into the mobile or desktop application without having to learn a completely different UI technology first. For a team maintaining several related products, that familiarity makes everyday development considerably easier.

Testing the device adds another layer because the UI is closely connected to the hardware. reMarkable uses Squish to automate user flows and run tests on real devices, allowing the team to reproduce interactions and verify how the application responds. This is particularly useful when the same behavior needs to be checked repeatedly as the software changes.

The team has also spent time making those tests more stable. Instead of checking a property immediately and assuming the application has already reached the expected state, tests can dynamically wait for that state to occur. That distinction is important when you are testing real software on real hardware, where operations do not always complete in exactly the same number of milliseconds. By changing how those verifications are handled, reMarkable has been able to reduce test instability significantly.

For developers working on embedded Qt applications, the takeaway is practical. Reliable GUI automation should follow the state of the application rather than depend on optimistic assumptions about timing. A test that understands when the application is ready is generally more useful than one that simply waits for an arbitrary amount of time and hopes for the best.

Why Does Qt Object Recognition Matter in GUI Testing?

If you are evaluating GUI testing tools for a Qt application, it is worth asking how much the tool actually understands about Qt. Many testing tools can reproduce mouse clicks or interact with what appears on the screen. That does not necessarily mean they understand the objects, properties, and relationships inside the Qt application itself.

This is one of the main reasons direct Qt integration matters to d&b audiotechnik. The company develops professional PA systems used in environments such as stadiums, cruise ships, and other large venues. As its software has grown, the number of features and UI elements that need to keep working has grown with it. Senior Software Engineer Alexander Weidemann describes the ability of Squish to work directly with the Qt object system as the key advantage for his team.

"The game changer, the key thing is the seamless integration. The UI testing tool can dig into the Qt object system."

That integration reduces the amount of Qt-specific work the team has to create for itself. Other testing tools are available, of course, but if a generic tool does not understand the framework properly, somebody on the development team has to bridge that gap. Engineers can end up implementing additional handling for Qt before they get to the actual job of writing and running useful tests.

Hear firsthand from Alexander Weidemann, Senior Software Engineer, from d&b audiotechnik

For a team already maintaining a growing application, that extra infrastructure has a cost. It needs to be developed, understood, debugged, and maintained as the application changes. d&b's approach is to use tooling that already understands the Qt-specific parts of the software so the team can spend more time defining what needs to be tested rather than teaching the testing tool how the application works.

Can you Automate Qt GUI Tests Without Writing Everything by Hand?

Test automation often raises another practical question: how much test code are developers and QA engineers going to have to write and maintain themselves? A framework can be technically powerful and still become difficult to adopt if every useful test requires substantial scripting before it can do anything meaningful.

At d&b, Squish's record-and-playback functionality helps engineers create test scripts based on interactions with the application. This reduces the need to manually write all of the underlying Python from the beginning. The team can also work with different approaches, including Behavior-Driven Development and Model-Based Testing, depending on what makes sense for the project and the behavior being tested.

Recording does not replace the thinking involved in good test automation. Someone still needs to decide which workflows matter, what the expected result should be, how tests should be organized, and whether a test is robust enough to remain useful as the application evolves. What recording can do is shorten the path between identifying a useful user flow and turning that flow into something repeatable.

That becomes particularly valuable when GUI testing is shared between developers and QA engineers. Not everyone contributing to automation needs to approach the problem in exactly the same way or spend most of their time writing technical test code. The tooling can handle more of the interaction layer while the team concentrates on the behavior it wants to verify.

How do you Stop new Qt Features From Breaking Existing Ones?

Regression testing becomes harder to ignore as a Qt application matures. When developers are working on a new feature or a large epic, their attention naturally stays close to that work. They know what has changed, which new interactions need checking, and where the difficult parts of the implementation are likely to be. What is harder to keep in mind is every older feature elsewhere in the application that still needs to behave exactly as it did before.

d&b uses Squish automated GUI testing to keep checking those established parts of the software as new functionality is introduced. Weidemann points out that adding a feature does not change the requirement that older features must continue to work. Automated regression tests give the team a way to verify those existing flows repeatedly without expecting developers to manually revisit every area of the UI after each change.

This becomes more useful as the product grows because the amount of historical functionality grows too. Manual regression testing can become a larger task with every release, while an established automated suite can continue exercising the same important behaviors. Developers can then focus their manual attention on the areas where it provides the most value, particularly new functionality and changes that need investigation rather than repetition.

d&b also uses Axivion for static code analysis alongside Squish for GUI testing. The two tools address different parts of software quality while both handling Qt-specific aspects of the application. Static analysis can identify problems in the code and its architecture, while GUI automation checks whether the application continues to behave as expected from the user side. For the development team, that provides useful coverage at two different levels without requiring custom Qt integration around each tool.

At What point Does Manual GUI Testing Stop Scaling?

There is nothing inherently wrong with manual testing. When an application is relatively small, manually checking its important workflows can be quick, flexible, and perfectly reasonable. The difficulty appears when the application continues growing while the team still has to repeat the same verification work release after release.

Sebastian Kratz, Team Lead for Digital Solutions at Accenture Song, has seen that transition while working on client projects involving Qt, QML, Qt Widgets, and Squish. His team has used the technologies together across different projects for several years, giving him a view of what happens when testing requirements grow alongside the software.

"Coming from a world where manual testing was done exclusively, getting into automation is kind of really an eye opener. It's the only way to handle the complexity that comes when the project reaches a certain size."

That point about project size is important. A team may start with a manageable number of manual tests, but every feature introduces more behavior that may need to be checked again later. Eventually the number of possible interactions and regression scenarios becomes difficult to cover consistently by hand. The team then has an uncomfortable choice between spending more time on repetitive verification and accepting that less of the application will be checked.

Guide: Learn How to Scale Automated Testing Strategies

Get the 5-Step Handbook

Automation changes that equation by giving repeatable checks somewhere else to live. Once an important workflow has been automated reliably, it can be executed again without asking a person to reproduce every interaction manually. Developers and QA engineers can use their time for exploratory testing, unusual cases, new functionality, and problems where human judgment is actually useful.

Hear firsthand from Sebastian Kratz, Team Lead for Digital Solutions at Accenture Song

For Sebastian, moving toward automation also changed his view of QA itself. Testing was no longer simply about manually verifying what developers had built. Automation opened up a broader role involving test strategy, integration, results, and deciding how quality information should be used throughout the project.

How do Automated GUI Tests fit into an Existing Development Workflow?

A GUI test suite is more useful when it fits naturally into the development process around it. Running automated tests in a separate environment and occasionally checking the results may provide some value, but it leaves much of the potential benefit unused. Teams usually need the tests to work with the systems they already rely on for development, integration, reporting, and quality assurance.

This is something Sebastian highlights from Accenture Song's work with Squish. His team can integrate the testing setup into existing IT ecosystems, keep track of results, and use testing data with other tools. That means the output of GUI automation does not have to remain isolated inside the testing tool. It can become part of the broader flow of information the team uses to understand the state of a project.

For a Qt team evaluating GUI automation, this is worth considering early. The immediate question may be whether a tool can interact with a QML control or verify a property, but the longer-term question is what happens after hundreds or thousands of those tests exist. Developers need to know when something fails. QA teams need to understand trends and results. The testing system needs to remain useful as the project and surrounding toolchain change.

The easier that information is to integrate into existing engineering practices, the less likely automated GUI testing is to become a separate process that only a small part of the team understands.

How Difficult is it to Bring a new Engineer into Qt GUI Automation?

The maintainability of test automation depends on people as much as technology. A test suite may run reliably today, but eventually someone new will need to add tests, investigate failures, or understand why an existing test was designed in a particular way. If the tooling takes months to learn or depends heavily on knowledge held by one engineer, the team has created another bottleneck.

TEM Innovations GmbH (Werfen) has dealt with this question while automating GUI testing for its medical devices, particularly products related to hemostasis. The company has used Squish for around four years and also uses Test Center for handling test results. Christian Nennemann came to the tool after working with several other testing solutions and found that he could become productive with it relatively quickly.

That experience matters when new test automation engineers join the team. According to Christian, they can get started quickly rather than spending a long period learning how to make basic automation work. At the same time, the tool supports approaches such as BDD and model-based testing, which gives the team flexibility as its testing needs change.

Hear firsthand from Christian Nennemann from TEM Innovations GmbH

Ease of onboarding is easy to overlook when comparing GUI testing tools because feature lists are much simpler to compare. In practice, the amount of specialist knowledge required to maintain the tests has a direct effect on how sustainable the setup becomes. If several people can understand and extend the automation, the test suite is much less likely to become something everyone is afraid to touch.

How Much Time can Qt GUI Automation Actually Save?

TEM Innovations provides a straightforward example because its GUI testing used to be performed manually. Every repeated test required somebody to carry out the interactions and check the results. Once those tests were automated, the team could move that work into a stable suite that runs regularly, including nightly test runs.

Christian describes the impact clearly:

"Squish is a really huge time saver for us. As soon as we have the test automated, it just runs."

This does not mean the tests never need attention again. When the application changes, automated tests may need to change too. There will always be some maintenance, and poorly designed tests can create more maintenance than useful coverage. The difference is that maintaining a reusable automated check is not the same as asking an engineer to manually repeat the same sequence every night or before every release.

That is where the time saving becomes meaningful. One automated test may not change much by itself. A stable suite that executes dozens or hundreds of established workflows across repeated builds is a different proposition. It gives the team consistent regression coverage while reducing the amount of repetitive manual effort required to obtain it.

For TEM Innovations, this has created a stable testing base that can continue running while the team concentrates its manual effort elsewhere.

What Should you Look for When Setting up GUI Testing for Qt?

The customer stories differ in their details, but they point to a useful way of evaluating GUI testing for a Qt project. Start with the problems your developers and testers actually have rather than a long checklist of testing features:

• If you work with embedded hardware, ask whether your automated tests can run against the real devices you release and whether they can deal sensibly with asynchronous state changes.

• If your application has a large QML or Qt Widgets interface, find out whether the testing tool understands the underlying Qt objects or whether your team will have to implement that integration itself.

• If your product is already mature, think about how much existing functionality needs to be checked every time a new feature lands.

It is also worth looking beyond the first few tests. Consider who will maintain the suite a year from now, how quickly another engineer can understand it, where the results will go, and whether the automation fits into the development systems your team already uses. A testing approach that works well for ten scripts but becomes difficult to manage at several hundred is not solving the long-term problem.

The experiences of these four teams show different parts of that picture:

• reMarkable runs automated Qt GUI tests on real hardware and has improved reliability by waiting dynamically for application states.

• d&b audiotechnik uses direct access to the Qt object system to avoid unnecessary custom integration and to keep checking established functionality as the product grows.

• Accenture Song uses automation to handle project complexity at scale and connect testing with existing IT ecosystems.

• TEM Innovations has moved repetitive GUI verification away from manual execution and into a stable suite that can run nightly.

If you are developing with Qt and wondering where to start, look at what your team repeats most often. The same user flows being checked after every release, the same regression paths being clicked through by hand, and the same old functionality being reverified whenever something new is added are usually good places to begin. The goal is not to automate interaction for its own sake. It is to make reliable verification repeatable, so developers and testers can spend more of their time on the parts of the product that actually need their attention.