Open Source: Mit Bedacht
Wer Open-Source-Software nutzt, prüft Lizenzen, Support und Qualität selbst. Die Community lebt vom Zurückgeben, Tester helfen dabei mit Bugreports.
Architektur, Integration & Datenqualität
Qualität hängt oft weniger an einzelnen Funktionen als am Zusammenspiel: an Schnittstellen, über Jahre gewachsenen Altsystemen, Datenflüssen und Architekturentscheidungen, die ein System testbar machen oder eben nicht. Dieser Themenbereich betrachtet Softwarequalität aus der Perspektive von Architektur, Integration und Daten.
Die Artikel und Podcastfolgen reichen von Microservices, Contract Tests und Cloud-Migrationen über technische Schulden, Legacy-Systeme und Architekturdokumentation bis zu Testdatenmanagement, synthetischen Testdaten, Data-Warehouse-Tests und der Bewertung von Datenqualität. Sie richten sich an Menschen in Architektur, Entwicklung und Test, die Qualität schon beim Entwurf von Strukturen und Datenflüssen mitdenken. Die Grundlagenseite zum Integrationstest bietet den methodischen Einstieg.
Grundlagen
Artikel
Tester lieben Software-Architektur
Software-Architektur ist ein Grundpfeiler für Testbarkeit und muss mitwachsen. Tester und Architekten sollten deshalb öfter gemeinsam Kaffee trinken.
Wenn KI programmiert
Braucht KI eigene Programmiersprachen? Warum menschenlesbarer Code nur ein Zwischenstadium sein könnte und welche Rolle Entwicklern bleibt.
Additive Bias in der Software-Entwicklung
Der Additive Bias lässt Teams Features, Code und Testfälle lieber ergänzen als löschen. Die Folgen: Komplexität, technische Schulden, Feature Fatigue.
(Test)datenradikalkur
Eine Testdaten-Radikalkur kommt vor der KI. Datenmengen, Schemas und Datenschutz bremsen das Testdatenmanagement, KI allein löst das nicht.
KI-Systeme testen: Qualität muss neu definiert werden
KI-Systeme testen heißt, Qualität neu zu definieren. Zugleich hilft KI im Softwaretest bei Testfällen, Testdaten und Fehleranalyse. Ein Zwischenstand.
SAP-Testing: Geschäftsprozesse bestimmen die Teststrategie
SAP-Testing setzt bei Geschäftsprozessen und Risiken an. PRACTICES UP deckt elf Fokusbereiche ab, fünf Datenklassen ordnen die Testdaten.
Hysterisch gewachsen – und nun?
Legacy-Systeme wachsen mit Adaptern und Wrappern zu technischen Schulden. Modernisiert wird selten: Features, Politik und fehlender ROI bremsen.
Data-Warehouse-Test: Assertions aus Transformationsregeln
Im Data-Warehouse-Test gibt es keine Oberfläche. Assertions entstehen deshalb aus den Transformationsregeln, sortiert in sieben Regelklassen.
Systemarten in der Testautomatisierung: Desktop bis Cloud
Systemarten bestimmen Ansatz und Tools der Testautomatisierung. Desktop, Client-Server, Web, Mobile und Data Warehouse stellen je eigene Ansprüche.
Bye bye kompliziert – Hello komplex
Aus kompliziert wurde komplex, Ursache und Wirkung sind kaum noch eindeutig. Die größte Hürde beim agilen Arbeiten ist die Angst vor Kontrollverlust.
Testdimensionen für Integrationstests: Lücken erkennen
Testdimensionen für Integrationstests: Testziele, Testobjekte, Testebene, Testbasis und typische Fehler zeigen, wo die Tests noch Lücken haben.
Objektorientierung: Versprechen nur zum Teil eingelöst
Objektorientierung sollte Produktivität, Wartung, Wiederverwendung und Portabilität revolutionieren. Studien zeigen: Das gelang nur zum Teil.
Technische Schulden: Agile Tester müssen sie eingrenzen
Technische Schulden sind messbare Kosten mangelhafter Software. Agile Tester grenzen sie mit Story-Reviews, Codeprüfung, CI und Done-Kriterien ein.
Cloud-Services testen: Statische und dynamische Analyse
Cloud-Services testen, ohne alles zu prüfen: Der Fokus liegt auf betriebsrelevanten Funktionen und darauf, wie fremde Services zusammenspielen.
Datenqualität bewerten: Drei Audits für Kundendatenbanken
Datenqualität bewerten: Drei automatisierte Audits prüfen Schema, Struktur und Inhalt. Die Metriken zeigen, wann eine Bereinigung nötig ist.
UML-Metriken: Größe, Komplexität und Qualität messen
UML-Metriken zählen, was in jedem UML-Diagramm steckt, und machen Größe, Komplexität und Qualität messbar, lange bevor das System fertig ist.
Migrationstest: Das neue System muss tun, was das alte tat
Ohne Spezifikation misst der Migrationstest das neue System am Altsystem. Sieben Schritte von Code-Messung bis Abdeckung belegen die Gleichheit.
Testcenter: Testaktivitäten im Unternehmen bündeln
Ein Testcenter bündelt verteilte Testaktivitäten im Unternehmen. Kompetenz, Besetzung, Infrastruktur und Integration machen Qualität planbar.
Geoportale testen: Dienste und Clients nach ISTQB-Prozess
Geoportale testen: Geodienste und Clients getrennt prüfen, auf Funktionalität, Usability, Effizienz und Sicherheit im Umgang mit Geodaten.
Webservices testen: Anfragen generieren, Antworten prüfen
Webservices testen mit WSDLTest: Testdaten kommen aus dem WSDL-Schema, Vorbedingungen steuern Anfragen, Nachbedingungen prüfen Antworten.
Podcastfolgen
KI-generierter Code: Qualitätssicherung muss mitwachsen
KI-generierter Code heißt mehr Code und statistisch mehr Fehler. Nur rund 30 Prozent der KI-Review-Kommentare taugen, die Prüfung muss mitwachsen.
Warum vollständige Coverage keine Fehlerfreiheit garantiert
100 Prozent Branch Coverage und trotzdem Bugs: Was das über Code Coverage als Metrik sagt und warum am Ende die Assertions entscheiden.
API Testing: Agentenoptimiertes Design senkt Token-Kosten
API Testing liefert stabileres Feedback als Frontend-Tests. Wer REST, GraphQL, Webhooks und MCP kennt, testet gezielter und spart Tokens.
Testen komplexer Systeme: Klein releasen, schnell lernen
Software ist keine Brücke: Beim Testen komplexer Systeme geht es ums Lernen. Nach Cynefin helfen kleine, häufige Releases mehr als ein großes.
Holistic Engineering: Nicht-technische Faktoren prägen Code
Holistic Engineering bezieht Karriere-Frameworks, Lieferdruck und Teamkultur in Architekturentscheidungen ein, denn sie wirken mehr als Designmuster.
Fitness Functions: Wie Softwarearchitektur testbar wird
Fitness Functions machen Architekturentscheidungen automatisch prüfbar. Welche Typ-1-Entscheidungen fix bleiben und welche sich ändern dürfen.
Innovationsstau: Zu viele Prozesse lähmen Konzerne
Innovationsstau in Konzernen: Genehmigungen für jede Reise kosten Fokus, KI rechnet sich nicht auf Dateninseln. Kleine, freie Teams sind ein Ausweg.
COBOL-Unit-Tests: Java-Tests laufen im Mainframe-Debugger
COBOL-Unit-Tests schreiben viele Entwickler lieber in Java. Ein Tool übersetzt sie in Debugger-Skripte und bindet Jenkins und SonarQube an.
Chatbot-Testen: Warum Fehler in Prompt und Abruf stecken
Chatbot-Testen bricht mit der klassischen Testlogik: gleiche Eingabe, andere Ausgabe. Wer die abgerufenen Chunks protokolliert, findet die Fehler.
Agentic Engineering: KI beschleunigt vorhandene Prinzipien
Wer schlechte Prinzipien hat und AI einsetzt, wird schneller schlechter. Warum Agentic Engineering mehr als Codegenerierung braucht.
Blauer Engel für Software: Transparenz statt Bestnote
Der Blaue Engel für Software fordert offene Energiewerte, alte Hardware als Basis, lange Updates. Was die Zertifizierung kostet, wie lange sie dauert.
Smartphone-Sicherheit: vom Abhören bis zu Overlay-Angriffen
Smartphone-Sicherheit hat oft versagt, vom Abhören analoger Anrufe bis zu Overlay-Angriffen. Heute nutzen Angreifer vor allem großzügige App-Rechte.
Testreporting mit 3x3-Matrix reicht in 95 Prozent der Fälle
Testreporting in 5 Schritten: Ziel, Position, Prognose, Datenqualität und Automatisierung. So wird das Reporting zum echten Steuerungswerkzeug.
Entwurfsmuster im Testcode: Schluss mit Spaghetti-Code
Entwurfsmuster halten Testcode wartbar wie Produktionscode. Page Object, Builder und Facade geben Struktur, KISS und YAGNI verhindern Überdesign.
Process Mining macht Testabdeckung zur zählbaren Größe
Process Mining macht Testabdeckung messbar. Bei einem Workflow mit über 600 Durchläufen decken die häufigsten zehn rund 80 Prozent der Fälle ab.
Qualitätssicherung in Startups: Testbarkeit statt Prozesse
Qualität im Startup entsteht nicht durch Prozesse, sondern durch Haltung. Warum Tester dabei lauter sein müssen als Entwickler.
Pekka Klärck: Ein generischer Kern für heterogene Systeme
Pekka Klärck begann Robot Framework 2004 als Masterarbeit. Heute pflegt es eine Stiftung mit rund 85 Mitgliedern, der Anteil aus Deutschland wächst.
Thermomanagement im E-Auto: Früher testen mit HiL und VECU
Thermomanagement im E-Auto früher testen: HiL und virtuelle ECU nutzen dieselben Testfälle, bei bis zu 200 möglichen Systemverschaltungen.
Contract Testing: Der Consumer legt fest, was er erwartet
API-Schnittstellen brechen still weiter oder fallen früh auf, je nach Testansatz. Contract Testing stoppt riskante Änderungen im Build.
Tools sind keine Lösung für die Testautomatisierung
Ein Spielehersteller zählte in acht Wochen fast 5.000 Fehlerzustände. Das ändert eine bessere Testautomatisierungsstrategie, kein neues Tool.
Windturbinen testen: Wetter und Blitze prüft man im Feld
Windturbinen testen: 164 Subsysteme, vom Hardware-in-the-Loop-Simulator bis zur Kundenanlage. Japan verlangt nach jedem Blitz einen Stopp.
Dynamische Analyse: Code Coverage mit Embedded Trace
Dynamische Analyse für Embedded-Systeme: Embedded Trace misst Code Coverage im Integrationstest auf echter Hardware, ohne das System zu stören.
Codequalität im Studium: Tests brauchen komplexe Projekte
Codequalität im Studium: Tests überzeugen erst in komplexen Projekten. Coverage ist kein Selbstzweck, und ChatGPT stellt den Sinn von Tests infrage.
Wert des Softwaretests: Umsatz schlägt Codeüberdeckung
Den Wert des Softwaretests sehen Manager erst, wenn Tester ihn in Umsatz und Nutzerzufriedenheit begründen. Mit KI zählt Domänenwissen noch mehr.
Testmigration: Wenn die Cloud-Kosten das QA-Budget sprengen
Die Testmigration von Cypress zu Playwright begann bei Displate mit den Kosten der Cypress Cloud. Die kritischen Pfade zogen zuerst um.
Developer Friendliness: Zeit investieren, Zeit sparen
Developer Friendliness kostet kurzfristig Zeit, spart sie langfristig und macht Teams glücklicher. REST-Mocks und Testschnittstellen zeigen es.
Sicherheit durch Design: IT-Sicherheit gehört in den Entwurf
Sicherheit durch Design baut IT-Sicherheit von Anfang an ein: mit Bedrohungsmodellierung, sicheren Defaults und bewährten Bibliotheken statt Eigenbau.
Synthetische Testdaten aus Schemas: DSGVO-konform testen
Synthetische Testdaten aus XML- und JSON-Schemas decken Extremwerte ab, die Produktivdaten nie liefern, samt Fehlerbeispielen aus der E-Rechnung.
Legacy-Modernisierung, wenn die Experten fehlen
Bei der Legacy-Modernisierung fehlen oft die Fachexperten, nicht die Technik. Wie Umbau in Scheiben, Tests und RAG das Wissen im Altcode heben.
Robot Framework: wofür es sich heute noch lohnt
Robot Framework verbindet Web, Desktop, Datenbank und 3270-Hosts in End-to-End-Tests. Wo es stark ist, wo Web-Tools aufhören und warum es bleibt.
Enterprise Testing prüft die Wirkung von Konfigurationen
Wer SAP konfiguriert, testet im Grunde immer Nebenwirkungen im gesamten Zielsystem mit. Warum Enterprise-Testing eigene Regeln braucht.
Microservices testen bei REWE: Weniger End-to-End-Tests
Microservices testen mit Unit-Tests, API Testing je Service und wenigen E2E-Tests. Flaky Tests gehen in Quarantäne, Monitoring ersetzt lange Suiten.
Prüfung von KI-Systemen: Eine Matrix ordnet das Prüffeld
Die Prüfung von KI-Systemen braucht Ordnung: Die AI Assessment Matrix des TÜV AI Lab legt Prüfdimensionen gegen den Daten- und Modell-Lifecycle.
Cypress zu Playwright bei Displate: Migration in Schichten
Cypress zu Playwright migrieren: Warum ein Team-Hackathon mit 7 Tools die naheliegende Wahl erst zum sicheren Ergebnis machte.
Risikobasiertes Testen bei Bison: Weniger End-to-End-Tests
50 bis 60 Prozent weniger End-to-End-Tests durch risikobasiertes Testen: wie das funktioniert und wo man konkret anfängt.
UI-Testing mit Mock-Responses: Frontend ohne Backend testen
UI-Testing mit gemockten API-Antworten braucht kein Backend. Bei Volkswagen laufen so 280 Tests in unter drei Minuten, stabil und parallel.
CI/CD-Pipelines in Embedded C: Tests als Sicherheitsnetz
CI/CD-Pipelines für Embedded C mit CMake, Google Test und generierten Mocks. Jeder Bugfix beginnt mit einem Test, der den Fehler nachstellt.
Warum ist Code so schwer zu verstehen?
Warum versteht dein Gehirn manchen Code nicht? Das Arbeitsgedächtnis fasst nur vier Chunks. Guter Code respektiert genau diese enge Grenze.
Barrierefreiheit manuell prüfen: Tools reichen nicht aus
Barrierefreiheit manuell prüfen: Barrierefreie Komponenten ergeben keine barrierefreie Anwendung. Warum Screenreader-Tests mit Betroffenen bleiben.
Software-Analyse: Altsystem bewerten, bevor du es kaufst
Software-Analyse bei einer Übernahme: Ein Drittel des Codes liegt nur als Kompilat vor. Was statische Analyse in eineinhalb Tagen verrät.
Shift Left vs Shift Right: Du musst dich nicht entscheiden
Shift Left parallelisiert das Testen vor dem Go-live, Shift Right beobachtet die Produktion. Ein Versicherer nutzt dieselben UI-Tests für beides.
Datenprozesse testen: Soll-Ergebnisse aus der Spezifikation
Datenprozesse testen: Testdaten aus der Produktion decken nur rund 70 Prozent der Fälle ab. Die Sollwerte kommen aus der Fachspezifikation.
Business Analyst im Data Warehouse: Grenzfälle früh erkennen
Ein Business Analyst aus dem Testing hinterfragt Anforderungen im Data Warehouse, bevor Code entsteht. Tester prüfen auch seine Spezifikation.
Embedded Testing: Was ohne echte Hardware geht, was nicht
Embedded Testing beginnt, bevor die Hardware da ist. Warum Simulatoren am Timing scheitern und wann echte Zielhardware in die CI-Pipeline gehört.
Modellbasierte Formulartests: Testdaten per SMT-Solver
Formulartests für 255 Formularvarianten in 16 Bundesländern: Ein SMT-Solver erzeugt valide Testdaten aus den Regeln und findet Widersprüche.
Documentation as Code: Architekturdoku wie Quellcode
Documentation as Code hält Architekturdokumentation aktuell: Textformate wie AsciiDoc, Versionierung mit Git und Continuous Documentation im Build.
KI-Testen: Determinismus entscheidet über die Teststrategie
KI testen klingt komplex, reduziert sich aber auf eine Frage: deterministisch oder nicht? Was das ganz konkret für die Teststrategie heißt.
Robot Framework statt Eigenbau: Wie gelingt der Umstieg?
Robot Framework löst einen XML-Monolithen ab: rund ein Jahr Umbau, ein eigener Remote-Library-Server für .NET und Belege, die Kollegen überzeugen.
Testpyramide: Testschichten ergänzen sich ohne Doppelung
Die Testpyramide wird oft falsch angewendet: viele Unit-Tests, hohe Testabdeckung, trotzdem Bugs. Wann Integrationstests die bessere Wahl sind.
Qualitätsanforderungen brauchen eine änderbare Architektur
Funktionale und Qualitätsanforderungen trennen: sinnvoll oder irreführend? Was diese Unterscheidung für Architekturentscheidungen wirklich bedeutet.
Teststrategie: Wie wenig reicht wirklich?
Eine Teststrategie in drei Workshops: eine Testlandkarte mit Rollen, Tools, Umgebungen und Metriken statt hundert Seiten, die keiner liest.
Testdatenmanagement: Tester bestellen Daten selbst
Testdatenmanagement nach dem Shop-Prinzip: Tester bestellen anonymisierte Daten per Self-Service, statt fünf bis sechs Insellösungen zu pflegen.
Zero Trust bei der Telekom: Von 30 auf 3 Identity Provider
Zero Trust ist mehr als ein Buzzword: Wer es nicht selbst definiert, redet aneinander vorbei. Was das konkret bedeutet und wo man anfängt.
Testfälle aus Regeln: Warum verteilte Systeme sie brauchen
Testfälle aus Regeln decken bei verteilten Systemen Millionen Fehlerkombinationen ab. Ein Shrinker kürzt Fehler auf den kleinsten Schritt.
Metriken der Softwarequalität: Zahlen brauchen einen Bezug
Metriken der Softwarequalität zeigen oft unbequeme Wahrheiten. Dabei reicht eine Tabelle, um Testaufwand und Fehler zu prognostizieren.
Sind Architekturentscheidungen Sache des ganzen Teams?
Architekturentscheidungen treffen Teams oft unbewusst beim Coden. Drei Experimente zeigen, wie das gemeinsam und nachvollziehbar gelingt.
Domain Storytelling: Konversation statt Pflichtenheft
Domain Storytelling: Fachexperten erzählen Geschichten aus der Domäne, das Team zeichnet sie grafisch auf. So ersetzt das Gespräch das Pflichtenheft.
Cloud-Migration: Schrittweise schneiden statt neu bauen
Cloud-Migration klingt nach Technik, ist aber zum großen Teil eine Organisationsfrage. Monolithen, DBAs und Silos bremsen häufig am meisten.
Sociable Unit Tests: Use Cases bis zur Datenbank prüfen
Sociable Unit Tests prüfen ganze Use Cases vom UI-Einstieg bis zur echten Datenbank. Mocks taugen nur für externe Systeme, Testdaten-Builder helfen.
C++ Core Guidelines: Ownership ist die wichtigste Regel
Die C++ Core Guidelines von Stroustrup und Sutter klären, wem eine Ressource gehört. Makros sollen weg, Refactoring lohnt in Medizintechnik selten.
Audio-KI testen: Jeder Fehler kostet ein neues Training
Audio-KI testen, ohne in den Code schauen zu können: Warum goldene Testsätze, Trainingsdaten-Tracking und ChatGPT dabei eine Rolle spielen.
Contract-Based Testing: Breaking Changes früh erkennen
Contract-Based Testing macht Breaking Changes an Schnittstellen früh sichtbar. Provider und Consumer testen gegen denselben Kontrakt im Pact Broker.