Ganzheitliche Software-Qualität

Es gibt drei Arten von Organisationen: Die einen bewirken, dass etwas geschieht; die anderen beobachten, dass etwas geschieht; und wieder andere fragen sich, was geschehen ist. Ein Leitfaden für mehr Qualität. [...]

In der Welt der Software-Qualität ist die Gruppe jener, die bewirken, dass etwas geschieht, noch in der Minderheit. Jedoch hat es in den letzten zehn Jahren eine deutliche Verschiebung zugunsten dieser engagierten Organisationen gegeben. Immer mehr Ausbildungsinstitutionen (Universitäten, Fachhochschulen etc.) nehmen Software-Qualitätsthemen in das Ausbildungsprogramm, und die Absolventen tragen dieses Wissen hinaus in die Unternehmen.

Wo früher in den Software-Organisationen nur Entwickler gearbeitet haben, sind heute auch schon einige Tester zu finden. Während diese früher diejenigen waren, die zu dieser Aufgabe „abgeschoben“ wurden, weil sie nicht gut genug programmieren konnten, sind Software-Tester heute oft höher qualifiziert als Entwickler und befinden sich in einer Schlüsselrolle zwischen Produktmanagement, Kunden und Entwicklung. Viele Software-Organisationen machen sich zudem Gedanken über Prozesse und – jedoch leider weniger oft – werden diese auch systematisch definiert und weiterentwickelt. Zumindest der Trend geht in die richtige Richtung.

AUSRICHTUNG AUF QUALITÄT BEDEUTET VERÄNDERUNG
Oft verharren Entwicklungsorganisationen in Selbstzufriedenheit. Mit Sätzen wie „Wir sind der Marktführer – die Besten“, „Das ist nur eine Konjunkturkrise“, „Bei uns ist das alles ganz anders“ oder „Den anderen geht es auch nicht besser“ beruhigt und rechtfertigt man sich selbst. Leider gilt auch oft das Sprichwort „Nachdem wir das Ziel aus den Augen verloren hatten, verdoppelten wir unsere Anstrengungen.“

Nur, was kann man tun, um sich weiter zu entwickeln? Etablierte Denkgewohnheiten und Sichtweisen müssen in Frage gestellt werden. Das Erzeugen von Aufbruchsstimmung und das Denken in neue Richtungen – zum Beispiel durch eine mit dem Management entwickelte gemeinsame Vision – sind in diesem Fall sehr hilfreich und zielführend. Weiterer Tipp: Gewohnte Gruppenstrukturen aufbrechen. Dies kann auch physisch, z.B. in Form von Job-Rotation zwischen Entwicklern und Testern, passieren oder durch die Bildung von interdisziplinären Teams wie etwa in der agilen Entwicklung. Ein weiterer entscheidender Punkt ist das Vorleben von Veränderungen durch das Management. Es reicht oft schon, wenn das vorerst nur in einem eingeschränkten Organisations- oder Themenbereich passiert.

Wichtig: Software-Qualität setzt sich nicht nur aus Testen und Qualitätssicherung zusammen. Entscheidend ist, dass alle beteiligten Personen inklusive dem verantwortlichen Management über Veränderung nachdenken und sich bewusst werden, dass Veränderungen notwendig sind.

Viele Themen sind in diesem Zusammenhang wichtig und gehen oft Hand in Hand. Beispiele dafür sind: Requirements-Engineering, Change-Management, Code-Qualität, Risikoeinschätzungen, angemessene Prozesse, Automatisierung, Vorgehensweisen, Tools und deren Integration.

REQUIREMENTS
In fast jeder Entwicklungsorganisation ist das Thema Anforderungen ein Dauerbrenner und das schon seit Jahrzehnten. Die Langzeitbeobachtung lässt befürchten, dass dieser zentrale Aspekt in vielen Organisationen auch in den nächsten Jahrzehnten nicht nachhaltig gelöst werden wird.

Viele Betroffene tappen hier ziemlich im Dunkeln. Nicht nur, was die Inhalte der Requirements an sich betrifft, sondern es sind in den meisten Fällen noch viele Fragestellungen offen. Zum Beispiel die Unterscheidung zwischen „was“ und „wie“. Oft werden Lösungsbeschreibungen („wie“ etwas umgesetzt wird) und die Anforderungen aus der Kundensicht („was“ der Kunde gerne haben möchte) vermischt.

