Typische Schwachstellen eines Testprojekts

Die Top Ten der methodischen Fehler im Softwaretest – Teil 2
Kommentare

Der erste Teil dieser Artikelserie behandelte das Risiko, das eine Unterschätzung von Fehlern im Testprojekt birgt, sowie die Nachteile, die aus einem Aufschieben von Performance-, Last- und Stresstests bis zum Entwicklungsende erwachsen. Im zweiten Teil wird nun die Problematik fehlender Testfallabteilungen sowie ungeeigneter Testwerkzeuge erörtert.

Keine (professionelle) Testfallableitung

Selbst heute ist der Begriff Testfallableitung oder Test Case Design in vielen Testteams nicht präsent. Auch wenn Testpläne (Testkonzept, engl. test plan) existieren, entstehen in der Praxis die notwendigen Testfälle oft quasi aus dem „Nichts“. Die Art und Weise der Herleitung aus den Spezifikationen und Anforderungsdokumenten von Entwicklung und Business ist in der Regel nicht nachvollziehbar. Die Folge daraus ist eine Verdichtung von Testfällen in einigen Bereichen. Hier mag sich unter Umständen die Frage nach einer Optimierung der vorhandenen Testfälle stellen, um Testzeiten zu sparen, ohne die Qualitätsaussage zu schmälern (Effizienz). Bei anderen Themen kann es aber im gleichen Testprojekt keine oder kaum Testfälle geben, sodass hier tatsächlich unbekannte Risiken nicht geprüft werden (Effektivität). Oft repräsentiert die konkrete Ausprägung beider Aspekte das aktuelle Know-how der Person, die die Testfälle definiert hat. Die Testfallableitung basiert also allein auf persönlichen Kenntnissen und Erfahrungen. Anerkannte Optimierungsmethoden aus der Mathematik können auf dieser Basis aber nicht zum Einsatz kommen. Damit sind heutige Testanforderungen in Bezug auf optimale Testfallüberdeckung und Nachvollziehbarkeit der Testfallableitung nicht zu unterstützen.

Es hat sich bewährt, je nach Teststufe geeignete Testfallableitungs- und Optimierungsverfahren im Rahmen der Spezifikationsphase zu benutzen. Als Beispiele möchte ich hier die Verfahren Äquivalenzklassenanalyse, MCDC (Modified Condition/Decision Coverage), Pair- und Triplewise-Testing anführen (Abb. 1). Sollten im weiteren Verlauf Schwächen innerhalb von Tests erkannt werden, die auf Lücken in der Testüberdeckung hinweisen, so bestehen – durch die Nachvollziehbarkeit der Ableitung – wesentlich mehr und präzisere Anpassungsmöglichkeiten.

Abb. 1: Übersicht verschiedener Testdesigntechniken und Überdeckungsgrade

Abb. 1: Übersicht verschiedener Testdesigntechniken und Überdeckungsgrade

Ungeeignete Testwerkzeuge

Testwerkzeuge werden in ihrer Bedeutung stark unterschätzt. In vielen Bereichen werden kaum professionelle Werkzeuge berücksichtigt. Hierzu gibt es eine ganze Reihe von Fehleinschätzungen, die je nach Unternehmen in verschiedenen Ausprägungen auftauchen:

1. Vielfach existiert die Einschätzung, allein der Einsatz von Testtools würde den Testprozess oder gar die Produktqualität verbessern. Man meint, durch die reine Installation einzelner Testwerkzeuge oder gar entsprechender Enterprise-Lösungen/ Toolsuites den Testprozess zu verbessern. Es ist jedoch ein Irrglaube, dass allein hierdurch ein Testprozess standardisiert oder optimiert würde. Vor der Toolentscheidung sollten die unternehmensbezogenen Testprozess- und Richtlinienfragen sowie das Berichtswesen in den Dokumenten, wie Teststrategie und Testhandbuch, geklärt beziehungsweise definiert sein. Eine weitere Ideenvariante ist in diesem Zusammenhang die Annahme, dass sich gar die Produktqualität des zu testenden Systems verbessern würde. Durch das Testen alleine entsteht jedoch keine bessere Qualität am getesteten Objekt: Es lässt sich vielmehr durch professionelles Testen sehr präzise die aktuelle Produktqualität bestimmen, mehr aber auch nicht. Qualitätsverbesserungen lassen sich nur in den entsprechenden Entwicklungsprozessen realisieren.

2. Unternehmen sind oft von ihren neu erworbenen Testsystemen nach kurzer Zeit enttäuscht und integrieren diese nicht in ihrem Testbetrieb. Es ist fast gänzlich unbekannt, dass Testwerkzeuge erst über entsprechende Anpassungen ihre tatsächliche Leistungsfähigkeit entwickeln können. Die Einführungsphasen werden also viel zu kurz geplant, da wichtige Aufgaben innerhalb dieses Einführungsprojekts fehlen. Die zu frühe Produktivsetzung der Werkzeuge führt zu Enttäuschungen, da die zuvor erzeugte Erwartungshaltung nicht erfüllt wird.

3. Testtools werden gar nicht oder zu spät eingesetzt. Oft bleiben Testtools aber auch vollständig unberücksichtigt oder werden zu spät innerhalb der Testprojekte eingesetzt. Zu lange versucht man, auf bekannte Anwendungen, wie Text- oder Kalkulationssysteme, zurückzugreifen, um diese dann als Testwerkzeuge zu nutzen. Vielfach gibt es in Softwareunternehmen auch Kombinationen aus diesem Punkt mit Punkt 1 und 2. Es finden sich über deren Makrosprache „aufgebohrte“ Programme zur Testunterstützung in vielen Testlabors. Diese sind aus zweierlei Gründen sehr kritisch zu sehen. Rein funktional betrachtet können derartige Werkzeuge kein Testtool ersetzen, da wichtige, funktionale Elemente für die Prüfung von Testobjekten fehlen. Diese Lösungen kommen meistens nicht über das Qualitätsniveau eines Labormusters hinaus. Daneben gilt es, auch die juristische Komponente zu betrachten. Viele Lizenzverträge schränken die Benutzung der besagten Anwendungen ein. So soll ein Kalkulationsprogramm tatsächlich nur für Kalkulationen genutzt werden. Steht ein derartiger Paragraph im Vertrag, wäre beispielsweise der Einsatz des Programms als Testautomationstool unzulässig: Dies wäre mit einer Benutzung der Anwendung ohne gültigen Lizenzvertrag vergleichbar.

Testtools sind wichtig. Jedoch ist eine Einführung ohne die notwendigen Vorarbeiten im Bereich Testprozessdesign wenig sinnvoll. Dies setzt ein etabliertes Qualitäts- und Testhandbuch voraus. Auf dieser Basis lassen sich anschließend Kriterienkataloge für die Evaluation der verschiedenen Testlösungen und deren Werkzeuge entwickeln und die am besten geeigneten Testwerkzeuge auswählen. Nur auf diese Weise können Testtools Testprozesse unterstützen und ihren Nutzen ausspielen. Andernfalls überlässt man es eher dem Zufall, wie gut sich am Ende die ausgewählten Werkzeuge auf die Testprozesse abstimmen lassen.

Weiter mit: Teil 3

Alle Teile: Teil 1, Teil 2, Teil 3, Teil 4, Teil 5, Teil 6

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -