Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

04.11.2008

Die zehn größten Fehler im Test-Management

Eric Jochum
Mangelhafte Software kann das Geschäft jeder Firma ins Stolpern bringen. Nur wer seine Anwendungen richtig testet, vermindert das Risiko und erhöht die Stabilität.

Software muss heute höchsten Anforderungen genügen: Die zugrunde liegenden IT-Infrastrukturen werden immer komplexer, die Qualitätsansprüche wachsen, und der Zeitdruck steigt. Obwohl der Geschäftserfolg immer stärker von der eingesetzten IT abhängt, kämpfen viele Unternehmen mit fehlerhafter Software, überschrittenen Kostenbudgets oder nicht eingehaltenen Projektlaufzeiten.

Mit Hilfe eines Softwaretest-Managements lassen sich diese Probleme vermeiden. Fehler können zu jedem Zeitpunkt des Software-Lebenszyklus erkannt und behoben werden. Die folgenden Erfahrungswerte zeigen, welche Fehler man vermeiden sollte:

Verzicht auf Test-Management

Der erste Fehler, den Unternehmen in Sachen Test-Management machen, ist so einfach wie nahe liegend: Sie haben keines. Test-Management wird in den meisten Fällen weder methodisch geplant noch umgesetzt. Oft denkt sich der verantwortliche Projektleiter erst am Ende des Entwicklungsvorhabens eine Handvoll Testfälle aus und überprüft lediglich stichprobenartig und unsystematisch einige Funktionen der Software.

Meist werden an diesem Punkt zu viele Fehler gefunden, um sie rechtzeitig zu korrigieren und das Projekt noch innerhalb der geplanten Laufzeit fertig zu stellen. Obwohl die Software längst eingeführt werden sollte, müssen nun erst noch Fehleranalysen und Fehlerkorrekturen betrieben werden. Dies erzeugt deutlich mehr Aufwand als ursprünglich geschätzt. Zudem ist meist keine Zeit mehr, die Korrekturen sowie die gesamte Software erneut zu testen. Das Ergebnis bleibt somit risikobehaftet.

Manche IT-Abteilungen setzen zwar das Thema Test auf ihre Agenda, vergessen in ihrer Kalkulation aber die Korrekturen - ein weiterer Faktor, der versteckte Kosten und Zeitverluste innerhalb eines Projekts bedeuten kann. Deshalb sollte nicht nur der Test eingeplant werden, sondern auch die Korrektur von Fehlern sowie ein entsprechender Regressionstest. Darunter versteht man die Wiederholung aller Testfälle oder einer Teilmenge, um mögliche Nebenwirkungen von Modifikationen in unveränderten Teilen der Software aufzuspüren.

Unterschätzte Komplexität und Vorbereitungsdauer

Viele Unternehmen beginnen mit dem Testen zu spät. Oft handeln sie dabei auch nach dem Irrglauben, dass erst ein großer Teil der Software erstellt sein muss, damit Tests überhaupt sinnvoll sind. Die Folge: Fehler werden erst zum Projektende entdeckt. Mit einem systematischen Test-Management kann von Beginn der Entwicklung an projektbegleitend getestet werden. So lassen sich Fehler schnell in den Entwicklungsstufen finden, in denen sie entstanden sind. Auf diese Weise ist eine weniger aufwändige Korrektur möglich, und folgende Entwicklungsstufen bauen nicht auf unentdeckten Fehlern auf. Darüber hinaus lassen sich bereits während der Projektlaufzeit Qualitätsaussagen zum fertigen Produkt treffen.

Schlechtes Testdaten-Management

Der wichtigste Schritt des Testdaten-Managements ist die komplette Erfassung der vollständigen Testdaten. Einige Unternehmen beschränken sich an dieser Stelle darauf, den Testfall zu beschreiben, und vergessen darüber hinaus, ein vollständiges Datenset zu definieren, welches für die spätere Erfassung notwendig ist. Kernpunkt für den Erfolg ist es, Testdaten dauerhaft zu verwalten. Das kann heißen, neue Daten hinzuzufügen, ebenso aber auch, vorhandene Daten anders zusammenzustellen.

Kann man während des Testens nicht auf den passenden Datenbestand oder nur auf alte Daten zurückgreifen, so führt das zu erneutem Zeitverzug und möglichen Fehlerquellen. Zudem ist es Aufgabe des Testdaten-Managements, zu wissen, welche Daten an welchen Tagen welche Ergebnisse auslösen können und welche Ergebnisse erwartet werden dürfen. Damit das Risiko-Management gelingt, ist es unbedingt notwendig, über die gesamte Projektlaufzeit entsprechende Ressourcen einzuplanen.

