Tag Archives: Software-Qualitätssicherung

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?

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.
 

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:

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:

 

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)?