Teure Fehler im ersten Praxistest bei 60 Millionen € Software-Projekt

Wie heute im Web zu lesen war, hat die Bundesagentur für Arbeit ein Software-Projekt eingestampft.

Das Erschreckende dabei: Das Projekt lief seit 4 Jahren und hat schon 60 Millionen Euro gekostet.

Das Traurige dabei: Die Entwicklung wird nicht weiter verfolgt, weil beim ersten Praxistest Fehler auftreten, die man sehr gut vermeiden kann.
Im vorliegenden Fall handelt es sich um ein Problem, das Kontonummern nachträglich nicht mehr geändert werden können. Wenn man deswegen ein Projekt einstampft, muss der Fehler sehr tief sitzen. Vielleicht hat eine Entwicklungsabteilung die Kontonummer als Primärschlüssel verwendet?

Fakt ist, dass die Fehler, die hier aufgetreten sind, nicht erst bei der Codierung, gemacht wurden. Hier sind Fehler in der Planung aufgetreten. Diese Fehler kann man leicht vermeiden, wenn man regelmäßige Feedbacks einholt, und auch Unbeteiligte einmal über die Input-Dokumente schauen lässt.

Software-Qualitätssicherung ist „Devil’s Advocate“

Die entwicklungsbegleitende Qualitätssicherung spielt an der Stelle den Anwalt des Teufels, und untersucht schon während der Planungsphase die entstehenden Dokumente. Hier wird das große Ganze im Auge behalten. Die Ergebnisse der Entwicklungsabteilung, die auf Details konzentriert ist, werden so immer wieder einer Plausibilitätsprüfung unterzogen.

Um das leisten zu können, muss die Qualitätssicherung aber nicht als die Stelle verstanden werden, die „am Ende drauf schaut, ob keine Bugs mehr drin sind“, sondern als Partner der Entwicklung, als verlängerter Arm des Kunden, damit die Entwicklung den richtigen Weg verfolgen kann, und sich auf die Details konzentrieren kann.

Gerade in kleinen Teams reicht die Manpower häufig nicht, um diese Tiefe in der Qualitätssicherung auch zu leisten. Wenn dann falsche Design-Entscheidungen getroffen werden, drohen Nacharbeiten, Lieferverzug und Imageschaden.

Soweit sollte man es nicht kommen lassen. Wir stehen gern als Mittler und „Anwalt des Teufels zur Verfügung“.

 

Unit-Tests / Test driven development … ein kurzer Blick in den Alltag

Hier mal ein kurzer Einblick in den täglichen Arbeitsalltag.

Dieser belegt, wieso Testing auch bei trivialen Aufgaben nicht vernachlässigt werden sollte.

Die Aufgabenstellung war recht einfach:
Ein Programm (geschrieben in C/C++) sollte seine Versionsnummer ausgeben, wenn der Benutzer als einzigen Parameter „–version“ mitgibt.

Der Positiv-Test stellte recht schnell sicher, dass die Aufgabenstellung erfüllt war:

program.exe –version
lieferte

program Version 1.2.0.2345

Soweit, so schön, das Programm beendete sich danach auch wie eigentlich sinnvoll. Dummerweise stand das schon so nicht in der Anforderung – ein Fehler von demjenigen, der die Anforderung geschrieben hatte – gut, dass der Entwickler mitgedacht hatte!

Auf Negativ-Tests wurde zunächst verzichtet.
Wie hätten diese aussehen können?

  • Aufruf des Programms ohne Parameter
  • Aufruf des Programms mit einem anderen Parameter
  • Aufruf des Programms mit mehr als einem Parameter

Das Resultat?

  • Dummerweise beendete sich das Programm nun auch, wenn der falsche Parameter übergeben wurde.
  • Nachdem dieser Fehler behoben wurde, stellte sich heraus, dass die Applikation aufgrund einer Speicherzugriffsverletzung abstürzte, und zwar regelmäßig bei jedem Aufruf.

Da die Software so vom gesamten Team nicht weiter getestet werden konnte, wurde die Änderung schnell wieder zurückgezogen.

Was lernt man aus dieser Geschichte?

  • auch die kleinste Änderung sollte man sich zu zweit anschauen, oder zumindest im Abstand von einigen Stunden noch einmal mit unverstelltem Blick
  • Test-driven-development – also die Arbeitsweise, zunächst Unit-Tests zu entwickeln, und diese dann zu erfüllen, ist hilfreich.
  • Negativ-Tests sind nicht „lästig“ oder „unnütz“, sondern das Salz in der Suppe.

Ich wünsche allen Entwickler-Kollegen ein schönes – bugfreies Wochenende!

Test-Ebenen und Test-Akteure

Software-Test-ToolboxDas Testen der Software kann sowohl durch den Lieferanten / Hersteller geschehen, wie auch durch den Kunden, der seinen Einsatzzweck umgesetzt sehen will.
Auf Seiten des Herstellers wird der Test dann noch in verschiedene Ebenen unterteilt.

Testebenen

  • Unit-Test / Komponenten-Test

    Dies ist die Ebene, die dem Quellcode am nächsten ist. Es werden einzelne Software-Module getestet. Ziel des Tests ist es, dass die einzelnen Module die geplante Funktionalität für sich bereit stellen können.
    Diese Art von Test obliegt typischerweise dem Entwickler. Wobei wir auch hier gern für Sie da sind und Hilfestellung zu leisten. Dafür setzen wir ein Gerüst auf und implementieren erste Tests.

  • Integrations-Test

    Hier werden einzelne Komponenten miteinander getestet. Ziel dieses Tests ist es, die definierten Schnittstellen zwischen den Komponenten zu testen. Diese Teststufe ist ebenfalls noch recht nah am Code. Sie umfasst aber mehrere Komponenten und damit ggf. schon mehrere Entwickler. Dies ist immer auch abhängig von der Größe des Teams.

  • System-Test

    Dieser Test umfasst das Gesamt-System, und findet auf einer Test-Umgebung statt, kann also noch durch das liefernde Unternehmen abgebildet werden. Es werden sowohl funktionale wie auch nicht-funktionale Anforderungen überprüft.

Dem Kunden obliegt letztlich der
  • Abnahme-Test

    Die Durchführung erfolgt nicht mehr anhand von Testdaten auf einer Testumgebung, sondern in der Produktiv-Umgebung, mit realen Daten.

Wir sind in der Lage, Sie als Hersteller während der Entwicklung zu begleiten und Ihnen bei der Test-Entwicklung und -Durchführung zu unterstützen.
Aber auch Kunden, die eine Sonder-Entwicklung in Auftrag gegeben haben,  helfen wir gern. Und stellen sicher, dass das Lastenheft umfassend überprüft wird.
Durch unsere langjährige Erfahrung können wir Ihnen in beiden Fällen helfen.  Besonders beim Abbauen der Sprachbarrieren, die zwischen den häufig technisch geprägten Entwicklungs-Abteilungen und den Fachabteilungen bestehen. Dadurch erreichen Sie das richtige Ergebnis in kürzerer Zeit!