Story
Wie ein KI-QA-Agent auf einem einzigen Mac mini läuft
1.792 kaputte Tests, ein Mac mini und ein Agent mit 24 Tools. Wie der QA-Agent von PerfectApps Tests repariert, Fehlschläge sichtet und Releases freigibt, und warum er auf Apple silicon statt auf einem Linux-VPS läuft.
Aktualisiert 2026-09-15
PerfectApps ist eine No-Code-Plattform für Anwendungen. Das QA-Team betreut mehr als 2.100 automatisierte Testfälle in Cypress und Selenium. Heute wird der Großteil dieser Arbeit von einem KI-Agenten gestartet, ausgewertet und berichtet, der auf einem einzigen dedizierten Mac mini lebt.
So ist er entstanden, das macht er, und darum war die Wahl der Hardware bewusst.
Am Anfang standen 1.792 kaputte Tests
Ein verpflichtender Sicherheitsfix entfernte Bootstrap aus der gesamten Codebasis von PerfectApps. Die Seitenstruktur änderte sich überall gleichzeitig, und am selben Tag schlugen 1.792 Testfälle fehl, verteilt auf mehr als 50 Bereiche des Produkts.
Niemand hat die manuelle Reparatur genau geschätzt, weil sie nie von Hand gemacht wurde. Die grobe Einschätzung: das ganze Team, vier Personen, bis zu zwei Monate lang mit nichts anderem beschäftigt.
Da hörte der Agent auf, nur eine Idee zu sein.
Reparieren, dann abdecken, dann beurteilen
Reparieren. Statt 1.792 Tests einzeln zu reparieren, fand der Agent jede Grundursache einmal und wandte den Fix auf jede betroffene Spec an. Der Login wanderte in einen einzigen gemeinsamen Befehl, sodass eine Änderung jeden Test erreichte.
Abdecken. Als die Reparatur lief, nahm sich derselbe Ansatz Bereiche vor, die nie getestet worden waren. Die Suite wuchs von 1.400 auf 1.955 Spec-Dateien. Dazu gehörte ein visueller Diagramm-Designer, der auf einem Canvas gezeichnet wird und einem Test nichts zum Anklicken bietet. Die Lösung: nicht mehr den Canvas testen, sondern die gespeicherten Daten prüfen. 51 neue Specs, alle grün beim ersten vollständigen Lauf.
Beurteilen. Nach jeder Regression musste jemand die Fehlschläge durchgehen und entscheiden, welche kaputte Tests waren, welche echte Bugs und welche Rauschen. Das kostete pro Release 12 Stunden, verteilt auf drei Personen. Jetzt ist es die Aufgabe des Agenten. Bei einem Release ging er 1.748 Testergebnisse durch und fand unter rund 300 Fehlschlägen genau einen echten Produktbug. Der Rest waren Altlasten der Migration.
Was der Agent macht
Der Agent hat 24 Tools und entscheidet selbst, welche er in welcher Reihenfolge aufruft. Das Team spricht mit ihm in einfachem Englisch, in Microsoft Teams oder im Web.
Ein Release-Lauf durchläuft eine feste Pipeline:
One release run
- 1SanityA smoke test on production. If it fails, everything stops.
- 2RegressionMore than 2,100 test cases in five parallel lanes, in about 90 minutes.
- 3New testsSpecs for areas without coverage, generated while regression runs.
- 4TriageEvery failure classified as a test issue, a real bug, a flaky test or a known blocker.
- 5ReportA GO or NO-GO verdict, posted to Teams and to the GitHub pull request.
Ein paar Beispiele, was sich geändert hat:
| Aufgabe | Von Hand | Mit Agent |
|---|---|---|
| Kompletten Regressionslauf sichten | 12 Stunden, 3 Personen | Minuten |
| Neuen Test aus einem Jira-Ticket schreiben | Je 2 bis 4 Stunden | Minuten |
| Bug nach Regression mit Belegen melden | Je 30 bis 60 Minuten | Automatisch |
| Hotfix-Release freigeben | Ein halber Tag | Minuten |
Der Wert liegt nicht in der Zeit, die bei einer einzelnen Zeile gespart wird. Er liegt darin, dass Wochen manueller Arbeit im Release-Zyklus gar nicht mehr vorkommen.
Warum ein Mac mini und kein Linux-Server
Der Agent läuft nativ auf einem dedizierten Mac mini. Kein Docker, kein Kubernetes, kein Cluster. Nach außen kommt er über einen Cloudflare Tunnel.
Das war eine Entscheidung, getroffen nach dem Vergleich mit einem Linux-VPS:
- Browser laufen schneller. Auf Apple silicon liefen Chrome und Cypress drei- bis fünfmal schneller als auf dem VPS.
- Der Agent arbeitet im echten Repository. Er liest und schreibt die Testdateien direkt, daher braucht das Erzeugen einer neuen Spec keine zusätzliche API-Schicht.
- Nichts zu simulieren. Ein Mac hat einen echten Display-Stack, also muss kein virtueller Display-Server am Leben gehalten werden, nur um einen Browser zu öffnen.
- Platz für lokale Modelle. Kleine Modelle auf der Neural Engine des Mac können Routing und einfache Klassifizierung übernehmen, und das größere Cloud-Modell bleibt dem Nachdenken vorbehalten, das es braucht.
Der VPS hätte 43 Dollar pro Monat weniger gekostet. Das ist weniger als der Entwicklertag, den der Umzug kosten würde.
Was das bedeutet, wenn Sie einen Agenten bauen
- Geben Sie dem Agenten eine eigene Maschine. Er braucht einen Browser, ein Dateisystem und die Freiheit, stundenlang zu laufen, ohne dass ihn jemand abmeldet oder neu startet.
- Fangen Sie mit der Arbeit an, die niemand machen will. Triage und Testreparatur waren der Engpass, nicht das Schreiben neuer Features.
- Lassen Sie einen Menschen das Urteil fällen. Der Agent klassifiziert und empfiehlt. Das Team entscheidet, ob ein Release ausgeliefert wird.
- Wählen Sie die Hardware passend zur Arbeit. Wenn Ihr Agent einen Browser steuert oder für Apple-Plattformen baut, macht sich Apple silicon schnell bezahlt.
Der QA-Agent von PerfectApps wurde für den internen Einsatz gebaut und läuft auf einem dedizierten Mac mini bei MacDuty.
Heute auf Lager
Diese stehen jetzt im Rack. Wählen Sie einen, sehen Sie, was dazugehört, und legen Sie Ihr Konto erst bei der Bestellung an.
Racks werden geprüft
Ein eigener Mac mini
Wählen Sie eine Konfiguration. Wenn eine nicht vorrätig ist, hinterlassen Sie Ihre E-Mail, und wir schreiben Ihnen an dem Tag, an dem sie ins Rack kommt.
Jährlich: mindestens 19 % günstiger als monatlich
Als Nächstes