AI-assisted test automation –
Your code stays in-house
Qwasaa builds test coverage where it is missing: in legacy device software.
Test cases are generated based on your changes, on your hardware, without the cloud.
Your releases are getting faster. Your tests are not. With every feature, the gap widens between what ships and what is actually covered.
In legacy systems, this is rarely an oversight. The test suite grew over the years, alongside the code and usually under deadline pressure. At some point no one can say with confidence which tests cover which behaviour. New tests cost time the sprint does not have. Existing tests break when something changes, and repairing them consumes exactly the budget that was meant for new coverage.
Qwasaa starts where the gap appears. An AI agent reads the change in the code, works out which dependencies are affected, and generates the relevant test cases. It runs on a machine inside your network. Your source code never leaves the building.
Test automation fits into your existing development process without rebuilding it. It complements the step-by-step modernization of legacy software at the point where changes need to be verified.
When the test suite stops keeping up
Automated testing rarely pays off where it would be easiest. It pays off where changes have become risky.
Coverage grows more slowly than the code
The team ships new features regularly. Test coverage cannot keep pace, because test cases are written by hand and manual work does not scale. We identify which areas of your system ship untested and how coverage can be generated there automatically instead of being added afterwards. The result: coverage grows with the code, not with the size of the team.
No one knows which test verifies what
Test names say little, documentation is missing or outdated, and the mapping between requirements and tests sits in the heads of a few individuals. Every change starts the search again. Qwasaa makes the connection between code, function and test machine-readable. The relationship becomes something you can query rather than reconstruct.
The team repairs tests instead of writing them
After every larger change, tests break that should not have been affected. Developers spend days bringing test code back in line. Regression tests get maintained because they have to be, not because they deliver the most value right now. We shift that work: the agent updates test cases and prioritises which tests need to run first. The team reviews the result instead of producing it.
Time gets tight before release
Tests run late, often shortly before delivery. Any defect found then meets a schedule with no slack left. When tests are written and run alongside development, issues are detected earlier. The decision about a defect is made while it is still cheap to fix.
Tests write themselves
This is the same sequence we demonstrate live at our trade fair booth. Four steps, one machine, no external service.
Something changes in the running product: a new function, adjusted behaviour, a bug fix. The trigger is ordinary day-to-day development, not a separate test run.
It analyses what has changed and which parts of the system are affected. Dependencies a person would miss, because they sit three levels down, become visible as well.
From that analysis the agent writes the matching test cases. Without manual intervention, in the language and test framework your project already uses.
The tests run immediately. You see straight away what the change covers and what remains open, before the build goes into a release.
Why this runs on-premises
The agent works on a machine inside your network. There is no cloud service, no API call to an external service, and no copy of your source code on someone else’s infrastructure.
For medical technology, semiconductors and aerospace, this is often a prerequisite for using AI at all. Source code in those fields is intellectual property, contractual subject matter and often part of a regulatory approval. Handing it to an external service has to be justified to customers, auditors and your own legal department.
Running locally takes that question off the table. What the model sees stays on your hardware. Traceable, auditable, and independent of how an external provider’s terms of use may change.
What Qwasaa specifically covers
Test automation only works if it fits the codebase and the processes you already have. That is why we start with what exists, not with the tool.
Before any software testing is automated, we establish what is already there. We evaluate the test strategy, existing coverage, regression tests, test data and the places where verification is missing. You get an assessment of where automation will make a difference and where it would only shift the effort elsewhere. If a broader view is needed, a Technical Assessment is the right starting point.
We set up the environment inside your network: model selection matched to the hardware you have, integration with repository and build system, and a connection to your existing CI. Without your team having to change its tools.
It is not only new changes that can be covered. For untested areas of your existing code we generate test cases retrospectively, closing the gaps first where changes happen most often.
In device software and HMI, the risk often sits in the user interface and at the interfaces to the hardware. We build test automation for the GUI and integration level, including hardware-in-the-loop where the equipment calls for it.
The agent needs an understanding of the system to write usable tests. In the process, a machine-readable map of your architecture and its dependencies takes shape. That knowledge stays in the company, even when people move on.
We do not build a dependency on us. Your team learns to run, review and correct the agent. Whatever we set up, you should be able to carry on by yourselves.
What you gain from test automation
What changes once testing keeps pace with development.
Fewer defects reach production
Gaps in coverage surface before a build ships. What today only shows up at the customer’s site appears in the test run right after the commit. That moves the fix out of support and back into development, where it costs a fraction.
Releases are no longer delayed by testing
Tests are written and run alongside development. Testing is finished when the code is finished. Quality assurance is no longer the final bottleneck before delivery.
Coverage grows with the code, not with the size of the team
New features bring their tests with them. The gap does not widen while the product grows.
The team works on test strategy instead of test maintenance
Reading diffs, following dependencies, bringing test scaffolding back in line: the agent takes care of that. What requires judgement stays with the team. Which risks have to be covered, what depth of testing is appropriate, and whether a test case is asking the wrong question.
Lower costs, higher quality
The QA budget goes into coverage and new work instead of maintenance and repair. Today a large share of it goes into regression testing and keeping existing tests in line. Once that work is automated, effort goes down and coverage goes up.
Less depends on individual knowledge
The connection between functions and tests sits in the system rather than in the heads of experienced team members.
Industries where automated testing matters most
The more closely software is tied to a device, a production line or a regulatory approval, the more expensive a defect becomes once it reaches the field.
Medical technology
Verification under IEC 62304 has to be planned, carried out and documented so that it can be traced. Automatically generated tests are only usable there if traceability is preserved. We set up test generation so that every test case maps to a requirement and feeds into your technical file.
Semiconductor industry
Equipment software runs for decades and is extended continuously. The source code is often the most closely guarded asset in the company. Running on-premises is not a question of convenience here.
Aerospace
Changes to qualified software bring evidence requirements with them. The more precisely you can see which areas a change touches, the smaller the scope of re-verification can remain.
Industry and automation
Control software is rarely tested at a desk. It is tested on the machine. Hardware-in-the-loop and automated regression testing move part of that work back into development.
Frequently asked questions about test automation
When does test automation make sense?
When code changes often and the consequences of a change are hard to predict. For stable code that is rarely touched, automation brings little. The value comes from repetition: the more often a test runs, the sooner it pays for its setup. That is why we start with the areas that change most frequently, not the largest areas.
What is automated testing?
Automated testing is the part of software testing that runs without manual intervention, usually with every code change. It ranges from unit testing of individual functions through integration testing between components to GUI tests that reproduce how the software is operated. The difference from a manual test is not thoroughness; it is repeatability.
How does this help with regression testing?
Regression tests are where much of the maintenance effort lies in legacy systems. They break when something changes, and bringing them back in line is manual work. The agent updates them based on the diff and prioritises which ones actually need to run for a given change, so the suite stays useful instead of simply growing.
When does test automation pay off financially?
The usual calculation weighs setup effort against the manual testing time saved. In legacy systems that falls short, because the larger cost often lies elsewhere: in the time spent before every release securing changes whose effects nobody fully knows. We make that cost visible first, in the initial conversation.
Can AI write reliable test cases?
It can propose test cases that a person then has to review. That is exactly how we use it. The agent takes on the work that costs time and requires little judgement: reading diffs, following dependencies, writing test scaffolding. The decision on whether a test verifies the right thing stays with the team. A test case nobody has read does not count as coverage for us.
How much computing power does running locally require?
For most projects, a workstation with a current GPU is enough. In the initial conversation, we check what your existing hardware can handle and select the model accordingly. Procuring a dedicated server is usually not necessary.
Let's talk about your current test environment
In a first conversation, you give us an overview of your system and the current state of its verification.
Typical topics include:
• Your system, its technology and how often it changes
• What is tested today and what is not
• Whether running locally on your hardware is realistic
• Possible next steps
The conversation takes about 30 minutes. At the end, we can assess together whether test automation will make a difference in the short term in your case and where the most sensible entry point lies.
Creating clarity together
Together, we’ll assess where your software is covered today, where gaps remain, and what the next realistic step is.
Frank Rub
Chief Executive Officer
Sebastian Kratz
Head of Innovation
Let’s get started
We look forward to your inquiry and will get back to you within one business day.
By clicking the submit button, you confirm that you agree to our privacy policy.
You can find us here
Our home is on the 13th floor of the Jentower, in the heart of the beautiful city of Jena on the Saale River.
Do drop by – we look forward to seeing you.
show on map