In den heute üblichen iterativen Vorgehensweisen ist es notwendig, zwischen dem „Was“ und dem „Wie“ einen ständigen Abgleich und Konsens zu schaffen.

WENN DER CHEF ODER DER AUFTRAGGEBER DRÄNGEN
In vielen Unternehmen ist es ein Bewusstseinsthema nach dem Motto „Wieso wird denn hier so viel geschrieben? Wäre es nicht besser, wenn endlich gearbeitet wird?“ In derartigen Organisationen hat das Thema Requirements-Spezifikation keinen Stellenwert.

In vielen Fällen ist es aber auch der Zeitdruck, der oft aus einer falschen Aufwandsschätzung und Planung resultiert. Es wird dann einfach zu wenig Zeit für gute Spezifikation eingeplant oder auch bei guter Planung kann es dem Auftrag­geber oder Chef oft nicht schnell genug gehen, bis er endlich etwas Vorzeigbares sieht. Meist passiert dies dann auf Kosten der Qualität.

REQUIREMENTS-ENGINEERING IN AGILEN PROJEKTEN
Aufgrund der Verbreitung der agilen Vorgehensweisen wird die Anforderungsspezifikation immer mehr zum Thema, da die meisten agilen Vorgehen leider nicht ausreichend darauf eingehen. User-Stories und andere agile Requirements-Artefakte werden zwar erwähnt, aber oft nur sehr oberflächlich beschrieben. Daher muss sich jede Organisation, die agile Vorgehensweisen anwendet, auch Gedanken darüber machen, wie mit Requirements umgegangen wird.

DIE PASSENDEN WERKZEUGE VERWENDEN
Das meist verwendete Tool in diesem Bereich ist nach wie vor die Textverarbeitung oder Tabellenkalkulation. Diese sind zwar flexibel bei der Erstellung von Anforderungen, jedoch beinahe unbrauchbar, wenn es um die Änderungsverfolgung, Versionierung, Attributierung und andere wichtige Themen im Requirements-Management geht.

Es muss klar getrennt werden zwischen der inhaltlichen Darstellung und Strukturierung von Anforderungen, die idealerweise durch geeignete Requirements-Management-Tools erfolgen, und der Steuerung der Umsetzung der Anforderungen, wofür sich dann Tracking-Tools wieder recht gut eignen.

TESTEN AUF BASIS GENAU DEFINIERTER GRUNDLAGEN
Das Testen an sich muss heute kaum mehr argumentiert werden. Es gibt aber auch hier einige Themen, die immer wieder hinterfragt werden müssen: Lässt sich ohne Grundlage testen? Das muss natürlich klar verneint werden.

Es stellt sich jedoch häufig die Frage, was die passende Testgrundlage ist. Testen die Verantwortlichen das, was die Entwickler ihnen sagen? Testen sie nach den Vorgaben, die ihnen die Entwickler geben?  Oder haben die Tester angemessene Anforderungsspezifikationen, Qualitätsrichtlinien, Definitions of Done, vordefinierte Guidelines und Checklisten, an denen sie sich bei der Testfallerstellung und Durchführung orientieren können?

Ein Software-Tester ohne Grundlagen ist wie ein Wanderer ohne Karte und Ziel. Er wird herumirren und eventuell zufällig oder mit seinem Hausverstand und Fachwissen den einen oder anderen Fehler finden, insgesamt jedoch meist ziemlich ineffizient arbeiten.

Manche Unternehmen betreiben Unit-Tests in der Entwicklung recht umfangreich und sind der Ansicht, dass das Testen damit erledigt sei. Das ist jedoch ein Irrtum, da mit den Unit-Tests nur ein bestimmter Teil der benötigten Aufgaben abgedeckt werden kann. Abhängig von der Art des entwickelten Systems sind das zum Beispiel zwischen 30 und 60 Prozent der notwendigen Tests. Je nach Komplexität des Systems sind jedenfalls auch Integrationstests und Systemtests durchzuführen, die typischerweise andere Sichtweisen als die Unit-Tests abdecken und daher nicht weggelassen werden dürfen.

