Kategorien
Was ist eigentlich Qualität?
Ich beschäftige mich schon eine Weile mit dem Thema Qualitätsmanagement. Eigentlich schon seit fast fünf Jahren. Dabei stolpert man, wenn man es durch die technische Brille anschaut, über Themen wie Continuous Integration, Unit Testing, Code Reviews, statische Code-Analyse, funktionale Integrationstests und und und. Diese Liste könnte ich nach fünf Jahren im Business wohl noch eine ganze Weile fortführen. Wenn man aber ehrlich ist, kommt man erst recht spät an den Punkt, an dem man sich die Grundsatzfrage stellt.
Was ist eigentlich Qualität?
An dieser Stelle sollte man sich als Leser hinsetzen und versuchen den Begriff für sich zu definieren. Nicht einfach, oder? Man könnte damit beginnen mögliche Qualitätsmerkmale zu definieren. Wartbarkeit, Funktionalität, Robustheit und Portabilität sind zu Beispiel welche, die im ISO-Standard benannt sind. Qualität einer Software könnte also über die Erreichung des Maximalwerts in den einzelnen Kategorien sein. Das Produkt ist maximal Robust. Super. Hohe Qualität. Wartbar ohne Ende? Hohe Qualität. Klingt jetzt recht einfach.
Leider gibt es bei diesem Weg Qualität zu bestimmen ein Problem. Manche Software hat gar nicht den Anspruch wartbar zu sein. Wenn ich dazu keine Anforderung besitze, muss es trotzdem die Möglichkeit geben hohe Qualität zu produzieren. Man kommt also schnell drauf, dass es gut wäre Qualität und Anforderungen in Zusammenhang zu setzen. Genau das machen auch viele Definitionen von Qualität.
In Gablers Wirtschaftslexikon wird Qualität wie folgt beschrieben „Übereinstimmung von Leistungen mit Ansprüchen“. Qualität ist also das, was man selbst drauf macht. Es geht um den Einhaltungsgrad der gesetzten Anforderungen. Und genau so definiert es auch die passende ISO-Norm (EN ISO 9000:2005):
„Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt“
Ist ein wenig schwer als Deutsch zu erkennen, ist es aber und es sagt so ziemlich das gleiche aus, wie bereits unsere andere Definition.
also für mich ist Qualitätsmanagement super simpel zu definieren:
„Das Testen der Funktionen.“
weil ich ganz oft bei z.b. Browsergames feststelle das es zwar intern alles programmiert wurde aber sich keiner die Zeit genommen hat wenigstens mal auf den Button zu drücken um zu schauen was er das macht was von ihm erwartet wird.
hier finde ich einen ganz anderen punkt interessant, die Leute die die Software testen, müssen auch wissen wie Sie zu funktionieren hat. Das ist oft aber Schwerer als gedacht, da selbst wenn ich 100 Leuten etwas erkläre, der 101te das ganze anders versteht wenn er meine erklärung nicht gehört hat, sondern es von jemand anderen wiedergegeben bekommt.
Leider kann ich dir Wasrun da nicht zustimmen. Zu oft habe ich Entwickler erlebt, deren Code zwar den Blindtest überstand und alle vorher geschriebenen Unit-Tests, aber bei näherer Betrachtung hätte wohl niemand von Qualität gesprochen. Es bringt nichts nach diesem Paradigma zu arbeiten, wenn sich danach niemand traut weiter daran zu arbeiten, weil man Angst hat, was kaputt zu machen.
Ich gebe dir aber recht, wenn man es so formulieren mag, dass alle Pattern, Tests, Styles, Regeln und sonstiges nichts nichts bringen, wenn das Problem dadurch nicht gelöst wird.
Ich sehe das auch etwas anders: Qualität setzt sich aus vielen Faktoren zusammen, die das Ziel haben,
die künftige Wirtschaftichkeit verbunden mit der Implementierung zu verbessern:
Schwer wartbarer Code ist unwirtschaftlich, weil erhöhter Programmieraufwand nötig ist.
Unsicherer Code ist unwirtschaftlich, weil die Implementierung unzweckmäßig genutzt wird und dadurch große Probleme und Strafen resultieren können.
Nicht funktionierender Code ist unwirtschaftlich, weil der eigentliche Zweck nicht (vollständig) erfüllt wird.
Unperformante Anwendungen sind unwirtschaftlich, weil sie frustrieren, Kunden vergraulen und auch wieder weiteren Programmieraufwand schaffen, um die Sache performanter zu gestalten.
Diese ganzen Punkte kann man nicht automatisieren, sondern nur mit genügend Erfahrung entgegentreten.
Continous Integration, Unit-Tests usw. sind nützliche Tools, keine Frage. Aber das ist bei Weitem nicht alles.