Next-gen software engineering is an approach to AI software engineering that ties software construction and quality assurance closely together: every software specification has a matching test specification, every model a test model. AI-supported automation raises the degree of test automation, but it doesn’t replace experts. Critical software needs testers with hands-on training more than ever.
Key Takeaways
- AI-generated code causes high costs in the long run, because it is often of lower quality and still has to be versioned, documented and tested.
- Test specifications are test models in all but name, even if the industry doesn’t call them that. They keep the business logic consistent across technologies while the technologies underneath change.
- The tester role has a bright future, because software runs in more and more critical areas and quality assurance can’t be fully automated.
- Training in software testing has to focus more on hands-on experience, because only learning by doing builds the real expertise that theory alone can’t provide.
Testing Can Only Tell You Whether Software Is Good or Bad
Checking has a built-in limit: at the end of a test run, all you get is a statement about whether something works or not. That limit is the starting point for rethinking software engineering, and for AI software engineering in particular.
Ina Schieferdecker has worked on the quality and testing side for decades and automated consistently along the way. Test automation, she says, has arrived across the board, and the generic test architecture from the ISTQB Test Automation Engineer syllabus is now being applied to frameworks such as Robot Framework. Still, one frustration remains: just stating the result isn’t enough.
The conclusion is meant constructively. Software construction and software analysis need to be linked more closely, instead of checking afterward what development has produced.
Why Software and Test Software Should Be Built Against Each Other
Every software system comes with a test system, every software specification with a test specification, every software model with a test model. You can carry this principle all the way up to the requirements.
The V-model, widely used in German-speaking countries, serves as the reference. Its document-based approach covers not only the software side but also the test side, and aligns the two. Software and test software are developed in parallel and against each other.
The idea reaches the requirements themselves. They should be defined from the system perspective and from the test perspective. If requirements aren’t testable, development isn’t worth it.
Model-Based Testing Returns Under a New Name
Low-code and no-code approaches are bringing model-based testing into practice. The new label is accepted where the old one was hard to sell.
Many conference talks today speak of test specifications written in structured testing. Mathematically, these are models, even if nobody calls them that. They are test models.
The advantage of working at the specification level becomes clear when you compare it with writing it all out in code. If you code keyword-driven tests or map the page logic of a web interface, you have to go deep into the details, and that kind of code is hard to maintain. At the specification level, you can express the logic independently of any technology. The technology can evolve, and the business logic stays.
Vibe Coding Lets an Expensive Problem In Through the Back Door
Bad code that gets waved through quickly becomes very expensive in the long run. That’s exactly why catching it belongs on the construction side, up front, at the requirements.
It’s a shift-left approach under another name. Testing starts with requirements engineering. If the requirements aren’t testable, there is no chance of building a usable system.
Automatically generated code brings its own risks. It can be functionally wrong, but it can also perform badly or turn out as spaghetti code. Language models haven’t been trained only on high-quality code so far. They pull in everything.
“We’re letting a big problem in through the back door, because worse code that gets waved through too quickly becomes very, very expensive in the long run.”
(Ina Schieferdecker)
Every Additional Line of Code Costs Money
The wow effect of AI generation hides the follow-up costs. Generated code has to be reviewed, maintained, versioned, documented and tested. Hardly anyone has done that math so far.
Language models produce a lot of text and code that needs reviewing. Even asking them to keep it short and concise changes little: the output stays wordy and eager to show off.
Ina expects a serious productive breakthrough to take another five to ten years. Anyone who uses LLMs or smaller language models seriously is already on the road to disillusionment, she says, and has a better sense of what doesn’t work.
How the ModelBus Embeds AI in Software Engineering
Software engineering is information-processing engineering, and all information can be modeled. Requirements need different models than tests, and tests need different models than system designs or architectures.
The ModelBus concept developed at Fraunhofer follows the idea of a service bus, but it connects models and information. Information travels over the bus from the requirement into the system design or test design, and from test execution back into system analysis and into readjusting the requirements.
For every engineering task there are front-runner tools, but never a one-size-fits-all solution. Once you apply AI at every point, the interesting question is how the individual chatbots find out from each other what is currently happening in which task. There is no complete picture of this tool class yet.
In AI Software Engineering, Models Can Also Grow Bottom-Up
Classic model-driven software engineering works top-down. You design in models, but at some point the reality of development catches up, the models stop being updated and fall out of sync.
AI adds something new. You can recognize patterns in code, and patterns are abstractions, which means models. That makes it possible to model not only top-down but also to derive models bottom-up from existing code.
Software is language, more formal than natural language, which makes it a good field for LLMs. The same goes for models. This is open research territory with room for many doctoral theses.
Theory Isn’t Enough for the Next Generation of Testers
Training for the testing profession today is heavily theory-based. There is a glossary and a living syllabus framework with Foundation, Advanced and Expert levels as well as specialist modules, but practical exercises are often not part of the exam.
That becomes a problem because software sits in more and more critical areas. In critical infrastructure and business-critical applications, software has to work reliably, securely and with good performance. Experts safeguard that quality, and their skills don’t come from theory alone.
There’s another concern. Language models absorb broad knowledge, while there is little time left to train the next generation of experts. Training should therefore consistently push participants into challenging practical tasks, so that real aha moments and learning happen.
Practical Exercises Create the Transfer Abstract Examples Can’t
Learning happens on real tasks, not on abstract textbook examples. An ATM or an isolated input field will get you through the exam, but the transfer only works when participants bring their own requirements and user stories and develop test cases from them.
Ina has taught the Foundation Level at several universities, with a continuous series of practical exercises over a semester or a two-week block course. The class worked through a use case that wasn’t too simple, at unit, integration, system and acceptance level, including performance questions and model-based testing, and always with the tools that were current at the time.
AI lowers the barrier for exactly this approach. The effort of coding and maintaining exercises was an obstacle for a long time. With AI, that is much easier to manage, and there is hardly an excuse left for keeping practice out of training.
The Tester Role Has a Bright Future
The more critical the areas software runs in, the more indispensable quality assurance becomes, and automation can’t rationalize it away.
AI raises the level of automation another notch, and that’s a good thing. The gain lies in using limited testing resources more intelligently, going straight for the pain points and doing it as early as possible. That is exactly what the profession should work toward.
Frequently Asked Questions
Why isn’t it enough to perform testing only after software has been developed?
Ultimately, a test run only tells us whether something works or not. This finding comes too late to ensure quality. Next-gen software engineering therefore integrates design and testing: Every software specification has a corresponding test specification; every model has a corresponding test model; and every software system has a corresponding test system.
How can you tell if a requirement is flawed?
By its testability. Requirements should be defined from both the system perspective and the testing perspective. If a requirement cannot be tested, there is no chance of building a usable system, and the development is not worth the effort. Testing thus begins as early as requirements engineering, a “shift left” approach by another name.
Has model-based testing become mainstream?
Yes, mostly under a different name. Low-code and no-code approaches are bringing the idea to life, and what is referred to as a test specification in structured testing is, mathematically speaking, a test model. The advantage over hard-coded keyword scripts or mapped page logic is that: At the specification level, the business logic remains constant, while the underlying technology continues to evolve.
Why is AI-generated code considered expensive, even though it’s created quickly?
Because every additional line of code incurs follow-up costs: it must be reviewed, maintained, versioned, documented, and tested. Generated code can be functionally incorrect, have poor performance, or be spaghetti code. Language models have not yet been trained only on high-quality code, but instead draw in everything. Code rushed through the process quickly becomes very expensive in the long run.
How far have language models come in productive software engineering?
A serious, productive breakthrough will likely take another five to ten years. Anyone who seriously uses LLMs or smaller language models is already on the path to disillusionment and has a better understanding of what doesn’t work. The models produce a lot of text and code that needs reviewing, even when you explicitly ask for brevity.
Can AI derive models from existing code?
Yes. Patterns can be identified in code, and patterns are abstractions, that is, models. In addition to the classic top-down approach of model-driven software engineering, this also enables a bottom-up approach. This addresses an old problem: models designed top-down are no longer adjusted in day-to-day development and fall out of sync.
What’s missing from tester training that focuses primarily on certifications?
Practical experience. A glossary and a syllabus framework with Foundation, Advanced, and Expert levels map out knowledge, but practical exercises are often not part of the exam. Abstract textbook examples, such as an ATM or an isolated input field, get you through the exam, but the transfer of knowledge only succeeds when applied to your own requirements and user stories.
Is AI making the role of testers obsolete?
No. The more critical the areas in which software runs become, the more indispensable quality assurance becomes, and that cannot be eliminated through automation. AI takes the level of automation up a notch. The benefit lies in using limited testing resources more intelligently, targeting pain points specifically, and doing so as early as possible.
