Typische Schwachstellen eines Testprojekts

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

Im ersten Teil dieser Serie über Fehler und Fallstricke in Softwaretests wurde das Risiko, das eine Unterschätzung von Fehlern im Testprojekt birgt beleuchtet, im zweiten Teil die Problematik fehlender Testfallabteilungen sowie ungeeigneter Testwerkzeuge erörtert. Teil drei beschäftigt sich nun mit „planlos“ durchgeführten Tests und der Unterschätzung von Test-Know-how.

Keine Testmethodik

Tests werden in der Regel relativ planlos durchgeführt. Aufgrund fehlender Testfallbeschreibungen und Testpläne lassen sich oft nur intuitive Tests innerhalb der Testausführung realisieren. Der Einsatz einer Testmethodik hilft dabei, alle Testthemen – insbesondere die Aufgaben Testspezifikation und Testvorbereitung – im Vorfeld einer Testdurchführung zu behandeln. Hierdurch werden die Risiken in Bezug auf Störungen innerhalb der Tests deutlich reduziert. Ferner lassen sich durch den Einsatz weiterentwickelter Testfallableitungstechniken präzisere Testfälle mit einer besseren Testüberdeckung realisieren. Sind alle Testfälle, Testdaten und Testumgebungen dokumentiert, so sind die Voraussetzungen zur Einführung eines KVP (Kontinuierlichen Verbesserungsprozesses) gegeben.

Doch wie entwickelt man eine geeignete Testmethodik? Eigentlich ist das nicht mehr notwendig, denn es gibt erfreulicherweise bereits einige Testmethodiken am Markt, wie das TMap (Test Management Approach). Auch in den ISTQB Best Practices (International Software Testing Qualifications Board) finden sich die wichtigsten Testthemen wie auch ein Testphasenmodell (der fundamentale Testprozess). Es empfiehlt sich, diese Konzepte beziehungsweise dieses Wissen durch eigene Anpassungen oder Erweiterungen modifiziert beziehungsweise ergänzt im konkreten Umfeld einzuführen. In diesem Zusammenhang möchte ich nicht vergessen, auf die Bedeutung des Unternehmensleitbilds einzugehen. Dieses sollte auf das Unternehmen bezogen die wichtigsten Faktoren, also Unternehmensauftrag (Mission), Werte, Regeln und Ziele bestimmen. Hierbei ist es zum Beispiel für Testteams wichtig zu wissen, wie sich das Unternehmen in Bezug auf die Erfolgstriade (Zeit, Kosten und Qualität) positioniert. Gleichzeitig lassen sich nicht alle drei Dimensionen mit der gleichen Bedeutung belegen. Dieser Fall lässt sich nicht auflösen, da er eine Konfliktsituation darstellt. Es bedarf folglich einer Rangfolge zwischen den drei Faktoren, und das Leitbild sollte den wichtigsten Faktor benennen. Ob dieser nun die Kosten, die Zeit oder die Qualität darstellt, beeinflusst natürlich sehr stark die Entwicklung der fachbezogenen Regelwerke, wie beispielsweise des Qualitätsmanagementhandbuchs. Hiervon leiten sich die Teststrategien und weiterführende Testhandbücher ab. Fehlen entlang dieser logischen Kette einzelne Bereiche, so lässt sich keine sinnvolle Testmethodik mehr etablieren. Zumindest würde es nicht verwundern, wenn die betreffenden Methoden die Unternehmensziele nicht optimal berücksichtigten. Oft wird gerade das Unternehmensleitbild in seiner Bedeutung unterschätzt: Entweder fehlt das Dokument, oder es fehlen wichtige allgemeine Vorgaben, wie die konkrete Anwendung der Erfolgstriade. So wird es für Fachabteilungen schwierig, Entscheidungen zu treffen, die auch langfristigen, strategischen Zielen optimal entsprechen.

Test-Know-how wird unterschätzt

Betrachten Sie einmal die Universitätslandschaft und suchen Sie in Deutschland Fakultäten oder wissenschaftliche (An-)Institute, die sich dem Thema Softwarequalität wirklich ernsthaft annehmen. Hier gibt es einige vorbildliche Ausnahmen, mehr jedoch auch nicht. In einem der für die nächsten zwanzig Jahre strategisch wichtigsten Bereiche der Softwareindustrie ist das zu wenig. Gelegentlich frage ich bei Universitäten an, warum eine derartige wissenschaftliche Einrichtung nicht innerhalb des Campus existiert. Die interessanteste Antwort hierzu war bis jetzt folgende: „Prinzipiell wäre es ein durchaus interessantes Thema. Unterdessen entwickeln wir jedoch in unseren Fakultäten Software auf einem so hohen Niveau, dass Fehler eigentlich gar nicht mehr auftreten. Offensichtlich behandeln wir bereits indirekt das Thema Softwarequalität ausreichend genug.“ Wie ehrlich die Antwort gemeint war, weiß ich nicht.

