Wir beschäftigen uns seit vielen Jahren parallel zu unseren individuellen Software Entwicklungstätigkeiten mit der praktischen und projektbegleitenden Qualitätssicherung von Software Entwicklungsprojekten.
Dabei stellen wir immer wieder mit Erstaunen fest, wie wenig Verständnis und Erfahrungen bei manchen Software Entwicklern aber auch bei Projektleiten bis hin zum oberen Management vorhanden ist. Einige Entwickler finden das Testen "unsexy", so mancher Manager spart gerne am Ende eines Projektes an der Qualität.
Es werden viele theoretische Ansätze gepredigt, es werden dutzende von Templates für Qualitätshandbücher erstellt, es werden hochkomplexe und sehr kostenintensive Software Qualitätssicherungstools angeschafft. An der praktischen Umsetzung und Nutzbarkeit scheitert es dann aber leider in den meisten Fällen - warum ist das eigentlich so?
Oftmals wird das Qualitätsmanagement als Teil des Projektmangements missverstanden. Das Qualitätsmanagement muss aber parallel zum Projektmanagement existieren und hat unter anderem die Aufgabe, auch das Projektmanagement als solches zu überwachen.
Der Qualitätsmanager sollte aber gerade nicht dem Projektmanagement unterstehen, damit der Termin- und Kostendruck des Projekts nicht die Qualität beeinträchtigen kann.
Überschätzung - was verstehen wir unter dem Begriff der Überschätzung?
Zum einen sind es die "ganz normalen" Softwareentwickler, die ihre Kenntnisse und Leistungsfähigkeiten gerade in komplexen Umgebungen, gepaart mit hochkomplexen Frameworks, oftmals überschätzen. Anstatt kleine Schritte zu gehen und immer wieder das neu erlernte zu konsolidieren, wird alles nochmals um einen Komplexitätsgrad erweitert. Anstatt "uncoole" JUnit-Tests zu schreiben und zu Automatisieren wird lieber noch ein "optimierteres" und "generischeres" Pattern eingebaut.
Andererseits werden auch immer mehr QS-Zertifizierungen angeboten. Diese Unterstellen dem Zertifikatsbesitzer gerne, er wüsste mit dem Thema Qualitätssicherung wirklich etwas anzufangen. Leider überschätzt so mancher verantwortliche Projektleiter und Manager diese wirklich toll gemachten Zertifikate. Der derzeitige Zertifikatsboom sorgt nicht wirklich für eine Verbesserung der Qualität bei der Softwareentwicklung. Ein Zertifikat kann keine langjährige Erfahrung und das für die Qualiätssicherung notwendige Fingerspitzengefühl ersetzen.
Softwareprodukte zeigen sich gerne nach außen von ihrer besten Seite. Dabei wird durchaus viel Wert auf die von außen sichtbare Qualität gelegt. Die äußere Qualität ist das erste, was ein externer Betrachter eines Produktes sieht. Aber wie sieht es eigentlich im Inneren aus?
Wenig Wert wird auf die innere Qualität gelegt. Das sieht man schon alleine daran, dass der Begriff "innere Qualität" durchaus seltener vorkommt. Die innere Qualität ist es, die ein Produkt von innen heraus unterstützt, damit es nach außen glänzen kann.
So manchem Produktverantwortlichen ist es egal, wie sein Produkt innen aussieht. Hauptsache es glänzt gegenüber dem Kunden. Diese Einstellung ist nicht von Weitsicht geprägt. Sobald ein Kunde etwas hinter die Fassade blickt, wird der äußere Glanz verschwinden und damit auch ganz schnell das Vertrauen in das Produkt bzw. in die Entwicklung.
Die innere Software Qualität fängt bereits bei der Requirementsanalyse an, zieht sich über die Architektur und das Design, beeinflußt die Entwicklung und Dokumentation bis hin zur Systemintegration und Abnahme. Einen ganz entscheidenen Einfluß hat die innere Qualität auch auf die Wartbarkeit, Pflege und Erweiterbarkeit eines jeden Softwareproduktes.
Eine sehr interessante, aber zugleich auch verständliche Erfahrung ist, dass oftmals die sehr einfachen und kleinen Dinge die Qualität maßgeblich beeinflussen. Unsere Erfahrungen kommen aus dem Umfeld von Java-Projekten, können sicherlich aber auch auf Projekte in anderen Programmiersprachen übertragen werden.
Unserer Meinung nach bringt das durchgängige Anwenden und Überwachen der nachfolgenden vier Punkte eine sehr große Qualitätsverbesserung mit sich:
Wir haben zum Beispiel während den Phasen der Programmierung sehr gute Erfahrungen mit einfachen Komplexitätsmessungen gemacht. Wenn ein Entwickler während des Programmierens immer wieder feststellen kann, wie komplex seine Programmierung ist, dann wird er gezielte Refactoring-Maßnahmen ergreifen, um den Programmcode zu vereinfachen. Damit wird seine Programmierarbeit fast automatisch übersichtlicher und er erreicht durch einfache Unit-Tests eine gute Abdeckung und Sicherheit.
Unsere Erfahrungen haben gezeigt, dass selbst "alte Hasen" einen tollen Aha-Effekt hatten. Mit welch einfachen Algorithmen und Strukturen teilweise hoch komplexe Aufgaben sicher und stabil gelöst werden können, hat doch immer wieder auch die erfahrensten Profis überrascht - und die wirklichen Profis haben es gleich in ihre tägliche Arbeit übernommen ...
Ein weiteres Qualitätsmerkmal ist die Abdeckung des Programmcodes durch automatisierte Tests. Hier kommt eine sehr einfache Coverage Messung zu tragen. Der Entwickler kann auch hier sehr schnell während des Entwickelns von Test-Code sehen, welche Teile durch den Test erfasst werden und an welchen Stellen noch weitere Testroutinen erstellt werden müssen.
Nicht zu unterschätzen ist die Art und Weise, wie der Programmcode geschrieben wird. Die Programmiersprachen erlauben leider viele verschiedene Wege und Schreibweisen, um zum gleichen Ziel zu gelangen. Damit der Programmcode aber von jedem einfach gelesen werden kann, müssen Regeln aufgestellt und überwacht werden. Glücklicherweise können in modernen Programmierumgebungen diese Regeln hinterlegt und automatisch geprüft werden.
Ein wichtiger Punkt ist noch die automatische Überwachung von sogenannten "Standard-Fehlern". Hierbei handelt es sich um Fehler - meistens sind es Leichtsinnsfehler - welche seit vielen Jahren sehr bekannt sind und sich auch sehr schön automatisch prüfen lassen. Jede Programmiersprache hat ihre Eigenarten, daher sind die Standard-Fehler auch nicht bei allen Programmiersprachen gleich. Auch hier gibt es eine sehr gute Unterstützung in modernen Programmierumgebungen.