Startseite > Embedded > Entwicklungstools > Tipps für das Software-Testmanagement

Empfehlungen aus der Trickkiste der Softwaretechnolgie

Tipps für das Software-Testmanagement

12. Oktober 2011, 15:06 Uhr | Von Stephan Grünfelder

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Der Test ist kein Allheilmittel

Software-Qualität lässt sich nicht alleine durch gute Tests am Ende des Entwicklungsprozesses erzwingen. Anders formuliert: Man kann das Produkt eines „kranken Entwicklungsprozesses“ nicht am Ende „gesundtesten“. Wenn die Qualität von Software nicht ausreicht, genügt es daher nicht, nur das Thema Test alleine anzugehen.

Auch Reviews, Code Inspections, automatische statische Code-Analysen [7] und ggf. dynamische Analysen sollten ihren Einzug in die Software-Entwicklung finden. Dynamische Analysen erfassen Eigenschaften der Software wie Verbrauch von dynamischem Speicher, Laufzeitreserven u.v.m. Die vier genannten Methoden können relativ zuverlässig Fehler finden, die ein Test nur durch Zufall aufdeckt. Daher lautet

Empfehlung 4: Ergänzen Sie Ihr Prozessportfolio um Design-Reviews, Code-Inspektionen, Analysen von Speicherverbrauch und Laufzeitverhalten sowie automatische statische Code-Analyse.

Je später Sie sich im Projektverlauf entschließen, die genannten Methoden einzusetzen, desto teurer wird es: Ein ungeschicktes Design, das sich lange genug gehalten hat, bleibt vermutlich auch noch in vielen weiteren Firm-ware-Releases ein Problem, weil ein Redesign mit fortschreitender Zeit kostspieliger wird. Je später ein Engpass an CPU-Ressourcen oder an RAM erkannt wird, desto kostspieliger ist ein Design-Update. Ein spätes Einführen eines Werkzeugs zur automatischen statischen Analyse von Quellcode resultiert oft in einer großen Zahl von Falschwarnungen, die alle abgearbeitet werden müssen um sicherzugehen, dass die wenigen wirklich wichtigen Meldungen nicht übersehen werden.

Die genannten Verifikationsmethoden werden nicht vom Testteam durchgeführt, sondern vom Entwicklerteam. Es wäre schön, wenn das Entwicklerteam diese Aufgaben freiwillig übernimmt, weil sich mit Hilfe des Managements in den Köpfen der Mitarbeiter ein angepasstes Qualitätsdenken etabliert hat. Das Entwicklungsteam muss verstehen, dass nicht alleine das Testteam für Qualität verantwortlich ist. Ein Fehler, der vom Testteam gefunden wurde, aber im Entwicklerteam in einer Code-Inspektion oder in einem Unit-Test hätte gefunden werden müssen, ist Anlass zur Sorge: Haben die Entwickler zu wenig Zeit für Reviews? Werden Reviews schlampig gemacht? Gibt es Fehlerarten, die dem Team regelmäßig passieren und denen daher in Inspektionen besonderes Augenmerk gewidmet werden muss?

Wenn das Entwicklerteam seitens des Managements dazu ermutigt wird, Antworten auf diese Fragen zu finden, dann ist der erste Schritt getan, einen geschlossenen Regelkreis in Sachen Qualität aufzubauen: das Team ist bereit aus Fehlern zu lernen und die Prozesse maßvoll so anzupassen, dass die Fehlerzahl im Rahmen bleibt.

Empfehlung 5: Daher lautet meine fünfte Empfehlung: Etablieren Sie einen „Lessons Learned“-Prozess. Fehler passieren auch in gut organisierten Firmen. Wenn wiederholt ähnliche Fehler passieren, dann ist das jedoch ein Zeichen schlechter Organisation. In klassischen planungsgesteuerten Projektteams ist der Projektleiter bzw. der Qualitätsbeauftragte aktiv am Lessons-Learned-Prozess beteiligt. In selbstorganisierenden Teams gibt es diese Rolle nicht. Der firmeninterne Auftraggeber (Abteilungsleiter oder der Produktmanager) ist aufgefordert, nach jedem ernsten Fehler Konsequenzen für eine zukünftige Fehlervermeidung einzufordern und zu prüfen.

Ein Lessons-Learned-Prozess hat einen wohl definierten Bugtracking-Prozess zur Voraussetzung. Diesen zu etablieren ist keine Hexerei. Eine ganze Reihe von freien Bugtracking-Werkzeugen, wie z.B. [8], unterstützen den Prozess. Zeitgemäße Literatur widmet sich dem Thema oft unter der Überschrift „Abweichungsmanagement“ [6].