Praxisbericht
Seminar ‚Messen und Prüfen von Software‘, WS 2001/02
erstellt von
Philipp Suter (Wirtschaftsinformatik)
05.02.2002 Prof. Dr. Martin Glinz Betreuer: Christian Seybold
Inhaltsverzeichnis
Einführung 2
1 Eingesetzte Verfahren 3
1.1 ISO 9000 3
1.2 Cocomo II 5
1.3 McCabe 5
1.4 Testverfahren 7
2 Elca und Sumex II 7
2.1 Elca 7
2.2 Sumex II 8
2.2.1 Anwendungsgebiet 8
2.2.2 Systemumgebung und Entwicklungstools 8
2.2.3 Entwicklungsgeschichte 8
3 Qualitätsmanagement und –sicherung bei Elca 9
3.1 Projektmanagement 9
3.2 Qualitätssicherung 10
4 Testverfahren im Rahmen von Sumex II 10
4.1 Verfahren 10
4.1.1 Vorgehen 10
4.1.2 Risikoanalyse 110
4.2 Testphasen 12
4.2.1 Unittests 12
4.2.2 Integrationstests 13
4.2.3 Systemintegrationstests 13
4.2.4 Abnahmetests 14
4.2.5 Vorlagen und Tools 14
Fazit 15
Einführung
Im Folgenden soll aufgezeigt werden, wie bereits vorgestellte Test- und
Qualitätsmanagementstandards in der Praxis eingesetzt werden. Dies wird anhand der Softwarefirma ELCA geschehen, die mir freundlicherweise die Möglichkeit gab, einen Nachmittag lang mit Herrn Mäder, COO, und Herrn Pfister, Projektleiter Sumex II, Interviews zu führen. Die folgenden Ausführungen basieren grösstenteils auf diesen Interviews. Selbstverständlich haben jede Firma und jedes Projekt ihre eigenen Gesetzmässigkeiten. Je kleiner das Projekt, umso weniger Strukturen sind zu
erwarten. Es lohnt sich schlicht und einfach nicht bei einem kleinem Projekt, das nur aus wenigen Leuten besteht, allzu viel Zeit für Formalismus aufzuwenden. Dasselbe gilt für eine kleine Firma. Im Allgemeinen sollte bei der Anwendung von formalen Managementinstrumenten immer ein Kosten/ Nutzen-Denken im Vordergrund stehen.
Und gar keine strukturierten Abläufe zu verwenden ist auch selten eine gute Grundlage für herausragende Erfolge.
1 Eingesetzte Verfahren
Bei ELCA werden drei Verfahren eingesetzt:
1. ISO 9001 [1]
2. Cocomo II [2]
3. McCabe IQ2 [3]
Die ISO-Zertifizierung bezieht sich auf die gesamte Firma. McCabe und Cocomo werden als Standards für die Testverfahren und Projektplanung benutzt.
Selbstverständlich werden die Erfahrungen und die Kennzahlen aus den abgeschlossenen und laufenden Projekten eingesetzt um die Grundlagen aller Verfahren kontinuierlich zu verbessern und genauer auf die Bedürfnisse der ELCA abzustimmen.
1.1 ISO 9000
Basierend auf dem British Standard 5750 wurde 1987 von der International
Organization for Standards der ISO 9000 Qualitätsmanagementstandard entwickelt.
ISO 9000 und auch ISO 14000, der Ressourcenmanagementstandard, verstehen sich als Leitfäden für Firmen, um ihre Prozesse in einer Art zu gestalten, die international festgelegt ist und der periodischen Kontrolle einer unabhängigen Instanz unterliegt.
Dadurch wird es für den Kunden möglich, sich darauf zu verlassen, dass entweder die Qualität oder die Ressourcen besonders gepflegt werden. Der ISO 9000 wurde schon zweimal revidiert, 1994 und 2000. Ich beziehe mich im folgenden auf den 2000er Standard.
Die ISO Zertifizierung wird nicht durch die International Organisation of Standards selber durchgeführt sondern von externen Firmen. Die Organisation setzt nur den Rahmen für das Zertifikat. Alle drei Jahre muss eine registrierte Firma einen Audit durchführen, indem sie aufzeigt, wo sie sich verbessert und wo sie sich verschlechtert hat. Dies garantiert eine kontinuierliche Verbesserung. Es wird insbesonders auf die folgenden acht Punkte wert gelegt:
1. Kundenorientierung
Eine Firma sollte die Wünsche und Gebräuche ihrer jetzigen und zukünftigen Kunden kennen und versuchen sie zu übertreffen. Eine langfristige und stringente Kundenorientierung wird durch einheitliche Unternehmensziele und -visionen
erreicht. Dadurch kann besser auf den Markt eingegangen werden, Veränderungen werden schneller erkannt und adaptiert, Ressourcen werden besser eingesetzt und die Kunden sind zufriedener und loyaler.
2. Führung
Eine gut geführte Unternehmung lässt ihren Mitarbeitern Zeit und Raum ihre Aufgaben voll und ganz wahrzunehmen, ohne sich mit Aufgaben befassen zu müssen, die Sache des Managements wären. Durch klar kommunizierte Wünsche und Ziele gegenüber allen Stakeholdern wird den Mitarbeitern die Mögklichkeit gegeben, zufrieden und motiviert überdurchschnittliche Leistungen zu erbringen.
3. Mitarbeiterbeteiligung
Mitarbeiter die sich bestätigt und ernst genommen fühlen, setzen ihre Kreativität und Innovationsfähigkeit dafür ein, die Unternehmung besser zu machen. Dies kann durch Einbezug und Unterstützung eines jeden Mitarbeiters im täglichen Leistungs- und Kommunikationsprozess gefördert werden.
4. Prozessorientierung
Systematische und klare Verantwortungen und das Messen der Resultate in einem gut strukturierten Prozess führt zu schnelleren Produktionszyklen, besseren Produkten und klaren Verbesserungsmöglichkeiten. In den Prozess sollten Mitarbeiter, Kunden und Lieferanten einbezogen werden, um die Ressourcen und Aktivitätem optimal zu verteilen.
5. Systemorientierung des Management
Die optimale Einbindung aller Prozesse in das System Unternehmung mit Fokus auf den Kernprozess führt langfristig zu mehr Konsistenz, Effizienz und
Effektivität. Daher sollten die Abhängigkeiten, Verantwortlichkeiten,
Möglichkeiten und Rollen verstanden und kontinuierlich verbessert werden.
6. Kontinuierliche Verbesserung
Durch die ständige Reflexion der eigenen Leistung wird langfristig
unternehmensweite Flexibilität und Konsistenz erreicht. Ständige Schulung der Mitarbeiter und zielgerichtetes Messen und Verfolgen aller Prozesse führt zu Richtlinien die eine ständige Verbesserung ermöglichen.
7. Faktenbasierte Entscheidungsfindung
Effektive Entscheidungen basieren auf der Analyse von Informationen und Daten gepaart mit Erfahrung und Intuition. Die Grundlage dazu bietet eine strukturierte,
vertrauenswürdige und zugängliche Datenbasis, die mit allgemeingültigen Methoden analysiert wird.
8. Gegenseitiges Profitieren bei Lieferantenverbindungen
Eine Organisation und ihre Lieferanten stehen in gegenseitiger Abhängigkeit und haben gemeinsame zukünftige Interessen. Daher bietet sich die Möglichkeit, mit gegenseitigem Vertrauen Prozesse und Produkte langfristig zu verbessern und zu verbilligen. Lieferanten sollten gepflegt, aber gut assortiert und nicht zu breit gefächert sein.
Diese acht Prinzipien formen gemeinsam eine adäquate Basis, um eine Firma langfristig im Markt zu positionieren. Sie sind jedoch allgemein gefasst und jede Unternehmung sollte auf Grund ihres individuellen Hintergrundes selber entscheiden, welche Faktoren mehr oder weniger wichtig sind.
1.2 Cocomo II
Im Rahmen dieser Veranstaltung wurde Cocomo II bereits ausführlich behandelt und wird hier nur kurz zusammengefasst. Dieses Verfahren dient der Projektplanung und basiert auf Zahlen zur Abgrenzung eines Projektes, die im Rahmen von grösseren Softwareentwicklungen evaluiert wurden. Der Wiederverwendbarkeit und
Wartbarkeit wird besondere Aufmerksamkeit geschenkt. Voraussicht, Flexibilität, Architektur/Risikoauflösung, Teamzusammenhalt und Prozessreife ihm
Zusammenhang mit der Anzahl Lines of Code und Function Points sind die
Kernfaktoren zur Bestimmung der zu erwartenden Anzahl Personenmonate, welche wiederum die Länge und Kosten eines Projektes repräsentieren. Die folgenden drei Phasen oder Spiralzyklen sind das Herz von Cocomo II:
1. Prototyping der essentiellen Bausteine
2. Entwicklung alternativer Architekturen und Entwicklungsszenarien
3. Lebenszyklusmodel um die Kostentreiber und -träger genauer zu spezifizieren
1.3 McCabe IQ2
Auch auf dieses Testwerkzeug wurde im Rahmen der Veranstaltung bereits kurz hingewiesen. McCabe IQ2 wurde von McCabe & Associates im Laufe der letzten zwanzig Jahre suksessive entwickelt. Es unterstützt die Verlässlichkeit, Wartbarkeit und Stabilität von Applikationen durch die Möglichkeit, Testaktivitäten besser zu
planen, durchzuführen und nachzubearbeiten. Des weiteren unterstützt es das Configuration und Change Management. Es besteht aus folgenden sechs Bausteinen:
1. Quality Assurance
Dieses Modul dient als Unterstützung der Qualitätssicherung durch die grafische Abbildung der Komplexität. Die Komplexität einer Software sollte minimiert werden um die Qualität sicherzustellen. Dies wird erreicht, indem die Anzahl der möglichen Pfade in der Software auf ein absolutes Minimum beschränkt werden.
2. Test (Basis Path Testing, i.e. Structured Testing)
Hier wird die Testumgebung mit der Unterstützung von grafischen Wekzeugen erschaffen. Das Testen hängt direkt von der Komplexität der Software ab. Es sollte auf die Teile einer Software konzentriert sein, die eine grosse Tendenz haben, Fehler zu produzieren. Durch präzisses Beobachten der Fehler werden auch die interaktionsbedingten Fehler besser entdeckt.
3. Coverage Server
Dieses Modul dient der Speicherung von Testfällen und entdeckten Fehlern.
Insbesondere die Komplexitäts-Masse und die Lines of Code dienen als
Grundlage für die Testumgebung. Es wird erfasst, was schon erledigt ist und was noch in welcher Form zu tun ist.
4. Reengineer
Durch verschiedene Farben wird der Status eines bestimmten Softwaremoduls angezeigt. Die System Analyse und das vermeiden von redundantem und doppelt vorhandenem Codes wird erleichtert.
5. TRUEchange
Das Change Management und Versioning einer Software wird erleichtert. Dieses Tool ähnelt dem bekannten CVS. Es können die gemeldeten Bugs und die entsprechenden Reparaturen erfasst werden und Notfalls steht eine frühere Version zur Verfügung.
6. TRUEtrack
Probleme mit den gleichen Ursachen werden zusammengefasst. Es können Pendenzen und Verantwortlichkeiten bestimmt werden. Die anfallenden Aenderungen während eines Change Cycles können genau beobachtet werden.
7. TestCompress
Grosse Datenmengen können zu kleinen, testbaren Subsets zusammengefasst werden, damit sie effizient getestet werden. Dieses Tool erleichtert die Auswahl einer repräsentativen Stichprobe und verkleinert die Anzahl Tests.
1.4 Testverfahren
Im hier vorgestellten Projekt werden die folgenden Testverfahren benutzt. Sie werden nicht weiter kommentiert, da sie im Rahmen dieser Veranstalung im besonderen und im Rahmen des WI-Studium im allgemeinen schon öfters vorgestellt wurden.
Code Inspektion (Code wird gemeinsam durchgelesen und besprochen.)
Funktionale Tests (Sind alle spezifizierten Funktionen korrekt implementiert?)
Debugger (Schrittweises Ausführen aller Programmteile.)
Coverage Tests (Wurden alle Codezeilen einmal getestet?)
Performance Tests (Wie ist so die Antwortszeit?)
Stress Tests (Was passiert, wenn alle gleichzeitig das gleiche wollen?)
Robustheitstests (Ist Datenintegrität bei Ausfällen gegeben?)
Langzeittests (Läuft die Software auch noch nach zwei Wochen?)
Installation (Kann die Software effektiv auf allen Plattformen installiert werden?)
2 ELCA [4] und Sumex II
Im folgenden werde ich nun die besuchte Unternehmung und eines ihrer Produkte vorstellen.
2.1 ELCA
300 Ingenieure aus 18 verschiedenen Ländern bilden zusammen das Software- Unternehmen ELCA mit Hauptsitz in Lausanne und Büros in Zürich, Bern, Genf, London und Ho-Chi-Minh-City. Ursprünglich war sie eine Tochterfirma der SBB, in den letzten Jahren wurde sie jedoch durch eine Management-Buyout suksessiv privatisiert. Der Umsatz wurde seit 1998 massiv gesteigert und lag im Geschäftsjahr 2000 bei über 42 Millionen CHF. Die Kundschaft erstreckt sich von der Verwaltung über Transportuntenehmen, Banken, Nahrungsmittelsektor bis zu Luftfahrt- und Telekomunternehmen. Enwickelt wird in Java / C++ / C# / Uniface.
2.2 Sumex II [6]
2.2.1 Anwendungsgebiet
Sumex II ist eine Software für Kranken- und Unfallversicherungen, die eingesandte Rechnungen, in elektronischer oder physischer Form, auf ihre Richtigkeit überprüft und dann die notwendigen Schritte veranlässt. Diese sind entweder Rückweisung, manuelle Vervollständigung oder elektronische Weiterbearbeitung im Rahmen der Buchhaltung und der Geschäftsprozesse der Versicherung. Die Rechnungen werden auf ihre Korrektheit in Abhängigkeit von TARMED[5], dem Tarif der FMH, getestet.
Dieser erlaubt neu eine Aufteilung der Leistung in einen medizinischen Teil, der Inhalt und Umfang der Leistung wiederspiegelt, und einen technischen Teil, der die Art und Weise der Rechnungslegung aufzeigt. Des weiteren wird der
Ausbildungsgrad und die zur Verfügung stehende Infrastruktur des Behandelnden in die Berechnung des Tarifes miteinbezogen. TARMED wurde auf Grund des
Krankenversicherungsgesetzes aus dem Jahre 1994 entwickelt.
2.2.2 Systemumgebung und Entwicklungstools
Sumex II ist ein datenbankbasiertes Java-Framework. Es addiert die Beträge auf den Rechnungen, multipiziert die verschiedenen TARMED-Faktoren und vergeicht die Daten der behandelnden Ärzte und deren Patienten mit den bereits erfassten. Die Datenbanken, die momentan unterstützt werden, sind DB2, Oracle und RTB. Im Projektmanagement werden verschiedene Tools eingesetzt. JBuilder für die
Entwicklung, CVS für das Versioning, JUnit für das Unittesting und GNATS für die Problemreports. Das zu Grunde liegende Betriebssystem ist Windows NT.
2.2.3 Entwicklungsgeschichte
Vor 2 1/2 Jahren wurde das Projekt ins Leben gerufen und ist im Moment in der Version 2 erhältlich. Es wurden sieben beta-Versionen erstellt, bis Version 1 released wurde. Sumex II wurde als Framework konzipiert, um es für verschiedene
Versicherungen einfach anpassen zu können.
3 Qualitätsmanagement und -sicherung bei Elca
Wie bereits erwähnt ist ELCA ISO 9001-zertifiziert. Durch die schnelleren Enwicklungszyklen und den grösseren Marktdruck in den letzten, vom eBusiness gezeichneten Jahren wird es immer wichtiger, dass eine Unternehmung parallele Abläufe in immer grösseren Projekten zu managen weiss. Effiziente Testverfahren und ein klares Risikomanagement sind die wohl wichtigsten Grundlagen.
3.1. Projektmanagement
Projekte werden bei der ELCA auf Spezialwünsche des Kunden hin gestartet.
Enwickelt wird nach dem Wasserfallmodell. Wichtig ist dabei die Uebersetzung der Kundenwünsche in eine für Softwareentwickler verständliche Sprache, dies geschieht durch die Abbildung der Prozesse in die Unified Modelling Language (UML) mit der Hilfe von Rational Rose. Meistens wird ein erster Prototyp erstellt, um dem Kunden die Möglichkeiten besser aufzeigen zu können. Danach wird mit Cocomo II eine Aufwandschätzung auf Grund von eigenen Erfahrungszahlen vorgenommen. Diese sind im Laufe der Zeit gesammelt worden. Einige wichtige Kennzahlen wären:
# GUI-Masken oder Web-Seiten
# Klassen und deren Methoden
LoC / Testaufwand
# Dokumentseiten
# Sitzungsstunden
# Code Reviews
Eine Offerte wird erstellte, die sich über den ganze Lebenszyklus einer Software (Entwicklung, Implementation und Wartung) erstreckt. Die Entwicklungsumgebung wird mit Hilfe von McCabe IQ2 modelliert. Die Einhaltung und Gestaltung aller Kriterien ist Sache des Projektleiters, erfolgt jedoch auf Grund von Vorgaben der Geschäftsleitung. Der Einsatz von Managementverfahren sollte sich im Vergleich zum effektive Aufwand im Optimum befinden um die gegebenen Ressourcen bestens ausnutzen zu können. Das Optimum lässt sich durch eigene Erfahrung und gesunden Menschenverstand abschätzen. Für ein zweimonatiges Projekt, das zwei Leute beschäftigt, lohnt es sich kaum mehr als ein paar Tage zu planen. Aber für eine Entwicklung, die ein halbes Jahr in Anspruch nimmt und mehr als zehn Leute beschäftigt, ist es klar, dass bis zu einem Monat oder mehr der Vorbereitung dienen.
3.2 Qualitätssicherung
ELCA verfügt über ein internes Qualitätshandbuch, in dem folgendes vorgegeben ist:
Entwicklungsrichtlinien
Managementaktivitäten (Projekt-, Change- und Konfigurationsmanagemnt)
Kontrollaktivitäten (Statistiken, Tests und Enwicklungsprozess)
Qualiätserhaltungsaktivitäten (Qualitätsbedürfnisse, Messkriterien und Qualitätsplan)
Des weiteren wurden spezifische Dokumente zur technischen Realisation und Entwicklung sowie zum Projektmanagement entwickelt, um ein einheitliches Vorgehen bei Projekten und die durchgehende Messbarkeit der Projektdaten zu gewährleisten. Über die Jahre können so die erfassten Metriken verfolgt werden und ergeben Anhaltspunkte für Verbesserungen. Damit lässt sich der komparative Wettbewerbsvorteil der ELCA erklären, der sich eindrücklich in den
Wachstumszahlen der letzten Jahre niederschlägt.
4 Testverfahren im Rahmen von Sumex II
Bevor das Projekt Sumex II in Angriff genommen wurde, hat man ein Testkonzept entwickelt. Es legt die Teststrategie und das Vorgehen bei der Planung von Tests im Projekt fest. Es werden jedoch keine konkreten Testfälle entwickelt. Ein solches planmässiges Vorgehen ermöglicht den effizienten Einsatz aller zur Verfügung stehenden Ressourcen.
4.1 Verfahren
Zuerst wird das genaue Vorgehen bestimmt um möglichst viele Fehler zu finden und zu überprüfen. In Verbindung mit dem zeitlichen Druck ergibt ein strukturiertes Vorgehen einen Rahmen, in dem die Fehler möglichst früh entdeckt werden sollen.
Wichtig ist auch das Kosten-Nutzen Verhältnis hinsichtlich des Testaufwandes. Als Grundlage dient eine Risikoanalyse, welche vorgibt, was zuerst getestet werden muss.
4.1.1 Vorgehen
Es werden vier Testphasen unterschieden: Unit-, Integrations-, Systemintegrations- und Abnahmetest, auf die in Kapitel 4.2 eingegangen wird. Die bereits besprochenen Testtypen werden festgelegt. Ein Testablauf wird detailliert bestimmt:
1. Ueberwachen der Testphase (Koordination) 1.1. Planung der Tests (Risikoanalyse, Zeitbedarf) 1.2. Prüfen des Testplanes (Vollständigkeit, Prioritäten) 1.3. Ueberwachen der Testfälle (aktuellen Stand überwachen)
1.3.1. Informationslieferant für Testfälle (Dokumentation) 1.3.2. Design der Testfälle (Notwendigkeit)
1.3.3. Schreiben der Testfälle 1.3.4. Prüfen der Testfälle 1.3.5. Vorbereiten der Testdaten
1.4. Ueberwachen der Testdurchführung (Verwaltung und Koordination) 1.4.1. Konfigurationsmanagement (Test-Version)
1.4.2. Zuständigkeit für Testumgebung (Ausrüstung)
1.4.3. Durchführen der Tests (Aufzeichnen Resultate und Dauer) 1.4.4. Change Management (Fehlerprioritäten)
1.4.5. Abschluss der Tests (oder abbrechen)
Diese Liste verdeutlicht jedoch nur die wichtigsten Aktivitäten und ist nicht als strenge sequentielle Abfolge zu verstehen, das Meiste findet parallel statt.
Die Testwerkzeuge werden festgelegt:
Selbstgeschriebene Tools in Java (besonders heikel da selber geschrieben)
Javascope (Coverage-Tool)
Optimizelt (Performance für CPU und Speicher)
Cyrano Workbench (Performance der Datenbank)
4.1.2 Risikoanalyse
Wichtige oder sehr komplexe Teile des Systems müssen identifiziert werden um die Wirksamkeit und Effizienz der Tests zu steigern. Prioritäten werden zugeteilt um bei plötzlichem Termindruck eine sinnvolle Auswahl treffen zu können. Das Risiko wird aus der Eintrittswahrscheinlichkeit und den Auswirkungen berechnet:
R = W * A
Die jeweiligen Skalen reichen von eins bis drei (unwahrscheinlich bis oft / klein bis gross). Es wird zwischen funktionalen (Klassen und Methoden) und nicht
funktionalen (Hardware, Daten, Datenmenge, Schnittstellen und Sicherheit) Risiken unterschieden. Die Priorität wird nun berechnet, wobei sich der Aufwand auf Stunden, respektive finanzielle Kosten bezieht:
Priorität = Risiko / Aufwand
Eine funktionale Risikoanalyse wird bei Integrations- und Systemintegrationstests durchgeführt, eine nicht funktionale Risikoanalye nur beim Systemintegrationstest.
Die Verantwortung und somit auch die Risikoanalyse für die Abnahmetests ist Sache des Kunden.
4.2 Testphasen
Die einzelnen Unittests finden sowohl bei der ELCA, als auch beim Kunden statt. Der Inegrationstest der ELCA-Units führt die ELCA alleine durch. Der
Systemintegrationstest wird gemeinsam mit den vom Kunden entwickelten Units gemacht. Der Abnahmetest entfällt alleine auf den Kunden. Bei Bestehen des Tests wird dies in einem Dokument festgehalten, um eventuell bei späteren rechtlichen Problemen darauf zurückgreifen zu können.
4.2.1 Unittests
Die in Kapitel 4.1.1 beschriebenen Aufgaben werden wie folgt wargenommen: 1, 1.1, 1.2, 1.3, 1.4.2 durch den Projektleiter, der Rest durch den Entwickler der einzelnen Units. Diese Units bestehen aus einem Modul, einer Klasse oder gar einer ganzen Kollektion von Klassen. Kritische Units werden in einer speziell dafür entworfenen Liste (Klassen/Package Name, Entwicklername, Testbeschrieb, Schnittstellen- übersicht, anderes) aufgeführt.
Ein Unit durchläuft normalerweise folgende Tests:
Code Inspektion (nicht durch Enwickler, auf Klarheit und Verständlichkeit)
Funktionale Tests (Testprogramme, Bottom-Up, Methoden als Blackbox)
Coverage Tests (100% für kritische Units)
Performance Tests
Die Testdurchführung wird gemäss einer Spezifikation für Testfiles dokumentiert.
Testdaten sind künstliche oder reale aber anonymisierte Daten.
4.2.2 Integrationstests
Der Uebergang zum Integrationstest ist fliessend, da schon Units zu immer grösseren Einheiten zusammengefasst werden. Es werden jedoch vor allem noch die
Schnittstellen in die Tests mit einbezogen. Von verschiedenen Teams entwickelte Teilsysteme werden zum erstenmal zusammentgefügt. Die in 4.1.1 beschriebenen Aufgaben werden wie folgt aufgeteilt. 1, 1.1, 1.2, 1.3, 1.3.2, 1.4, 1.4.2, 1.4.4, 1.4.5 Projektleiter; 1.3.3, 1.3.5, 1.4.1, 1.4.3 Entwickler; 1.3.1, 1.3.4 beide. Somit testet niemand mehr seinen eigenen Code, das Change Management obliegt nun ausschliesslich dem Projektleiter. Es wird wiederum eine Liste aller kritischen Komponenten (Komponentenname, Entwicklername, Testbeschrieb, Uebersicht Schnittstellen, Teilkomponentennamen, anderes) erstellt. Im Gegensatz zum Unittest ist der Zeitaufwand nicht mehr Teil der Entwicklungszeit, sondern wird separat berechnet.
Technische Anforderungen, Benutzeranforderungen und die Risikoanalyse sind die Grundlagen der Testfälle. Generell werden Blackbox-Tests angewandt. Die
durchgeführten Tests sind die folgenden:
Funktionale Tests (gültige und ungültige Parameter)
Performance Tests (z. T. schon bei Unittests)
Stresstests
Robustheitstests
Langzeittests
Daten (Datenbank und Logfiles) werden in Stichproben inspiziert. Die Testphase ist abgeschlossen, wenn alle hochprioritären Tests und etwa 95% der niedrigprioritären durchgeführt sind. Die Probleme werden dokumentiert, das Risiko wird abgeschätzt, je eine Liste der durchgeführten Tests, der abgedeckten Anforderungen und der gemeldeten Problemmeldungen wird geführt.
4.2.3 Systemintegrationstests
Vor der Lieferung sollte das ganze System überprüft werden. Somit wird
gewährleistet, das alle technischen und alle Benutzeranforderungen erfüllt sind. Die Aufgaben nach 4.1.1 teilen sich wie folgt auf: 1, 1.1, 1.2, 1.3, 1.3.2, 1.4, 1.4.2, 1.4.4.,
1.4.5 Projektleiter; 1.3.3, 1.3.5, 1.4.1, 1.4.3 Entwickler; 1.3.1, 1.3.4 beide. Die separat beim Kunden und bei der ELCA entwickelten Teilsysteme werden zusammengeführt und getestet. Im Gegensatz zum Integrationstest werden auch „grossmassstäbliche“
Tests durchgeführt. Dadurch werden die optimale Dimensionierung und
Konfiguration des Systems, sowie potentielle Leistungsprobleme und Riskien erkannt.
Folgende grossmassstäbliche Tests werden mit realen aber anonymisierten Daten durchgeführt:
Simulation von grossen Lasten
Messung der Performance bei Lastspitzen
Test betreffend Langzeitverhalten
Test betreffend Ressourcenverbrauch
Tests betreffend Robustheit (Verfügbarkeit, Gewährleistung der Datenintegrität, Verhalten bei Pannen).
Die Ablaufplanung und Durchführung erfolgt analog zum Integrationstest, ebenso verhält es sich mit den Testfiles.
4.2.4 Abnahmetests
Nach der Lieferung des Systems werden die Abnahmetests vom Auftraggeber durchgeführt. Eventuell wird der Produzent zur Abwicklung des Tests beigezogen.
Gewisse Funktionalitäten können erst beim Abnehmer getestet werden. Daher wird zuerst ein Pilottest durchgeführt, damit sichergestellt wird, dass auch eventuelle kritische Geschäftsprozesse erfolgreich abgewickelt werden können. Die Planung, Durchführung und Dokumentation erfolgt analog zum Integrations- oder
Systemintegrationstest.
4.2.5 Vorlagen
Folgende Vorlagen können während der Tests benutzt werden, um das Erstellen von Dokumenten zu erleichtern:
Komponentenliste (Unittest (UT), Inegrationstest (IT), Systeminegrationstest (ST), Abnahmetest (AT))
Testliste (UT)
Code Review Report (UT)
Testfall (IT, ST, AT)
Liste durchgeführter Tests (IT, ST, AT)
Abdeckung der Anforderungen (IT, ST, AT)
Liste von Problem und Fehlermeldung (IT, ST, AT)
Vorlage für Problem und Fehlermeldung (IT, ST, AT)
Checkliste für Testbereitschaft (IT, ST, AT)
Fazit
Die obigen Ausführungen geben einen kleinen und sehr spezifischen Einblick in die praktische Welt des Qualitätsmanagments und des Softwaretestens. Leider ist es nicht möglich allgemein gültige Aussagen zu machen. Jedes Problem verlangt nach seiner eigenen Lösung und auch nach einer eigenen Umgebung, in der es gelöst wird. Ein Vorgehen wie eben beschrieben lässt sich nur für grosse Projekte mit einer Laufzeit von mehreren Monaten verwirklichen. Bei kleinen Projekten testet jeder für sich selber und schlussendlich wird integriert, meist ohne grosse Schnittstellenprobleme.
Und wenn doch, dann lassen sich diese meist schneller anpassen, als dass eine passende Testumgebung entwickelt werden kann.
Mir hat der Einblick in eine grosse Softwareentwicklungsfirma mit strukturierten Abläufen und einem klaren Ziel sehr viel Spass gemacht. Und ich hoffe, dass ich die dabei gewonnenen Erkenntnisse auch selber einmal einzusetzen weiss.
Literatur:
[1] http://www.iso.ch/iso/en/iso9000-14000/iso9000/qmp.html (2002) [2] Boehm, Barry und andere (seit 1998), Modelentwurf erhältlich unter
ftp://ftp.usc.edu/pub/soft_engineering/COCOMOII/cocomo99.0/modelman.pdf (2002) [3] http://www.mccabe.com/products/mccabe_iq.htm (2002)
[4] http://www.elca.ch/Home/1.html (2002)
[5] http://www.tarmed.ch/deutsch/i_infos/i_aus_f.htm (2002) [6] Pfister, A. (2001) Testkonzept und -plan zu Sumex II
