Softwarequalität — erwarte sie nie vom Auftragnehmer (!)

Im Dzone Guide to Software Quality and Software Agility, Edition 2015 findet sich auf den Seiten 4-5 das Ergebnis einer Umfrage unter 600 IT Professionals (von denen die meisten im Umfeld der Implementierung Java-basierter Enterprise Applikationen arbeiten dürften: denn auf dieses Umfeld konzentriert sich Dzone).

Und dieses Ergebnis ist erschreckend (in Englisch gehaltene Aussagen sind Zitate aus dem Bericht):

DZone surveyed more than 600 IT professionals for our Guide to Code Quality and Software Agility to discover how organizations should prioritize various quality metrics as they mature, and to reveal how the types of software they produce inf luence their testing strategies.

Starting with the basics, we asked respondents whether their team does testing at all. 87% said they do, leaving 13% who don’t. 95% of respondents said they believe that testing is necessary on all the software they develop, meaning 8% of respondents don’t do testing, but believe they should.

 
Man kann dieses Umfrageergebnis auch so lesen:

13% aller Entwickler testen gar nicht, was sie implementiert haben.

Einer von 20 denkt sogar, Test sei überflüssig (!).

 
Wen will es bei solcher Einstellung noch wundern, dass Software häufig deutlich zu schlechte Qualität hat?

Die Auftraggeber bezahlen das mit zu hohen Wartungskosten (und hohem Risiko) über den gesamten Lebenszyklus der Anwendung hinweg.

Erschreckend ist, dass selbst Entwickler, die wissen, dass Test notwendig ist, ihn — je nach Unternehmen mehr oder weniger — viel zu früh beenden (oft sogar im vollen Bewusstsein, dass bisher durchgeführter Test nicht ausreicht).

Dies belegen folgende Aussagen des Umfrageergebnisses:

The Definition of Done Varies Significantly Among Organisations:

The most basic definition of done for software products is also the most common for respondents:

79% say its when all code compiles and builds for all platforms.

Other common answers were [ Prozentzahl auf jeweils ein spezifisches Unternehmen bezogen? ]:

• Features reviewed and accepted by Product Owner (65%),
• New features are system-tested (59%),
• Acceptance/story tests are written and passing (52%).

We also asked whether respondents had ever had deadlines in their current product team that caused them to release with less testing than they thought was necessary. 72% said yes.

 
Es wundert mich immer wieder, wie wenig Auftraggeber versuchen zu erzwingen, dass sie für ihr Geld auch wirklich Qualität bekommen. Sind Einkäufer auch großer Unternehmen derart inkompetent? Oder gibt man ihnen einfach nur falsche Zielvorgaben?

Advertisement

Zu ungenaue Dokumentation von Software-Anforderungen kann enorme Schäden verursachen

Anforderungen an unternehmenskritische Software müssen schriftlich, genau und vollständig dokumentiert sein.

Welch gewaltiger Schaden entstehen kann, wenn man das nicht beherzigt, zeigen die folgenden beiden Beispiele:

• The Mars Climate Orbiter space probe failed to land on Sep 23, 1999, because its thruster control software was based on English units while the team responsible for adjusting its trajectory was using the metric system!
   
• A few months later, the Mars Polar Lander also experienced a setback during its landing. It was still 40 metres above its final landing point when its feet deployed, as expected, but the software interpreted it as an imminent event. As a result, the computer shut down the descent engines, leading to an abrupt crash and total loss of both mission and hardware. System engineers had advised the software developers to not rely on the transient signal from the legs of the lander as they were deploying but, apparently, they failed to document this information in the software specifications.

Quelle: Software Quality Issues, 22 Jun 2015, by Claude Y. Laporte

Beide Beispiele zeigen klar und deutlich, dass keine Anforderung

• als selbstverständlich gelten
• oder auch nur undokumentiert bleiben darf.

Es reicht auf keinen Fall, Anforderungen nur mündlich zu kommunizieren — schon allein deswegen nicht, weil später hinzukommende Tester sie dann ja nicht kennen und deswegen auch nicht gezielt verifi­zie­ren werden.
 
 
Dass guter Ausgang eines Projekts, in dem es nicht einfach nur um Prototyping gehen soll, höchst genaue Dokumentation sämtlicher Anforderungen noch vor Beginn der Implementierung zwingend voraussetzt, zeigt auch ein Projektdesaster, das SAP erlitten hat beim Versuch für die Firma Waste Management (in USA) ein neues ERP-System zu implementieren. Das Projekt endete in einem Zustand, in dem Waste Management SAP vor Gericht sogar des Betruges bezichtigte [E].

