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“.

 

Software-Testing – Warum und Wie?

Warum Software-Testing?

Wenn vom Software-Test die Rede ist, kommen häufig Fragen auf, warum explizite Tests erforderlich seien. Man habe doch beim Entwickler gesehen, dass die Software die gestellte Aufgabe erfüllt und auch im Prototypen sieht doch alles gut aus.
Software-testing
Software-Tester bei der Arbeit

Das muss doch reichen?

Die „Zunft“ der Software-Tester und Test-Verantwortlichen sieht diese Punkte als zwingende Testteile, doch sind noch weitere Fragestellungen im Software-Test zu beachten.
Zunächst wollen wir uns darauf einigen, dass ein Test immer einen Vergleich zwischen einem Soll-Zustand und einem Ist-Zustand darstellt.
Der Soll-Zustand sind die Anforderungen, die an die Software gestellt werden, der Ist-Zustand ist das zu liefernde / gelieferte Software-Produkt.
Die Anforderungen sind zum Teil impliziter Natur („die Software soll nicht abstürzen“, „die Software soll die umgebende Hardware nicht beschädigen“, „die Software soll sicher sein“, „die Software soll intuitiv bedienbar sein“).
Diese Anforderungen werden häufig nicht formuliert oder näher spezifiziert.

Wie funktioniert Software-Testing?

In der Spezifikation, dem Lastenheft findet man jedoch die expliziten Anforderungen.
Auf Basis Ihrer Anforderungen entwickeln wir für sie den Testplan.
Dieser Testplan soll reproduzierbare Testergebnisse liefern, sowohl jetzt wie auch in 5 Jahren.
Abgrenzen muss man noch den Begriff des Testens von der Fehlersuche:
Der Test ist ein Soll-/Ist-Vergleich, dessen Detailgrad von der Tiefe des Testplans abhängig ist. Der Test kann Abweichungen („Bugs“) zu Tage führen, die der Entwickler dann untersuchen kann. Ein Test ist aber in der Regel keine detaillierte Fehlersuche oder eine Bereitstellung einer Lösung. Diese obliegt dem Entwickler, der Tester kann lediglich einen Vorschlag machen.
Dies dient der Wahrung des 4-Augen-Prinzips und der Objektivität des Testers.
Umfang des Software-Testing
Angebotsübersicht zur Software-Qualitätssicherung