Software-Testing: Tipps zur Qualitätssicherung Detail - Computerwelt

Computerwelt: Aktuelle IT-News Österreich


22.05.2011 Daniel Liebhart*

Software-Testing: Tipps zur Qualitätssicherung

Von der Einbettung eines messbaren und durchgängigen Testprozesses als Teil der IT-Strategie sind noch viele Unternehmen weit entfernt. Aus Sicht der Individualentwicklung gibt es jedoch einige einfache Praxistipps für die Software-Qualitätssicherung.

Die um sich greifende Regulierung des Entwicklungsprozesses und des IT-Betriebs führen dazu, dass sich Unternehmen zunehmend mit den Themen Testing und Qualitätssicherung auseinandersetzen. Doch die Qualitätsansprüche an Softwaresysteme fallen aufgrund der individuellen Sichtweise der Beteiligten sehr unterschiedlich aus. Die Anwender wollen ein intuitiv zu bedienendes GUI und möglichst kurze Antwortzeiten. Der Auftraggeber erwartet möglichst niedrige Kosten und eine rechtzeitige Inbetriebnahme. Für den Support ist eine weitgehend fehlerfreie Anwendung wichtig. Der Sicherheitsbeauftragte, das Controlling und andere Regelgremien wollen Anwendungen, die prüfbar und normenkonform sind. In der Theorie ist alles einfach. Man nehme die Qualitätsnormen nach ISO oder DIN, wie beispielsweise den Qualitätsbegriff nach ISO 8420, suche sich das entsprechende Qualitäts-Management-System (ISO-9000-Reihe, TQM, EFQM, IQM oder IMS) aus den über 30 verfügbaren Qualitätsmodellen aus und appliziere es auf den Software-Entwicklungsprozess.

In der Praxis sieht die Sache jedoch ganz anders aus, insbesondere in der Individualentwicklung oder der unternehmensspezifischen Erweiterung von Standardprodukten. Allein das Testen und die Verifizierung von Software kennt eine Unzahl von Standards, Methoden und Tools, die in der Praxis der Entwicklungsprojekte kaum oder nur sehr beschränkt anzuwenden sind. In der Individualentwicklung kommt hinzu, dass die Kosten, die mit der Qualitätssicherung einhergehen, nicht zu tragen sind. Es findet sich kein Kunde, der einen Aufpreis von bis zu 50 Prozent, wie beispielsweise Ian Sommerville in seinem Buch "Software Engineering" schätzt, zu zahlen bereit ist.

PRODUKT- ODER PROZESSQUALITÄT? Spätestens seit der Einführung der ISO-Norm 9126 (Software Engineering, Product Quality) existiert ein allgemein anerkannter Qualitätsbegriff für Software: Softwarequalität ist demnach "die Gesamtheit von Eigenschaften und Merkmalen eines Softwareprodukts oder einer Tätigkeit, die sich auf dessen Eignung zur Erfüllung gegebener Erfordernisse beziehen".

Der Standard und seine DIN-66272-Entsprechung listet sechs Qualitätsmerkmale (Portability, Functionality, Reliability, Maintainability, Efficiency und Usability) auf und sieht eine Quantifizierung über interne und externe Metriken vor. Die Übertragbarkeit (Portability) ist der Grad der Eignung der Software, von einer Umgebung in eine andere übertragen zu werden, die Funktionalität der Abdeckungsgrad in Bezug auf die Anforderungen, die Zuverlässigkeit (Reliability) bestimmt die Fähigkeit der Software, unter bestimmten Bedingungen lauffähig zu sein, während die Änderbarkeit (Maintainability) den Änderungsaufwand spezifiziert. Die Effizienz beschreibt das Verhältnis zwischen Leistungsniveau der Software und den eingesetzten Betriebsmitteln, und die Benutzbarkeit bestimmt den Aufwand zur Nutzung der Software durch die Anwender. Allerdings sind die Metriken leider nicht festgelegt, so dass eine formale oder auch automatisierte Prüfung der Merkmale in der Praxis kaum umgesetzt worden ist.

Eine grundlegende Schwierigkeit ist, dass die Tests dieser Merkmale - wenn überhaupt - nur mit großem Aufwand möglich sind und immer im Gesamtkontext des Systems gesehen werden müssen. Wesentlich einfacher ist es dagegen, Tests im Rahmen der einzelnen Phasen der Softwareentwicklung vorzunehmen. Konkret bedeutet dies, dass im Rahmen der Projektphasen die entsprechenden Tätigkeiten für das Qualitäts-Management eingeführt werden.

