Software testing trends for the near future cover three core areas: AI both as a test object and as a tool, professional test data management and holistic quality assurance under regulatory pressure. The decisive factor here is that quality is no longer an isolated testing task, but a shared team responsibility that requires social competence and cooperative work.
Key Takeaways
- AI as a testing tool is only useful if there is a specific problem that it solves. Tools without a problem solution are of no use, no matter how big the budget is.
- Test data management will become even more important in the future due to regulatory requirements such as the Cyber Resilience Act and the accessibility obligation.
- Non-functional quality characteristics such as performance, usability and security must be incorporated into the design right from the start, not just at the final testing stage.
- Static code analysis is an immediately available, automatic tool for code reviews and reducing technical debt that many teams still do not use enough.
- Software quality can only be achieved as a team effort: testers who contribute knowledge about the entire product and actively shape communication are better positioned for this than any individual role.
Which trends should testers really keep an eye on?
AI is at the top of the list, but not as an end in itself. For testers, there are two questions: how do you test AI, and how does AI help with testing? Both are young fields, unlike the decades-old approach to classic software.
When it comes to testing AI, an old question comes into sharp focus: What does quality mean in this context? The classic tester pattern, test case in, expected result out, often does not apply here. Instead, other methods are needed, such as statistical approaches. Anyone working in the field of software development should at least have an idea of this, even without being an AI expert.
When it comes to the second question, AI as a tool for testing, it is worth taking a sober look. AI is a tool. The question is not which tool to install because an AI budget pot is open, but which specific problem is to be solved. If there is a problem that AI can solve, then bring it on. If the tool is of no use, you can leave it alone.
If there is a problem that I can solve with AI, then bring it on. Installing tools that are of no use at all is pointless. Richard Seidl
There are enough useful starting points: understanding requirements better or making them more complete, working through specifications more cleanly, generating better test cases, supporting automation. That is a legitimate use. Playing around with Copilot is only justified if it actually makes development faster or better.
Test data remains an ongoing issue
Many companies find test data management difficult, and this will not change any time soon. From an AI perspective, the topic is coming back in a new form. Test data specialists will continue to be needed in the coming years.
In addition, regulatory requirements are increasing the pressure: Cyber Resilience Act, usability requirements, the accessibility plan. They are forcing us to think more broadly about quality than before.
Think quality holistically, don’t just check it at the end
The separation of developers and testers no longer works. Even in an agile team, it’s not enough for one person to develop and then push it over to the other, who then tests it. Quality must be thought of in a more integral way.
This particularly applies to non-functional testing. If you only run a penetration test, a performance test or a usability test at the end and find problems there, you are turning the big wheel backwards. The question then suddenly arises as to whether the framework fits or whether the architecture is the right one. A big barrel that opens late.
Thinking about these non-functional issues at the design stage saves corrections later on. Testers can contribute a lot here. This applies both externally and internally, for example in terms of maintainability. Many companies are running software that is 10, 20 or 30 years old and whose mountains of technical debt are simply being pushed back and forth. For future software, this should not be allowed to happen in the first place.
Why does software testing fail most often in practice?
The most common mistake is not having a strategy at all. You don’t need a 40-page test plan, but you do need a rough checklist: Which test levels, which test types, what about test automation, what about static analysis, reviews and test methods? For each point, you can then take a risk-based view and decide whether the project needs it.
Not every project needs comprehensive integration testing or fully automated UI testing. Things can be solved differently. But you have to think about it once. This is precisely the step that is often missing.
The second classic issue concerns the quality of the tests. There are often many test cases, whether unit tests, system testing or technical tests, often even automated. Nevertheless, there is still room for improvement. In the case of unit tests, people like to run behind the coverage measure: 80 percent code coverage is considered mandatory. Whether additional test cases with other values would be useful, which do not increase coverage but test better, often falls by the wayside.
Static analysis is a no-brainer
Static analysis is one of the clearest quick wins that is often overlooked in testing. The tools have been around for years and effectively provide an automatic reviewer for code and documents.
While AI is demanded everywhere, a ready-made machine is available here that provides input for reducing technical debt. The usual excuse that the tool throws up too many findings only half counts. Of course you have to process the results. But a strategy can be devised that is not painful. No one has to spend a whole year just fixing errors. This can be integrated into day-to-day business.
What skills do testers need for the future?
The most important development is not in technical skills, but in collaboration. The first idea of agility was often to put a tester on the dev team. The tester then sat in the sprint, was thrown the software at the end and started testing. If they found any errors, the review was canceled. It no longer works like that today.
Good teams thrive on soft and social skills. How do you communicate with each other, how transparent are you, how do you work together in pair programming or pair testing? This is where knowledge spreads. Testers start coding a little, developers develop quality awareness instead of first developing and then testing.
The tester was traditionally the one who had an overview of the entire product and knew all the people because he had to constantly ask questions. This position in the project network predestines the role to increase quality holistically and to step out of the testing silo. Quality starts with the requirements.
Instead of just reviewing requirements and pointing out deficiencies, it is about constructive contribution: helping developers to adapt tests in the IDE, creating a better code base. It’s the skills that count, not the role. Those who switch from ivory tower communication via Jira ticket to a joint look at the project will make progress.
How to turn working side by side into a real team
An example from the financial sector shows what change looks like. A team switched to agile and immediately asked itself what would happen to the test team. They put a tester on the team, who sat out his sprint and wrote manual test cases in an old, large test management tool while the developers worked through one user story after another. That didn’t work at all.
Through retrospectives and joint work, the team gradually began to communicate and exchange ideas. Working side by side became working together. One developer began to think about later automation and to implement it himself with the testing expertise from the team. The tester, who came from a purely technical background, got to grips with the technology, helped set up test automation and gave feedback on the unit tests.
One morning, a developer and this tester were sitting at a computer doing self-organized pair testing. No one had instructed them to do this. They had decided on their own to spend a morning working on the issues together. The separation was gone and the work was visibly more fun. Moments like this show that things can be better than they often are today.
Mentoring beats traditional specialist advice
Mentoring works better than instruction. The traditional consultant comes in and explains how it works, and the reaction is often: I don’t listen to you anyway. The coaching approach works better, listening more, providing impetus, using questions to bring topics into the team.
In practice, this means that a team is not coached full-time, but over one or two appointments per week. You look together at what needs to be done, set an impulse, build up an improvement and let things run their course over the week. In this way, the team improves from week to week.
The leverage is often not where the management thinks it is. “We all need to do test automation” is not always the point at which a team really needs help. An expensive tool or an open-source tool will not make the world a better place. The real problems often lie elsewhere. This also applies to AI: in many teams, the problems are so deeply rooted in other issues that AI would not be a solution, but rather make the situation worse.
Mastermind groups as a space for progress
A fixed group of five to six people who want to make progress in the same area can help each other a lot. Test managers, freelancers from test automation or testers meet every two to four weeks over a longer period of time, at a fixed date, and go through their challenges in a structured way.
This requires a high level of trust, which is why NDAs are part of it, because you can go in with hard topics. The topics range from the technical, such as test methodology, to the personal, such as burnout or stress and the question of how to communicate this. The group remains fixed for three to six months, many last longer and support each other as they progress.
