{"id":18821,"date":"2026-07-20T10:12:01","date_gmt":"2026-07-20T08:12:01","guid":{"rendered":"https:\/\/www.uni.lu\/research-en\/?post_type=news&p=18821"},"modified":"2026-07-20T10:22:57","modified_gmt":"2026-07-20T08:22:57","slug":"the-art-of-generating-useful-software-tests","status":"publish","type":"news","link":"https:\/\/www.uni.lu\/research-en\/news\/the-art-of-generating-useful-software-tests\/","title":{"rendered":"The art of generating useful software tests"},"content":{"rendered":"\n
\n

One faulty software update brought down 8.5 million devices in 2024. FutureFinTech research asks how automated testing can earn human trust.<\/strong> <\/p>\n\n\n\n

On 19 July 2024, computer screens around the world turned blue. Airlines cancelled flights. Hospitals postponed appointments. Banks, retailers, and government services reported disruption. It had all the markings of a cyberattack, but it was a faulty configuration update distributed by cybersecurity company CrowdStrike<\/a>. Microsoft estimated that the update affected 8.5 million Windows devices. Although this represented less than one per cent of Windows machines, many supported critical services. <\/p>\n\n\n\n

CrowdStrike withdrew the update within hours, but affected computers often required manual intervention to restart, extending the disruption. The incident illustrated a difficult truth: one small software update can have consequences far beyond the system where the problem begins. <\/p>\n\n\n\n

Software tests aim to identify such problems before deployment. But modern systems contain countless possible inputs, interactions, and failure points. Automatic test-generation tools offer one answer. Yet producing more tests does not automatically make software safer. At a FutureFinTech lecture on 2 July, Assistant Professor Carolin Brandt from TU Delft explored a more fundamental question: how can automatically generated tests become genuinely useful to the developers who must assess, understand, and maintain them? <\/p>\n\n\n\n

\nA safety net for changing software <\/h2>\n\n\n\n

A software test is a small program that checks whether another program behaves as expected. In an online banking service, one test might verify that a customer can transfer \u20ac50 from an account holding \u20ac100. Another could confirm that the system refuses the transfer when funds are insufficient. Tests can also examine less predictable situations. What happens when a user leaves a field empty, enters an invalid amount, or clicks a payment button twice? <\/p>\n\n\n\n

These questions matter because software rarely stays unchanged. Developers add features, repair faults, and connect systems to new services. A change in one place can create unexpected problems elsewhere. This is particularly important in financial services, where software supports payments, identity checks, fraud detection, investment decisions, and regulatory reporting. <\/p>\n\n\n\n

Thorough testing takes time. Researchers have therefore developed several ways to automate it, from random input generation and fuzzing to search-based optimisation. Brandt’s work focuses on test amplification<\/strong>. Rather than creating a test from nothing, the tool starts from tests that developers have already written. It changes the inputs, explores new behaviour, and creates new checks based on what it observes. The approach can uncover parts of a system that existing tests do not examine. But the generated results are not always ready to use. <\/p>\n\n\n\n

\nAsking open-source developers what mattered <\/h2>\n\n\n\n

To understand what makes a generated test useful, Brandt and her collaborators worked with maintainers of open-source Java projects. The researchers initially considered 312 projects. After running test amplification and manually reviewing the results, they submitted one proposed test to each of 39 projects through a pull request. They then engaged directly with the maintainers and implemented their feedback. <\/p>\n\n\n\n

Twenty proposed tests were accepted, 13 were rejected, and six remained open when the results were reported. Maintainers repeatedly returned to one question: what is the added value?<\/strong> Higher code coverage alone did not convince them. They wanted to know whether a test represented a meaningful scenario and protected behaviour that mattered to users. They requested simpler inputs, the removal of unrelated code, alignment with project conventions, and comments explaining unusual results. In some cases, they decided that the behaviour was not valuable enough to test. <\/p>\n\n\n\n

Their feedback confirmed that tests are also a form of communication. A well-designed test tells future developers what a system should do and why that behaviour matters. <\/p>\n\n\n\n

Brandt also discussed the growing role of large language models in test generation. These systems can perform well when tests follow established patterns, but their results depend heavily on the context and instructions they receive. This reinforces a wider lesson from her research:<\/p>\n\n\n\n

\n
\n
\n
\n \u201f<\/span>\n automation works best when it supports human judgement rather than attempting to replace it.<\/strong> \u201d\n<\/blockquote>\n
\n

<\/p><\/div>\n <\/figure>\n <\/div>\n<\/section>\n\n

<\/div>\n\n\n

\nFrom software quality to AI compliance<\/h2>\n\n\n\n

This human-centred approach becomes especially important as financial institutions adopt artificial intelligence. AI can help organisations analyse regulations, identify suspicious transactions, assess risks, and automate reporting. But institutions must also test whether these systems remain reliable, fair, secure, and compliant. Automatic tools could help teams explore more scenarios than people could create manually. However, developers, auditors, legal specialists, and compliance professionals must still understand the evidence those tools produce. A thousand unexplained tests may create the appearance of rigour without creating genuine confidence. <\/p>\n\n\n\n

As AI takes on more generative work in software development, questions about oversight will become more pressing. The challenge will not only be to produce more code and more tests, but to ensure that people can understand, question, and trust what those tools create. <\/p>\n\n\n\n

\n
\n \n
\n
\n
\n