Allgemeiner Hinweis
Informationen in Fragen der Testplanung und
-durchführung sowie Toolunterstützung beim Testen
bietet das Support-Zentrum Test der PSE.Wozu
testen wir?
- Um ein System zu erhalten, das so fehlerfrei
wie nötig (!) ist
- Um die Entwickler zu informieren, wie sie Fehler
vermeiden können!
- Um ein "testable design"
zu erreichen - ein Design, das überhaupt erst
das Auffinden von Fehlern ermöglicht!
- Um Abweichungen von
explizit oder implizit erwarteten
Systemeigenschaften festzustellen ("breaking
the software")
- Um dem Management Information über
die Qualität eines Systems zu
geben - zur Entscheidung über die Verwendung des
Systems und seine Weiterentwicklung
- Um ein System zu validieren,
d.h. zu zeigen, daß es einer Spezifikation
genügt
[nach B.Beizer, "Black Box Testing", p.7]
Test-Coverage als Testendekriterium
Coverage (Testüberdeckung) ist eine gute Annäherung an
die Güte des Tests, aber mit
großer Vorsicht zu behandeln. Wichtig dabei ist die
Akkumulierung regredierbarer Testfälle aller Art wie
z.B.
- Benutzeroberflächentests formal
- Zweigüberdeckung im Code via Instrumentierung
- Funktionale Tests (gemäß Spezifikation,
markiert)
- Anwenderszenarien (Use Cases),...
Nach Kaner (Cem Kaner : 'Testing computer software',
Int. Thomson Computer Press, 1993) gibt es ca. 100
verschiedene Coverage-Arten. Über die Testfallarten hat
man eine Beziehung zu den wahrscheinlich zu entdeckenden
Fehlertypen und damit kann Coverage als Testendekriterium
genommen werden.
Die verschiedenen Sichten des Tests auf das Produkt
sind wichtig, hingegen ergibt die Berechnung einer
Gesamt-Coverage keinen Sinn!
Testbarkeit
Der Aspekt der Testbarkeit - die
Möglichkeit der Verifikation der über eine
Schnittstelle angebotenen Funktionalität durch eine
Teststrategie - sollte in allen Phasen der
Software-Entwicklung berücksichtigt
werden. Die Entwickler sollten auf Testbarkeit und
ausreichende Dokumentation des Code achten. Guidelines
dazu werden vom Test Support-Zentrum zur Verfügung
gestellt.
Technologiemanagement
Für ein erfolgreiches Projekt muß es einen
Mechanismus für die Ermöglichung von ständigen
Verbesserungen beim Test geben
(Fahrplan für ein Test Improvement Road
Map):
- Neue Technologien tauchen auf
- Neue Erkenntnisse bei
Tagungen/Workshops?
- Welche Erfahrungen gibt es -> Test
Support-Zentrum?
- Bedürfnisse werden ermittelt
- Welches Modell wird beim Test
verwendet z.B.
Funktionsnachweismodell: 'Jeder
fehlerfreie Testfall erhöht die
Qualität des Produkts!'
- Praktiken im Projekt werden überprüft
- Werden Leitfäden verwendet?
- Können Verfahren verbessert und neue
Tools eingesetzt werden?
- Alternativen werden ermittelt
- Welche Leitfäden sollen von
Entwicklung/Test verwendet werden?
- Welche geeigneten Tools sind am Markt
verfügbar?
- Verbesserungen werden ermöglicht
- Erlaubt die Termin-Situation eine
Verbesserung der verwendeten
Praktiken?
- In welchen Teilprojekten werden die
neuen Methodologien, Tools angewandt?
- Konnte die Effektivität und
Effizienz des Tests gesteigert
werden?
- und dann wieder Punkt 1
Organisatorische und strategische Aspekte beim
Test
Bei den Test betreffenden Entscheidungen spielen die
Faktoren Zuverlässigkeit, Menge an Features,
Projektkosten und Auslieferungsdaten eine große Rolle.
Damit der Test genügend Budget zugeteilt bekommt, muß
die Arbeit der Tester zu erhöhter Kundenzufriedenheit
führen und den Gewinn der Firma steigern helfen. Eine
Firma hofft die Qualitätskosten zu reduzieren. Daher ist
es Aufgabe des Tests den Nutzen des Tests in Hinblick auf
die Reduktion anderer Qualitätskosten herauszustellen.
Ein Beispiel: Kann man
nachweisen, daß sich Testautomatisierung bereits nach 3
-5 fiktiven manuellen Tests amortisiert und ca. 50
Regressionstest-Läufe im Software-Lebenszyklus zu
erwarten sind, so ist der Aufwand für den Aufbau der
Infrastruktur für automatisierte Tests ausreichend
begründet.
Qualitätskontrolle des Testens
Ist der Test effektiv, d.h.
werden die Fehler gefunden, die gefunden werden sollen?
Eine der Maßnahmen ist Error Seeding,
d.h. der gewollte Einbau von typischen Fehlern in
ausgewählten Moduln, um die Fehleraufdeckungs-Kapazität
der Testfälle zu testen.
Workflow im Entwicklungsprozeß
Für einen effizienten Einsatz von Test-Methodologien,
-Tools im Entwicklungsprozeß ist die Erstellung eines Workflow-Diagramms
erforderlich. Dieses enthält die Daten (e.g.
Detailspezifikation), die Aktivitäten (z.B.. Design von
Testfällen), Benutzer (Designer, Programmierer, Tester
etc.). Im Diagramm werden beginnend mit der Phase
Definition bis zum Einsatz alle Beziehungen - z.B.-
'erzeugt', 'benötigt', 'behandelt' etc. - zwischen den
Objekten definiert.
Integration des Testens mit anderen Aspekten
der Qualitätssicherung
Die folgenden Maßnahmen ändern die Art der
auftretenden Fehler:
- Vorbereiten und Durchführen von Reviews (auch
bei Testfall-Design mit der Entwicklung).
- Aus- und Weiterbildung der Tester
- Verwendung von adäquaten Methoden und Tools
(Design-Tools, Code-Generatoren etc.)
- Fehlerursachenanalyse (Warum werden bestimmte
Fehler erst beim Kunden entdeckt?)
- Definition von Metriken
"Tester-Thinking"
Um Test-Aufgaben erfolgreich zu bewältigen, ist - analog
zum "Programming Thinking" des Entwicklers -
ein "Tester Thinking" nötig - mit den Zielen,
- möglichst effizient
Fehler zu finden
- möglichst systematisch
Fehler zu finden
- möglichst viele Fehler
zu finden.
Kaner: 'As a final note, I hope that
you'll take a moment to appriciate the richness,
multidimensionality, and complexity of what we do as
testers'.
|