Zu welcher Komplexität sich diese juristische Auseinandersetzung schon während der ersten 2 Jahre aufgeschaukelt hat, geht hervor aus SAPs Statement We’ve spent millions so far on the Waste Management suit.

Da der Prozess schließlich mit einem Vergleich endete, der vorsah, dass SAP an Waste Management eine nicht öffentlich gemachte Summe zu überweisen hatte, kann man sich vorstellen, welch enormer Schaden in diesem Projekt für SAP, wahrscheinlich aber auch für den Auftraggeber entstanden war.

Dass das Desaster ganz wesentlich auf viel zu ungenaue Anforderungsdefinition zurückführbar war, lässt sich ablesen an folgenden 3 Fakten:

• Der Kunde (Waste Management) argumentierte: SAP gave Waste Management software that it knew was “unstable and lacking key functionality”, …
   
• Der Auftragnehmer (SAP) konterte: Waste management breached its contracts with SAP by failing to “timely and accurately define its business requirements”.
   
• Der Prozess endete mit einem Vergleich, was ja wohl nicht anderes bedeutet, als dass es Versäumnisse auf beiden Seiten gab.

Wie man Software Test effektiv macht

Wer daran interessiert ist, entstehende Software möglichst wirkungsvoll zu testen (oder zu kontrollieren, wie effektiv sie getestet wird bzw. wurde), dem empfehle ich die Lektüre meiner Seite Aus dem Erfahrungsschatz eines IT Managers.

Meinungen zum dort Gesagten, bitte hier als Kommentar hinterlassen. Danke.

 

Test Automation Tools

Diskussionsforum zur Seite Test Automation Tools

und zu meinen Aussagen, das Messen von Testabdeckung betreffend:

• Testabdeckung
• Testabdeckungsmaße
• Sprich ein Machtwort

Klar sein muss:

Nur nachgewiesene Testabdeckung kann zeigen, ob ausreichend getestet wurde.

 

Software Tester’s Core Knowhow

People who want to do software test the right way, especially those who are responsible for Test Automation or Managing a Team of Software Testers, might be interested in looking up Software Tester’s Core Knowhow (2 articles in English, many more in German).

For reducing the danger of Costly Automation Failures I recommend to read first what Carl Nagle is telling us about Test Automation Reality.

 

Software-Test wäre effektiver, wenn …

Die hohen Summen, die große Firmen (Banken und Versicherungen etwa) für Software-Test ausgeben, wären mit Sicherheit deutlich besser angelegt, wenn man sämtliche Tester zwingen würde, weit detaillierter als bisher zu belegen,

• welche Details im einzelnen denn nun wirklich getestet wurden,
• gegen welche Spezifikationspapiere man geprüft hat,
• und — vor allem — welche Testabdeckung die jeweils letzte Test­wiederholung erzielt hat.

Derzeit werden Tester viel zu sehr sich selbst überlassen — ihre Effektivität zu messen und gezielt zu steigern wird nicht wirklich versucht (!).

Lese auch:

• Es muss professioneller getestet werden,
  denn
• Software-Fehler zu reduzieren, wird zunehmend wichtiger.

 

Lücken der Software-Qualitätssicherung

Wissenschaftler aus München berichten (siehe Demystifying Maintainability):

"In 2003 we conducted a study on software maintenance practices in German software organizations. Interestingly, of the 47 respondents only 20% did specific checking for maintainability during quality assurance".

Frage: Liegt das daran, dass es Unternehmen, die Software für Kunden produ­zieren, völlig gleichgültig sein kann, wie teuer den Kunden später die Wartung dieser Software kommt?

Wenn ja: Kann dem Auftraggeber solche Haltung wirklich gleichgültig sein? Warum unternimmt er i.A. gar nichts, um sicherzustellen, dass er gut wartbare Software bekommt (solche also, bei der die Total Cost of Ownership gering ist)?