Fehlende Testautomatisierung

Man unterscheidet zwischen der codenahen und der GUI-Testautomatisierung. Unternehmen machen den Fehler, entweder keine codenahe Testautomatisierung anzusetzen oder die GUI-Testautomatisierung zu früh zu beginnen. Verzichtet man auf eine codenahe Testautomatisierung, verschenkt man eine preiswerte Möglichkeit, zeitig Aufschlüsse über die Qualität des Systems zu erhalten.

Typischerweise kommt es in frühen Projektphasen noch zu Änderungen in den spezifizierten Masken, da Anforderungen künftiger Benutzer übersehen wurden oder sich nachträglich noch ändern. Wird eine GUI-Automatisierung zu früh angesetzt, muss sie alle Änderungen der Masken nachziehen. Dies treibt den Wartungsaufwand der GUI-Automatisierung in die Höhe.

Optimal wären eine frühe codenahe Testautomatisierung und zusätzlich eine GUI-Testautomatisierung zum Projektende. Auf diese Weise lässt sich ein Großteil der bestehenden Funktionen mit einer daraufhin erstellten Automatisierung kostengünstig in Form von Regressionstests prüfen. An dieser Stelle spielt auch das erwähnte Testdaten-Management eine wichtige Rolle. Eine Automatisierung, egal ob codenah oder auf das GUI bezogen, verlangt Testdaten, die sich immer wieder in ihren Ursprungszustand zurückversetzen lassen. Nur so liefert das zu testende System für die Automatisierung vergleichbare Ergebnisse.

Unterschätzter Know-how-Bedarf

Unternehmen begehen häufig den Fehler, die Entwickler der Software auch als Tester einzusetzen. Dies liegt zwar nahe - wer kennt die Software besser als ihr Autor? Die Erfahrung hat jedoch gezeigt, dass den Entwicklern der objektive Blick auf ihre Software fehlt. Sie neigen dazu, nur die Funktionen zu testen, für die sie das Produkt entwickelt haben. Negativfälle, in denen Anwender falsche, nicht nachvollziehbare Eingaben machen, werden von ihnen in aller Regel nicht berücksichtigt. Im Übrigen verfügen die meisten Entwickler auch nicht über das spezifische Wissen eines Testers, da es in der Ausbildung meist nicht berücksichtigt wird.

Das Test-Management zeigt zwar Defizite in der Qualität der Software auf, viele Unternehmen tun sich aber schwer, den daraus resultierenden Nutzen zu quantifizieren. Oft müssen erst Fehler in der Produktion auftreten, damit entsprechende Budgets eingerichtet werden. Dementsprechend sollten die Verantwortlichen die Komplexität und das notwendige Know-how frühzeitig identifizieren und handeln, bevor Fehler auftreten.

Entwicklung und Testen von Software sind hochkomplexe Aktivitäten, die - wenn sie gut aufeinander abgestimmt sind - maßgeblich zur Gesamtqualität beitragen. Eine unabhängige Testabteilung ergänzt die Softwareentwicklung, niemals kann jedoch eine Abteilung die andere ersetzen.

Verzicht auf methodisches Vorgehen

In der Praxis testen Unternehmen häufig ziel- und planlos. Viele manuelle Schritte, Redundanzen, unterschiedliche Dokumentationen und daraus resultierende Mehrkosten sind an der Tagesordnung. Intuitiv versuchen Tester, die richtigen Testfälle zu ermitteln. Dabei werden Testfälle übergangen, mehrfach erstellt, oder man findet nicht die richtigen beziehungsweise wichtigen. Das Ergebnis: Ein effektives Testen wird unmöglich.

Mit einem methodischen Vorgehen lassen sich dagegen die richtigen Testfälle in der richtigen Zahl finden. Die Unternehmen können damit auch den Aufwand für das Testen und den Support maßgeblich senken. Das bedeutet höhere Qualität, geringere Kosten, verbesserte Dokumentation der Systemanforderungen, eine geringere Ausfallrate und schließlich zufriedenere Kunden.

Experten haben sich unter dem Dach des International Software Testing Qualifications Board (ISTQB) zusammengeschlossen, um dieses methodische Vorgehen in die Ausbildung für professionelle Softwaretester zu integrieren. Gute Tester sind heute schwer zu finden, mit einem ISTQB-Zertifikat hat man eine Basis geschaffen, die Qualität der Tester zu belegen.

Ungeeignete Testwerkzeuge