Dazu findet in einem pragmatischen Ansatz während der ersten Projektphasen (Analyse und Grobspezifikation) die Qualitätsplanung statt. Sie umfasst die Festlegung der Merkmale und Messwerte sowie die Ausführungsszenarien in Form von Testplänen. Die Qualitätssicherung, also die Maßnahmen zur Abwicklung der Qualitätskontrolle, wird anschließend während der Feinspezifikation definiert. Die Qualitätskontrolle selbst findet während der restlichen Projektphasen statt. Es gibt jedoch auch einen Nachteil dieses Vorgehens: In realen Projekten werden die Testphasen oft als zeitlicher Puffer für die Entwicklung verwendet, so dass Testpläne und Testfälle schnell von der Projektrealität überholt werden und damit zum Papiertiger verkommen. Trotzdem ist dieses Vorgehen einfach und sinnvoll und stellt lediglich eine einfache Erweiterung des normalen Projekt-Management-Prozesses dar.

DAS FEHLERPROBLEM Ein zentraler Ansatz für das Testing könnte sein, dass Fehlerursachen, Auftretenswahrscheinlichkeiten, Häufigkeiten und Ort bekannt wären. Leider existieren nur sehr wenige Fehlerstatistiken. Selbst die viel zitierte "Chaos"-Studie der Standish Group, die zumindest den Erfolg von Softwareprojekten auflistet, ist vom renommierten Honorarprofessor und Autor des "Journal of Systems and Software", Robert L. Glass, vollständig in Frage gestellt worden. Er hat nachgewiesen, dass die Zahlen keinerlei statistischen Wert besitzen. Die Standish-Zahlen sind durch den Bericht "A Replicated Survey of IT Software Project Failures" der Universität Ottawa und Maryland aus dem Jahr 2008 vollständig widerlegt worden. Es gibt allerdings Untersuchungen für einzelne Systeme. So haben die Statistiken der AT&T-Mitarbeiter Perry und Evangelist gezeigt, dass bis zu 66 Prozent aller Fehler in den Schnittstellen auftreten. Meistens handelt es sich dabei um Konstruktionsfehler (13 Prozent), nichtadäquate Funktionalität (13 Prozent), mangelhafte Fehlerbehandlung (15 Prozent) und schlechtes Postprocessing (10 Prozent). Es sind genau die Schnittstellen, die viel zu oft vernachlässigt und in modernen Modellierungsmethoden auch zu wenig detailliert erfasst werden. Allein schon die explizite Modellierung eines Schnittstellenablaufs mit den Schritten Exportieren, Validierung der exportierten Daten, Transformation, Konversion, Validierung der zu importierenden Daten und Import in das Zielsystem hilft, fehlerhafte Schnittstellen zu vermeiden. Eine für die Praxis sehr nützliche Richtlinie hierfür ist die "Top 10 Defect Reduction List" von Barry Boehm.

Diesen Artikel

Bewertung:

Übermittlung Ihrer Stimme...
Noch nicht bewertet. Seien Sie der Erste, der diesen Artikel bewertet!
Klicken Sie auf den Bewertungsbalken, um diesen Artikel zu bewerten.
  Sponsored Links:

IT-News täglich per Newsletter

E-Mail:
Weitere CW-Newsletter

CW Premium Zugang

Whitepaper und Printausgabe lesen.  

kostenlos registrieren

Aktuelle Praxisreports

(c) FotoliaHunderte Berichte über IKT Projekte aus Österreich. Suchen Sie nach Unternehmen oder Lösungen.

Service

Acceptance Testing: Trotz knapper Ressourcen

Zum Thema

  • Snap Consulting - Systemnahe Anwendungsprogrammierung u Beratung GmbH

    Snap Consulting - Systemnahe Anwendungsprogrammierung u Beratung GmbH Wasser- und Energieversorgung, Öffentliche Verwaltung, Medizin und Gesundheitswesen, Maschinen- und Anlagenbau, Luft- und Raumfahrttechnik, Logistik, Konsumgüterindustrie,... mehr
  • SER Solutions Österreich GmbH

    SER Solutions Österreich GmbH Werbewirtschaft, Wasser- und Energieversorgung, Vereine und Verbände, Umweltschutz, Touristik, Personenverkehr, Öffentliche Verwaltung,... mehr
  • DBConcepts GmbH. Die Oracle Experten.

    DBConcepts GmbH. Die Oracle Experten. Enterprise Application Integration, Datenbanken, Business Intelligence und Knowledge Management, Tools, Server-Betriebssysteme, Middleware, Betriebssysteme für PCs,... mehr
  • ectacom GmbH

    ectacom GmbH Aus- und Weiterbildung, IT-Asset- und Lizenzmanagement, Übernahme von Softwareprojekten, Datenschutz, Antiviren- und Virenscanner Software, Backup und Recovery Systeme, Firewalls,... mehr

Hosted by:    Security Monitoring by: