ISO 25010 und 25059 im Kontext Softwarequalität
von Rainer Haupt
TL;DR: ISO 25010:2023 definiert 9 Hauptqualitätsmerkmale (nicht 8 wie in der 2011-Version) mit 40 Untermerkmalen für Software-Produktqualität. ISO 25059:2023 erweitert dieses Modell um 6 KI-spezifische Untermerkmale für AI/ML-Systeme. Beide Normen zusammen bilden ein vollständiges Qualitätsframework, das sich systematisch auf Testarten und Automatisierungstools mappen lässt.
Lesedauer ca. 14 Min · Stand: 2026-04
Qualität messbar zu machen, ohne sich in Marketing-Begriffen zu verlieren, ist eine alte Disziplin. Das SQuaRE-Framework der ISO/IEC-25000-Reihe liefert dafür die formale Grundlage. Mit der Revision von ISO 25010 im Jahr 2023 und der KI-Erweiterung ISO 25059 im selben Jahr ist das Modell wieder anschlussfähig — auch für Teams, die heute LLM-Komponenten in ihre Anwendungen integrieren. Dieses Dossier ordnet beide Normen, mappt sie auf konkrete Testarten und Werkzeuge und zeigt, wo Automatisierung trägt und wo nicht.
ISO/IEC 25010:2023 im Überblick
Alle 9 Hauptmerkmale und 40 Untermerkmale
| # | Hauptmerkmal | Untermerkmale |
|---|---|---|
| 1 | Functional Suitability | Functional Completeness · Functional Correctness · Functional Appropriateness |
| 2 | Performance Efficiency | Time Behaviour · Resource Utilization · Capacity |
| 3 | Compatibility | Co-existence · Interoperability |
| 4 | Interaction Capability (ehem. Usability) | Appropriateness Recognizability · Learnability · Operability · User Error Protection · User Engagement · Inclusivity · User Assistance · Self-descriptiveness |
| 5 | Reliability | Faultlessness · Availability · Fault Tolerance · Recoverability |
| 6 | Security | Confidentiality · Integrity · Non-repudiation · Accountability · Authenticity · Resistance |
| 7 | Maintainability | Modularity · Reusability · Analysability · Modifiability · Testability |
| 8 | Flexibility (ehem. Portability) | Adaptability · Scalability · Installability · Replaceability |
| 9 | Safety (NEU) | Operational Constraint · Risk Identification · Fail Safe · Hazard Warning · Safe Integration |
Was sich von 2011 auf 2023 geändert hat
| Aspekt | 2011 | 2023 |
|---|---|---|
| Hauptmerkmale | 8 | 9 (Safety neu) |
| Untermerkmale | 31 | 40 |
| Usability | Eigenständig, 6 Untermerkmale | Umbenannt → Interaction Capability, 8 Untermerkmale |
| Portability | Eigenständig, 3 Untermerkmale | Umbenannt → Flexibility, 4 Untermerkmale |
| Safety | Nicht vorhanden | Komplett neu, 5 Untermerkmale |
| Quality-in-Use | In 25010 enthalten | Ausgelagert in ISO 25019:2023 |
| Scope | Nur Software/Computersysteme | Erweitert auf alle ICT-Produkte |
Umbenannte Untermerkmale: Maturity → Faultlessness (unter Reliability), User Interface Aesthetics → User Engagement (unter Interaction Capability).
Neue Untermerkmale neben Safety: Inclusivity (aus Accessibility herausgelöst), User Assistance (aus Accessibility herausgelöst), Self-descriptiveness (komplett neu), Resistance (unter Security neu), Scalability (unter Flexibility neu).
Gestrichen: Accessibility (aufgesplittet in Inclusivity + User Assistance).
Mapping Qualitätsmerkmal auf Testart
| Qualitätsmerkmal | Testarten |
|---|---|
| Functional Suitability | Unit-Tests · Integrationstests · End-to-End-Tests · API-Tests · Akzeptanztests · Regressionstests |
| Performance Efficiency | Lasttests · Stresstests · Soak-Tests · Spike-Tests · Benchmarks · Kapazitätstests |
| Compatibility | Cross-Browser-Tests · Cross-Platform-Tests · API-Contract-Tests · Interoperabilitätstests · Koexistenztests |
| Interaction Capability | Accessibility-Tests · Usability-Tests · Visual-Regression-Tests · UX-Heuristic-Evaluation |
| Reliability | Chaos Engineering · Fault Injection · Recovery-Tests · Verfügbarkeitsmonitoring · Failover-Tests · Soak-Tests |
| Security | SAST · DAST · SCA · IAST · Penetrationstests · Vulnerability Scanning · Secret Detection · Container Scanning |
| Maintainability | Statische Codeanalyse · Komplexitätsmetriken · Duplikat-Erkennung · Architektur-Compliance · Code Reviews |
| Flexibility | Installationstests · Migrationstests · Konfigurationstests · Cross-Environment-Tests · Skalierungstests |
| Safety | HAZOP · FMEA · Fehlerbaumanalyse · Fail-Safe-Verifikation · Formale Verifikation |
Automatisierungspotenzial nach Merkmal
| Merkmal | Automatisierungsgrad | Begründung |
|---|---|---|
| Functional Suitability | Sehr hoch | Reifste Toollandschaft, CI/CD-Kern |
| Performance Efficiency | Sehr hoch | Threshold-basierte Pass/Fail-Gates möglich |
| Maintainability | Sehr hoch | Statische Analyse auf jedem Commit |
| Security | Hoch | SAST/DAST/SCA automatisiert; Pentests manuell |
| Reliability | Hoch | Chaos Engineering in CI/CD integrierbar |
| Compatibility | Hoch | Cross-Browser automatisiert; Koexistenz schwieriger |
| Flexibility | Mittel-hoch | IaC/Container helfen; Migration komplex |
| Interaction Capability | Niedrig-mittel | Nur ~30–40 % der WCAG-Probleme automatisiert erkennbar |
| Safety | Niedrig | Experten-getriebene Analyse; formale Verifikation teilweise |
ISO/IEC 25059:2023 — das Qualitätsmodell für KI-Systeme
Eckdaten
ISO 25059:2023 («Quality model for AI systems») wurde im Juni 2023 als Erstausgabe vom JTC 1/SC 42 (Artificial Intelligence) veröffentlicht. Die Norm referenziert ISO/IEC 25010:2011 (nicht 2023) — eine DIS-Revision, die auf 25010:2023 referenziert, ist in Arbeit. Scope: anwendungsspezifische Erweiterung des SQuaRE-Frameworks für KI/ML-Systeme.
Architekturentscheidung
ISO 25059 behält alle 8 Hauptmerkmale aus ISO 25010:2011 bei und fügt keine neuen Hauptmerkmale hinzu. Das Modell erweitert um 5 neue + 1 modifiziertes Untermerkmal in der Produktqualität sowie 2 neue Untermerkmale im Quality-in-Use-Modell.
KI-spezifische Untermerkmale — Produktqualität
| Untermerkmal | Typ | Zugeordnet zu | Bedeutung |
|---|---|---|---|
| Functional Adaptability | NEU | Functional Suitability | Lernen aus Daten, Anpassung an Umgebungsänderungen |
| Functional Correctness | MODIFIZIERT | Functional Suitability | Fehlerrate bei KI erwartbar; Correctness und Incorrectness messen |
| Transparency | NEU | Usability | Informationen über KI-System für Stakeholder zugänglich |
| User Controllability | NEU | Usability | Nutzer kann in KI-Funktion rechtzeitig eingreifen |
| Robustness | NEU | Reliability | Korrektheit trotz adversarialer oder fehlerhafter Eingaben |
| Intervenability | NEU | Security | Operator kann zur Schadensverhinderung eingreifen |
KI-spezifische Untermerkmale — Quality in Use
| Untermerkmal | Typ | Zugeordnet zu | Bedeutung |
|---|---|---|---|
| Transparency | NEU | Satisfaction | Verständnis der Systemfunktion für Endnutzer |
| Societal & Ethical Risk Mitigation | NEU | Freedom from Risk | Fairness, Accountability, Explainability, Privacy, menschliche Kontrolle, professionelle Verantwortung |
Testherausforderungen für KI-Systeme
| Herausforderung | Ursache | Betroffenes Merkmal |
|---|---|---|
| Test-Orakel-Problem | Erwartetes Ergebnis bei ML oft unklar | Functional Correctness |
| Non-Determinismus | Gleicher Input ≠ gleicher Output | Functional Correctness |
| Concept Drift | Datenverteilung ändert sich über Zeit | Functional Adaptability |
| Data Drift | Input-Features verschieben sich statistisch | Functional Adaptability |
| Adversarial Attacks | Gezielte Manipulation der Eingaben | Robustness |
| Black-Box-Modelle | Interne Logik nicht inspizierbar | Transparency |
| Niedrige Testbarkeit | Geringe Transparenz erschwert Testing | Transparency |
| Bias-Erkennung | Diskriminierung in Trainingsdaten versteckt | Societal Risk Mitigation |
| Zeitkritische Eingriffe | Autonome Systeme reagieren schnell | Intervenability, Controllability |
| Modell-Regression | Retraining verschlechtert Teilmetriken | Functional Correctness |
Ansätze und Tools für KI-Tests
| Qualitätsmerkmal | Testansatz | Tools |
|---|---|---|
| Functional Correctness | ML-Metriken (Accuracy, Precision, Recall, F1, AUC-ROC), Cross-Validation | MLflow, Deepchecks, scikit-learn metrics |
| Functional Adaptability | Data-Drift-Monitoring, Concept-Drift-Detection, Retraining-Validierung | Evidently AI, NannyML, WhyLabs, Alibi Detect |
| Robustness | Adversarial Testing, Noise Injection, Out-of-Distribution Detection | IBM ART, CleverHans, Giskard |
| Transparency | Explainability-Analyse, Log-Prüfung, Model Cards | SHAP, LIME, Fiddler AI |
| User Controllability | Override-Tests, Reaktionszeit für menschlichen Eingriff | UI-Testframeworks (Playwright, Cypress) |
| Intervenability | Kill-Switch-Tests, Safe-State-Transition-Tests | Chaos Engineering Tools + Custom Suites |
| Fairness/Bias | Gruppenvergleiche, Demographic Parity, Equalized Odds | Fairlearn, AIF360, Evidently AI |
| Data Quality | Schema-Validierung, Vollständigkeit, Freshness | Great Expectations, Deequ, Soda Core |
| LLM-Evaluation | Halluzinations-Erkennung, Toxizität, Relevanz | Ragas, DeepEval, Evidently AI |
Vergleich ISO 25010 versus ISO 25059
Strukturvergleich
| Aspekt | ISO 25010:2023 | ISO 25059:2023 |
|---|---|---|
| Scope | Alle ICT-Produkte | Speziell KI/ML-Systeme |
| Typ | Basisnorm | Anwendungserweiterung der Basisnorm |
| Hauptmerkmale Produktqualität | 9 | 8 (referenziert 25010:2011) |
| Untermerkmale Produktqualität | 40 | 31 + 5 neue + 1 modifiziertes = 37 |
| Quality-in-Use | Ausgelagert in ISO 25019 | Enthalten, 5 Hauptmerkmale + 2 neue Untermerkmale |
| Normative Referenz | Eigenständig | Basiert auf ISO 25010:2011 |
| Metriken | Definiert in ISO 25023 | Eigene TS in Entwicklung (SC 42) |
Was ISO 25059 hinzufügt
| Hinzugefügt durch 25059 | Übergeordnetes Merkmal | Modell | Praxisrelevanz |
|---|---|---|---|
| Functional Adaptability | Functional Suitability | Produkt | Data-Drift-Monitoring, Retraining-Validierung |
| Functional Correctness (modifiziert) | Functional Suitability | Produkt | ML-Metriken statt binärer Pass/Fail |
| Transparency | Usability | Produkt | Explainability-Tests, Log-Audits |
| User Controllability | Usability | Produkt | Override-Mechanismus-Tests |
| Robustness | Reliability | Produkt | Adversarial Testing, Noise Injection |
| Intervenability | Security | Produkt | Kill-Switch-Tests, Notfall-Szenarien |
| Transparency | Satisfaction | Quality-in-Use | Endnutzer-Verständlichkeitstests |
| Societal & Ethical Risk Mitigation | Freedom from Risk | Quality-in-Use | Bias-Testing, Fairness-Metriken |
Konzeptuelle Unterschiede
| Aspekt | Klassische Software (25010) | KI-Systeme (25059) |
|---|---|---|
| Korrektheit | Binär: korrekt oder fehlerhaft | Probabilistisch: Fehlerrate erwartbar |
| Verhalten | Deterministisch, reproduzierbar | Nicht-deterministisch, lernend |
| Testdaten | Definierte Testfälle | Statistische Verteilungen, Driftüberwachung |
| Erklärbarkeit | Code ist inspizierbar | Black-Box-Modelle, Explainability nötig |
| Fehleranalyse | Stack Traces, Logs | Feature Importance, Confusion Matrices |
| Regression | Code-Änderungen verursachen Regression | Datenänderungen verursachen Regression |
| Bias | Kein Thema in der Norm | Zentrale Herausforderung (Societal Risk) |
| Sicherheitseingriff | Standard-Fehlermechanismen | Explizite Intervenability gefordert |
Praxisbezug — Tools und Teststrategie
Tool-Empfehlungen nach Qualitätsmerkmal
| Qualitätsmerkmal | Empfohlene Tools | Lizenz / Kosten |
|---|---|---|
| Functional Suitability | Playwright, Cypress, RestAssured, pytest, JUnit, Robot Framework | Alle OSS / kostenlos |
| Performance Efficiency | k6 (Grafana), Gatling, JMeter, Locust | OSS; Enterprise-Varianten verfügbar |
| Compatibility | Playwright (Multi-Browser), BrowserStack, Pact (Contract Testing) | Pact OSS; BrowserStack ab USD 29/Mo |
| Interaction Capability | axe-core, Pa11y, Lighthouse, Applitools Eyes | axe/Pa11y OSS; Applitools Freemium |
| Reliability | Gremlin, LitmusChaos, Chaos Mesh, ToxiProxy | Litmus/Chaos Mesh OSS; Gremlin ab USD 475/J |
| Security | OWASP ZAP, SonarQube, Snyk, Trivy, GitLeaks | ZAP/Trivy OSS; Snyk Freemium |
| Maintainability | SonarQube, ESLint/PMD, ArchUnit, CodeClimate | SonarQube Community OSS |
| Flexibility | Terraform/Ansible Test Suites, Container Structure Tests, InSpec | Alle OSS |
| Safety | LDRA, Parasoft, Polyspace (formale Verifikation) | Kommerziell, hoch |
| KI: Correctness | MLflow, Deepchecks, scikit-learn metrics | Alle OSS |
| KI: Adaptability/Drift | Evidently AI, NannyML, WhyLabs | Evidently OSS; WhyLabs Freemium |
| KI: Robustness | IBM ART, CleverHans, Giskard | Alle OSS |
| KI: Transparency | SHAP, LIME, Fiddler AI | SHAP/LIME OSS; Fiddler kommerziell |
| KI: Fairness/Bias | Fairlearn, AIF360, Evidently AI | Alle OSS |
| KI: Data Quality | Great Expectations, Deequ, Soda Core | GE/Deequ OSS; Soda Freemium |
Teststrategie auf Basis der Normen
Phase 1 — Qualitätsmerkmale priorisieren. Relevante Merkmale pro System identifizieren; nicht alle 9 sind gleich wichtig. Banking: Security und Reliability priorisieren. Consumer-App: Interaction Capability und Performance. KI-System: zusätzlich Robustness, Fairness, Transparency.
Phase 2 — Messbare Qualitätsziele definieren. Beispiele:
- Performance: 95 % der Requests unter 2 Sekunden
- Reliability: 99.9 % Uptime, Recovery unter 30 Sekunden
- Security: null kritische OWASP-Top-10-Findings
- Maintainability: Cyclomatic Complexity unter 15, Duplikation unter 3 %
- KI-Correctness: F1-Score über 0.92 auf Testdatensatz
- KI-Fairness: Demographic Parity Difference unter 0.05
Phase 3 — Quality Gates in der CI/CD-Pipeline.
| Pipeline-Stage | Tests | Tools |
|---|---|---|
| Build | Unit-Tests, SAST, Linting, Dependency Check | pytest/JUnit, SonarQube, ESLint, Snyk |
| Integration | API-Tests, Contract-Tests, Accessibility | RestAssured, Pact, axe-core |
| Pre-Release | Performance, DAST, Chaos Engineering | k6, OWASP ZAP, LitmusChaos |
| Pre-Release (KI) | Model Validation, Bias Check, Data Quality | Deepchecks, Fairlearn, Great Expectations |
| Production | Monitoring, Drift Detection, Verfügbarkeit | Prometheus/Grafana, Evidently AI, PagerDuty |
Phase 4 — Automatisieren oder manuell belassen.
| Automatisieren | Manuell belassen |
|---|---|
| Funktionale Regression | Exploratives Testing |
| Performance- und Lasttests | Usability-Tests mit echten Nutzern |
| SAST/DAST/SCA | Deep Penetration Testing |
| Statische Codeanalyse | Safety-Analyse (HAZOP, FMEA) |
| Accessibility (30–40 %) | Accessibility (60–70 %, Screen Reader) |
| Cross-Browser-Tests | UX Heuristic Evaluation |
| Data-Drift-Monitoring | Ethische Bewertung von KI-Ergebnissen |
| ML-Metriken-Tracking | Explainability-Bewertung durch Fachexperten |
Phase 5 — Kontinuierliches Monitoring.
| Monitoring-Metrik | Zugeordnetes Merkmal |
|---|---|
| Response Times, Throughput | Performance Efficiency |
| Error Rates, HTTP 5xx | Functional Suitability |
| Uptime, MTTR | Reliability |
| Security Alerts, CVEs | Security |
| Feature Drift, Prediction Drift | KI: Functional Adaptability |
| Fairness-Metriken über Zeit | KI: Societal Risk Mitigation |
Verwandte Normen im SQuaRE-Ökosystem
| Norm | Inhalt | Relevanz für QA |
|---|---|---|
| ISO 25010:2023 | Produktqualitätsmodell (9 Merkmale) | Basis-Framework für Teststrategie |
| ISO 25019:2023 | Quality-in-Use-Modell (aus 25010 ausgelagert) | Nutzer-zentrierte Qualität |
| ISO 25059:2023 | KI-Erweiterung des Qualitätsmodells | Pflicht für KI/ML-Systeme |
| ISO 25023 | Messverfahren für Produktqualität | Konkrete Metriken pro Merkmal |
| ISO 25012 | Datenqualitätsmodell | Basis für Data-Quality-Tests |
| ISO/IEC 5259 | Datenqualität für ML/Analytics | KI-spezifische Datenqualität |
| ISO/IEC TR 29119-11 | Testleitfaden für KI-Systeme | Praktische KI-Testmethoden |
| ISO/IEC 24029 | Robustheitsbewertung neuronaler Netze | Formale Methoden für Robustness |
| ISO/IEC 42001 | KI-Managementsystem | Governance-Framework |
Einordnung
ISO 25010 und 25059 sind keine Theorie für die Schublade. Wer eine Teststrategie bauen muss, hat mit den Normen einen vollständigen Merkmalskatalog plus Mapping auf Testarten und Tools — ohne die Begriffe selbst neu erfinden zu müssen. Die KI-Erweiterung schliesst die Lücke, die klassische Produktqualität bei lernenden Systemen offenliess: Robustness, Transparency und Intervenability sind keine Marketingbegriffe, sondern formal definierte Untermerkmale mit zugeordneten Testverfahren.
Drei Empfehlungen für den Einsatz im Projekt: Erstens nicht alle 9 Merkmale gleich gewichten — Priorisierung nach Domäne (Banking ≠ Consumer-App ≠ KI-System). Zweitens messbare Qualitätsziele formulieren, bevor Tools ausgewählt werden — die Norm gibt das Gerüst, nicht die Zielwerte. Drittens Automatisierung dort, wo das Merkmal ein automatisierbares Testverfahren hat (Functional Suitability, Performance, Maintainability) — dort, wo es das nicht hat (Safety, Interaktion, ethische KI-Bewertung), bleibt Expertenarbeit unverzichtbar.
Quellen
- ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model
- ISO/IEC 25010:2011 — vorherige Ausgabe
- ISO/IEC 25019:2023 — Quality-in-Use-Modell
- ISO/IEC 25059:2023 — Quality model for AI systems
- arc42 Quality Models — Quality.arc42 Repository
- iso25000.com — Übersicht ISO 25010
- IEC Blog — New standard ensures quality of AI systems
- ZEISS Digital Innovation — ISO 25010 in der Praxis
- innoQ — ISO 25010 Shortcomings
Sie bauen eine Teststrategie auf Basis von ISO 25010/25059 oder bewerten ein bestehendes Setup gegen die Normen? Im UTAA-Workshop priorisieren wir Merkmale und Tooling projektspezifisch. Mehr zur Methode oder direkt anfragen.