Das Testen einer Anwendung kurz vor der Veröffentlichung reicht laut einem auf dem JetBrains-Blog veröffentlichten Beitrag von Kerry Beetge nicht mehr aus, um die Qualität moderner Software zu gewährleisten. Die zentrale Idee besteht darin, Qualitätsprüfungen über den gesamten Lebenszyklus der Softwareentwicklung zu verteilen, sodass Fehler näher an dem Zeitpunkt sichtbar werden, an dem sie eingeführt wurden, statt erst nach der Ansammlung zusätzlicher Änderungen und Komplexitäten entdeckt zu werden.
Der Beitrag bringt diesen Wandel mit der zunehmenden Nutzung von durch künstliche Intelligenz generiertem Code in Verbindung. Unter Berufung auf eine Stack-Overflow-Umfrage aus dem Jahr 2025 wird darauf hingewiesen, dass 84 % der Entwickler Werkzeuge der künstlichen Intelligenz im Entwicklungsprozess nutzen oder deren Nutzung planen. JetBrains zufolge macht die zunehmende Menge des von diesen Werkzeugen erzeugten Codes wiederholte und skalierbare Überprüfungen wichtiger, wobei die menschliche Validierung aufgrund der Möglichkeit, dass Fehler in das automatisch erzeugte Ergebnis gelangen, weiterhin unverzichtbar bleibt.
Vom Tor vor der Veröffentlichung zur kontinuierlichen Qualitätssicherung
Der Beitrag unterscheidet zwischen Software-Qualitätssicherung (SQA), die die Einhaltung von Anforderungen an Betrieb, Zuverlässigkeit, Sicherheit und Standards während des gesamten Entwicklungszyklus verfolgt, und der traditionellen Qualitätskontrolle (QC), die sich meist auf das Endprodukt konzentriert und Fehler reaktiv behandelt. Der kontinuierliche Ansatz ermöglicht es, Probleme während des Schreibens oder der Integration des Codes zu erkennen, wenn ihre Behebung kostengünstiger ist und stärker mit dem ursprünglichen Kontext der Änderung zusammenhängt.
Der Beitrag weist darauf hin, dass sich Veröffentlichungszyklen in modernen Entwicklungsumgebungen von Monaten auf Tage verkürzt haben, während CI/CD-Pipelines die Überführung von Code vom Commit in die Produktion mit begrenztem menschlichem Eingreifen ermöglichen. Daher reicht es nicht aus, sich auf ein einziges Werkzeug zu verlassen; jede Testschicht deckt eine andere Art von Problemen auf.
Was decken die Werkzeuge praktisch ab?
- Statische Analyse: Sie untersucht den Code, ohne ihn auszuführen, um Fehler, Schwachstellen und Verstöße gegen Codierungsstandards zu erkennen. Ein Beispiel dafür ist Qodana.
- Unit-Tests: Sie überprüfen die Funktion einzelner Funktionen und Komponenten. Beispiele sind JUnit, Jest, PyTest und NUnit.
- Integrationstests: Sie prüfen das Zusammenspiel von Diensten und APIs sowie den Datenfluss. Zu den Werkzeugen gehören Postman und Soap UI.
- Funktionstests und Benutzeroberflächentests: Sie simulieren Benutzerabläufe über den Browser und verwenden Werkzeuge wie Playwright, Cypress und Selenium.
- Performancetests: Sie messen das Verhalten unter Last und helfen dabei, Engpässe, Speicherlecks und langsame Abfragen aufzudecken, wobei Werkzeuge wie JMeter, LoadRunner und k6 zum Einsatz kommen.
- Sicherheitstests: Sie kombinieren SAST, SCA, die Überprüfung von Abhängigkeiten und DAST sowie die Erkennung versehentlich eingefügter Geheimnisse oder API-Schlüssel.
Wie werden Werkzeuge ausgewählt und in die Arbeit integriert?
Der Beitrag schlägt vor, Werkzeuge anhand ihrer Integration in CI/CD, ihrer Unterstützung der verwendeten Sprachen und Frameworks, ihrer Fähigkeit zur Automatisierung wiederkehrender Aufgaben, ihrer Skalierbarkeit mit dem Wachstum von Code und Teams, der Bereitstellung umsetzbarer Berichte sowie der Sicherheitspraktiken des Werkzeugs selbst zu bewerten.
Auf Umsetzungsebene empfiehlt der Beitrag, Prüfungen in den Zeitpunkt des Schreibens des Codes zu verlagern, wiederkehrende Tests zu automatisieren, sie bei jedem Commit oder Build auszuführen und die technische Schuld anhand von Kennzahlen wie Codekomplexität, Duplizierung und Testabdeckung zu überwachen. Außerdem wird betont, dass Sicherheitsprüfungen in den regulären Qualitätssicherungsprozess aufgenommen und nicht auf eine separate Überprüfung vor der Veröffentlichung verschoben werden sollten.
Einordnung von certi.news
Die tatsächliche Veränderung, die der Beitrag vorschlägt, besteht nicht in der Hinzufügung eines neuen Tests, sondern in der Neuverteilung der Qualitätsverantwortung innerhalb des Entwicklungszyklus. Dieser Ansatz ist für Teams hilfreich, die mit kurzen Veröffentlichungszyklen arbeiten oder auf verteilte Architekturen und externe Abhängigkeiten setzen, hebt jedoch manuelle Tests oder das technische Urteilsvermögen nicht auf. Automatisierung, insbesondere auf künstlicher Intelligenz basierende, kann zwar die Erkennung von Problemen beschleunigen, garantiert allein jedoch weder eine vollständige Abdeckung noch die Richtigkeit der Ergebnisse. Außerdem bietet die Quelle allgemeine Leitlinien und Beispiele für Werkzeuge, legt jedoch keinen quantitativen Rahmen für deren Abwägung fest und weist keine unabhängigen Vergleichsergebnisse zur Leistung nach.