Oft betrachten Unternehmen den frühen Einsatz von Werkzeugen als Allheilmittel für all ihre Testprobleme. Dies ist jedoch ein Irrglaube. An erster Stelle jeder Optimierung des Test-Managements steht die Ausarbeitung der unternehmerischen Prozesse und Methoden. Erst wenn diese definiert sind, können Werkzeuge ausgewählt werden, die optimal dazu passen. Für kleine Unternehmen können sich hier mehrere Einzellösungen genauso sinnvoll ergänzen, wie sich möglicherweise für große Unternehmen integrierte Tool-Suites als richtig erweisen.

Auch ein zu später Werkzeugeinsatz kann die Tests entwerten. Häufig versuchen die Unternehmen allzu lange, bestehende Prozesse in bereits genutzte Tools wie Excel oder Word hineinzuprogrammieren. Fazit: Nur die richtigen Werkzeuge zum richtigen Zeitpunkt steigern Effektivität und Effizienz bestmöglich.

Unpassende, zu viele oder zu wenige Testfälle

Unerfahrene Tester und unsystematisches Vorgehen führen zu redundanten und fehlenden Testfällen. Zu viele Testfälle können einerseits Redundanzen bedeuten. Die Firmen verschenken damit Zeit und finanzielle Mittel. Zu wenige oder falsche Testfälle führen andererseits zu einer unzureichenden Abdeckung. Es bleiben ungetestete Funktionen zurück, mit dem Risiko, dass sie Fehler aufweisen, die in die Produktion gelangen. Mit analytischen, heuristischen oder systematischen Methoden lassen sich dagegen die richtigen Testfälle auswählen.

Last- und Performance-Test erst am Projektende

Last- und Performance-Tests sind ein wichtiges Instrument, um das System mit Blick auf das zu erwartende Benutzerverhalten zu prüfen. Ziel ist es, die Skalierbarkeit verschiedener Funktionen der Applikation zu ermitteln. Lasttests sind aufwändig, weshalb Unternehmen oft dazu neigen, sie erst am Ende eines Projekts anzusetzen. Jedoch lässt sich bereits während der Entwicklung testen, welcher Last das fertige Softwareprodukt künftig standhalten kann.

Probleme sind fast immer in der Softwarearchitektur begründet, die zu Beginn des Projekts entworfen wird. Testet man nun erst am Ende eines Entwicklungsvorhabens und findet solche Fehler verspätet, bedarf es eines großen Zeit- und Kostenaufwands, da man wieder am Anfang einhaken muss. Das kann einen zusätzlichen Zeitverlust sowie Mehrkosten bedeuten, welche die Verantwortlichen in aller Regel nicht einkalkuliert haben. Last- und Performance-Tests müssen deshalb immer von Beginn an konzipiert und entwicklungsbegleitend eingeplant werden.

Tester müssen Methoden anwenden, aber auch Ergebnisse auswerten.
Tester müssen Methoden anwenden, aber auch Ergebnisse auswerten.

Unterschätzte Folgen fehlerhafter Software

Was bedeutet eine fehlerhaft laufende Software für ein Unternehmen? Welche Kosten bringt eine verspätete Einführung? Wie wirken sich Lücken in der Software auf die Produktivität der Mitarbeiter und schließlich das Erreichen der Geschäftsziele aus? All das sind Fragen, denen sich die Verantwortlichen in den Unternehmen stellen müssen. Software darf heute nicht mehr nur vom Blickwinkel der IT aus betrachtet werden, denn sie hängt direkt mit den meisten Geschäftsprozessen des Unternehmens zusammen. Damit wird sie zu einem der kritischen Faktoren für Erfolg oder Misserfolg.

Unterschätzen die Verantwortlichen das und dulden sie mögliche Fehler, Verzögerungen oder Ausfälle, die durch Test-Management vermeidbar gewesen wären, schaden sie der Bilanz und dem eigenen Ansehen. Letztlich kann sogar der Verlust von Kunden drohen. Deshalb sollten Unternehmen eine Test-Management-Organisation aufbauen, die eigenständig und unabhängig von der Entwicklung arbeitet und damit vor den genannten Problemen schützt.

Fazit

Entwicklungsbegleitendes Testen anhand des V-Modells: Die verschiedenen Teststufen sind mit den jeweiligen Entwicklungsstufen verbunden.
Entwicklungsbegleitendes Testen anhand des V-Modells: Die verschiedenen Teststufen sind mit den jeweiligen Entwicklungsstufen verbunden.

Um den hohen Anforderungen gerecht zu werden, welche heute an Software in hochkomplexen und unternehmenskritischen Bereichen gestellt werden, bedarf es Tests auf jeder Stufe der Entwicklung. Unternehmen brauchen dazu ein strukturiertes Test-Management sowie qualifizierte Tester und Test-Manager. (ba)