Was ist Qualität? Und wie eng darf ich die Systemgrenzen ziehen, so daß immer noch eine Qualität beurteilt werden kann. Jedem Qualitätsmanager kommt da zwangsläufig die gute ISO 9126 in den Sinn, meist noch in der alten Version aus den Neunziger Jahren. Diese wird aber kurzfristig nun abgelöst durch die SQuaRE-Normen der 25000-Reihe. Dort wird deutlich unterschieden zwischen Produkt-Qualität, bei der das Produkt ohne jeglichen Kontext betrachtet wird, und der Benutzungs-Qualität, bei der das System, die Aufgabe, der Nutzer und das Umfeld mit betrachtet wird. Damit wird das Leben des Qualitätsmanagers nicht einfacher….aber noch ganzheitlicher!
Wer kennt sie nicht, die gute alte ISO 9126, in der die Qualität von Software-Produkten sauber und systematisch heruntergebrochen wird auf die 6 Unter-Eigenschaften:
- Funktionalität
- Zuverlässigkeit
- Benutzbarkeit
- Effizienz
- Änderbarkeit
- Übertragbarkeit
Dieser Kanon ist weit verbreitet und dient als Grundlage vieler ganzheitlichen Qualitätsmanager. Denn eins ist sicher: Wird einer dieser Qualitätsaspekte vergessen (z.B. Effizienz), so kann dieses Defizit kaum durch eine Übererfüllung der anderen Aspekte kompensiert werden. Das schwächste Glied der Kette entscheidet über die Gesamt-Qualität.
Die “alte” ISO-Norm (sie stammt aus dem Jahr 1991) hat allerdings den Nachteil, daß sie insbesondere die Qualität aus Unternehmenssicht nicht berücksichtigt: Für ein Unternehmen, das ein Software-System einsetzt, gelten ganz andere Ziele, nämlich vor allen Dingen die Wertschaffung mit Hilfe der IT. Natürlich wird ein System nur einen Wert schaffen, wenn es nicht permanent abstürzt (Funktionalität) und eine bestimmte Benutzbarkeit aufweist (Benutzbarkeit). Aber der Kontext der Benutzung, und hier vor allen Dingen die Aufgabe, die durch das IT-System bearbeitet werden soll, fließen hier (noch) nicht mit ein.
Diese Trennung wurde bereits in der ISO 9126:2001 angedeutet, vollzieht sich aber jetzt endgültig in der neuen ISO 25000-Serie, der sogenannten SQuaRE-Serie (Software product Quality Requirements and Evaluation). Ich habe diese Woche detaillierte Einblicke in die ISO 25010-Norm (Status: FDIS) erhalten und war positiv überrascht. Das oben aufgeführte Problem des unterschiedlichen Scopings wird hier sauber ausdefiniert. Es fängt alles mit einer sehr schönen Definition von Qualität an:
The quality of a system is the degree to which the system satisfies the stated and implied needs of its various stakeholders, and thus provides value.
Spannend ist der Zusatz “and thus provides value”. Der Spagat zwischen der Anforderungsorientierten Qualitätssicht und der Nutzensicht wird sauber durch zwei Qualitätsmodelle mit sauber abgegrenzten Qualitätscharakteristika realisiert:
- Quality-In-Use-Model: “[…] relate to the outcome of interaction when a product is used in a particular context of use. This system model is applicable to the complete human-computer system, including both computer systems in use and software products in use.”
- Product quality model […] relate to static properties of software and dynamic properties of the computer system. The model is applicable to both computer systems and software products.”
Der Kerngedanke macht Sinn: Ein System mit hoher Produkt-Qualität garantiert noch keinen Mehrwert in einem konkreten Anwendungskontext; dies gilt z.B. dann, wenn die Requirements kaum helfen, die eigentlich anstehende Aufgabe im System zu bearbeiten. Oder der konkrete Anwender vom System völlig überfordert ist. Auf der anderen Seite gibt es wohl kaum ein System, das einen hohen Mehrwert erzeugt, und keine entsprechende Produktqualität aufweist. Richtig ist aber, daß Abstriche dort durchaus erlaubt sind: Wenn, warum auch immer, das IT-System, das zwar alle 30 Minuten abstürzt, dem konkreten Nutzer extrem viel Spaß macht, eine Aufgabe zu bewältigen, kann am Ende immer noch eine hohe Quality-In-Use existieren.
Die “Neuen” Produkt-Quality-Attribute sind nun (im Folgenden mal ohne die Verfeinerungen angegeben):
- Functional Suitability
- Performance efficiency
- Compatibility
- Usability
- Reliability
- Security
- Maintainability
- Portability
Die Quality-In-Use-Attribute sind nun:
- Effectiveness
- Efficiency
- Satisfaction
- Freedom from risk
- Context coverage
Dieser Blog heißt ja “Diagnostiker” und nicht “Wiederholer”…was wäre die neue Norm, wenn es nicht das eine oder andere kritische gäbe. Nur mal drei Punkte zum Nachdenken….werden sicherlich in 2012 noch mal jeweils einzeln hier detaillierter erläutert:
- Warum taucht Usability (als Begriff) in der Produktqualität auf? Insbesondere, wenn es dann in der selben Norm in einer Note noch heißt “Usability is defined as a subset of quality in use consisting of effectiveness, efficiency and satisfaction”. Also ist Usability doch ein “Quality in use” Attribut?
- Warum gibt es die Dopplung des Begriffs “Efficiency”. Wird zwar in der Product Quality mit dem Präfix “Performance” versehen, die Unterattribute sind aber wieder generischer (eins davon ist z.B. das sicherlich nicht direkt für die Performance relevante Resource utilisation)?
- Was macht das Unter-Attribute “functional appropriateness=
degree to which the functions facilitate the accomplishment of specified tasks and objectives” bei der Produkt-Qualität? Die specified tasks and objectives sind etwas anderes, als die Requirements (auf die sich ja die Produkt-Qualität bezieht)?
Dazu später sicherlich noch mehr.
Aprospos, vielleicht noch zum Merken: Für mich als Tester fokussiere ich bei der Produkt-Qualität die Verifikation, also die Sicherstellung, daß gemachte Anforderungen erfüllt sind. Die Quality-In Use fokussiert dagegen die Validierung, also die Überprüfung, ob das System einen Wert darstellt. Diese vereinfachende Sicht begründet zumindest schon einmal die obigen 3 aufgebrachten Fragen. In diesem Sinne: Let’s test!