Was hat der Tester eigentlich in der Organisation zu sagen? Welche Verantwortung trägt er und welche Befugnisse hat er? Sind die Tester in die Entwicklung integriert oder sind sie eigenständig von den Entwicklern organisiert? Die Tester sollten mit der Entwicklung eng zusammenarbeiten – schließlich sitzen ja alle im selben Boot und haben dasselbe Ziel, nämlich den Kunden durch gute Software zufrieden zu stellen. Wenn der Tester nur als notwendiges Übel oder als „Feigenblatt der Qualität“ in der Entwicklung betrachtet wird, dann läuft etwas falsch. Der Tester bzw. Testmanager sollte entsprechend seiner Verantwortung auch angemessene Befugnisse haben.
Sie sollten jedoch so eigenständig in ihrer Rolle und organisatorischen Position sein, dass sie ihre Verantwortung und Aufgaben auch effektiv erfüllen können und das Vier-Augen-Prinzip der Qualitätssicherung gewahrt bleibt.

TEST-AUTOMATISIERUNG
Testautomatisierung ist heute für eine ­effiziente Durchführung des Testens unumgänglich. Die Entwickler werden dadurch auch „mutiger“ und das laufende Refactoring eines Systems wird einfacher. Testautomatisierungs-Tools & Frameworks liefern eine gute Basis. Jedoch ist zu beachten, dass die Auswahl eines Testwerkzeugs allein noch keine Test-Strategie darstellt.

Achtung: Auch (Unit-Test-)Entwickler und Testautomatisierungs-Fachtester müssen entsprechend ausgebildet und unterstützt werden, damit Testautomatisierung effektiv und effizient durchgeführt werden kann.

RISIKOMANAGEMENT
Risikomanagement wird oft nicht oder nur halbherzig betrieben. Selbst in sehr großen und risikoreichen Projekten besteht dies oft nur aus einem einmaligen kurzen Brainstorming als „Feigenblatt“ am Anfang des Projekts, damit  die Verantwortlichen auch dieses Thema abhaken können.

Dabei ist Risikomanagement, wenn es ernsthaft betrieben wird, ein sehr gutes Instrument für die Erreichung einer effektiven Vorgehensweise in der Entwicklung. Durch die Risikoeinstufung können praktisch sämtliche Aktivitäten im Projekt differenziert betrachtet und vom Aufwand her gesteuert werden. Eine gezielte Anwendung kann hier, ohne dass auf eine strukturierte und nachvollziehbare Vorgehensweise verzichtet wird, viel Aufwand und Geld sparen.

AGILE METHODEN
Es gibt praktisch kaum eine Software-Entwicklungsorganisation, die sich nicht mit agilen Methoden auseinandersetzt. Abhängig vom Umfeld passiert dies in der Praxis jedoch mit mehr oder weniger Erfolg.

Da agile Methoden oft nur einen recht kleinen Ausschnitt der Realität betrachten (zum Beispiel Scrum-primär: Projektmanagement und Projektcontrolling, Kanban-primär: das Ressourcenmanagement), ist es notwendig, die agilen Methoden immer im Kontext der gesamten Organisation, der Projekte und der restlichen Prozessthemen zu betrachten.

Eine dogmatisch isolierte Behandlung der agilen Ansätze führt in den meisten Organisationen erfahrungsgemäß bald zur Ineffizienz oder sogar zum Scheitern der agilen Methoden.

Alle genannten Themenbereiche sind in die Welt der Software-Qualität eingegliedert. Die Themen sind komplex und miteinander vernetzt und sollten nicht isoliert betrachtet werden. Das Gesamtoptimum für die Organisation sollte im Fokus stehen.

Dazu ist es wesentlich, sich nicht nur auf ein Thema zu konzentrieren, sondern das Prozesssystem als Ganzes zu betrachten, zu analysieren und dann passende Maßnahmen zu definieren. Die Umsetzung fällt leichter, wenn sie Schritt für Schritt erfolgt.

Einen Prozess- und Quality-Manager in der Organisation zu etablieren, wird für die nachhaltige Etablierung des Qualitäts-Gedankens förderlich sein.

Prozesse und das Umfeld ändern sich laufend, daher ist es sehr wesentlich, ständig an deren Anpassung und Verbesserung zu arbeiten.
Zu guter Letzt: Es ist nicht alles schwarz oder weiß. Interessierte sollten die periodisch auftauchenden dogmatischen Publikationen kritisch hinterfragen. Am besten ist man bedient, wenn man sich auf den eigenen Hausverstand verlässt und durchaus pragmatische Wege geht.

* Johannes Bergsmann ist Firmengründer und geschäftsführender Gesellschafter von Software Quality Lab.