Folglich mag es auch nicht verwundern, wenn letztlich Unternehmen das Testthema mit einem ähnlich gelagerten Stellenwert behandeln, wie es wissenschaftliche Zentren vorleben. So werden ganze Testprojekte oft an Aushilfskräfte vergeben, oder man betraut Entwickler mit den Testaufgaben. In Teilen mag es sinnvoll sein, jedoch verkümmert das Testen auf diese Weise oft zur Alibiveranstaltung. Generell sprechen viele Argumente gegen solche Entscheidungen, wie beispielsweise:

• Testen ist nicht trivial. Die Basis der oben geschilderten Grundhaltungen liegt oft in der Annahme, dass Testprozesse einfach seien. Ich bezeichne diese – eigentlich nicht existente – Testkategorie kurz als Dumpfbacken-Testing: Dieses Paradoxon geht von der Annahme aus, erfolgreiches Testen sei ohne tieferes Verständnis über die Testthematik möglich. Es ist jedoch eine Tatsache, dass Testen im Softwareumfeld profunde Kenntnisse in mindestens drei Domänen benötigt: in den Themen um das Testen (Methodologien, Technologien und Organisationen), um die technischen Detailkenntnisse bezüglich der zu testenden Produkte sowie um die verwendeten Testwerkzeuge. • Entwickler können nicht testen. Die zunächst etwas provokativ anmutende Aussage liegt jedoch im Bereich der Psychologie begründet. Entwickler entwickeln bekanntlich ihr Produkt. Das ist deren eigentliche Aufgabe. Psychologisch gesehen ist es deren „Baby“, das durch sie gehegt und gepflegt wird. Eine ihrer Aufgaben besteht auch darin, alle Widrigkeiten von ihrem Entwicklungsprojekt abzuwenden, damit sich das Produkt bestmöglich entfalten kann. Das ist auch richtig und wichtig, denn wie sonst sollen Entwickler die vielen Hürden nehmen, die bekanntlich jede Entwicklungsaufgabe in sich birgt? Der Testprozess – betrachtet unter dieser Prämisse – stellt jedoch einen destruktiven Prozess dar, da er potenziell dem Projekt schaden könnte: Das vielleicht schlechte Testergebnis könnte gar die Entscheidung nach sich ziehen, das besagte Projekt einzustellen. Die oben gemachte Aussage zielt also primär nicht darauf ab, die Kompetenz von Entwicklern infrage zu stellen, sondern sie fokussiert auf die Konfliktsituation, in der sich ein Entwickler bei der Übertragung qualitätssichernder Aufgaben befindet. Die Gefahr ist zu groß, dass unbewusst nur die funktionierenden Anwendungspfade getestet werden und nicht alle möglichen. Damit wäre die Qualitätsaussage am Testende unvollständig und wenig aussagekräftig. Sinnvolle Managemententscheidungen in Bezug auf die Produktfreigabe können so nicht getroffen werden. So verwundert es kaum, dass bei diesem Szenario in der Produktion trotz guter Testergebnisse noch überraschend viele Defekte auftreten. Oft hört man in diesem Zusammenhang auch als Schlussfolgerung, dass Testen wohl doch nicht sinnvoll sei. Es sei ja als Instrument ungeeignet, Defekte vorzeitig zu erkennen, bevor die Anwendung produktiv gesetzt wird.

Heute beschränkt sich Testen keineswegs mehr auf explorative Ansätze und Improvisationen. Schon längst hat sich fundamentales Wissen etabliert. Die ISTQBZertifikate dokumentieren dies sehr deutlich. Wer nun aber denkt, dass die besagten Zertifikate der drei Skill-Stufen (Foundation, Advanced und Expert Level) das Maß aller Erkenntnisse seien, der irrt. Dieses Wissen ist als Basis-Know-how als eine Art Standard (damit meine ich jedoch keinen Industriestandard oder eine Norm im Qualitätssinne) zu verstehen – also im Sinne eines belastbaren Wissensfundaments zum Aufbau weiterführender, hoch entwickelter Testtechnologien. Erst mithilfe von Testtechnologien, mit dem damit verbundenen, erweiterten Erfahrungshorizont aus deren Entwicklung wie auch dem Betrieb, entwickelt sich aus dem Testen eine Ingenieursdisziplin, die entsprechende leistungsfähige und professionelle Testdienstleistungen ermöglicht. Dies ermöglicht den Sprung vom Facharbeiter auf das Expertenniveau zum anerkannten Testingenieur. Aus einem Fachgebiet wird dann eine anerkannte Wissenschaft.

Weiter mit: Teil 4

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 -