Software-Test / Testmanagement

10 Merkmale einer testfeindlichen Umgebung

Sofern Sie in der glücklichen Lage sind von sich behaupten zu können, jedes Ihrer Test-Projekte ohne Probleme über die Bühne gebracht zu haben, dann brauchen Sie hier nicht weiter zu lesen. Doch dann würde ich Sie bitten, sich mit mir in Verbindung zu setzen, um mir Ihr Geheimnis zu verraten und wäre Ihnen sehr dankbar dafür. Sofern Sie jetzt weiterlesen: Als Software-Test Manager gehe ich von mehr oder weniger schmerzhaften Erfahrungen aus, dem ganz normalen Projekt-Alltag also. Auf Basis meiner Erfahrungen habe ich versucht ein paar Elemente zu isolieren und in Worte zu fassen, die im Tester-Leben sehr oft zu eben diesen schmerzhaften (ja – ich meine tatsächlich „schmerzhaft“) Erfahrungen führen. Die folgende 10-Punkte-Liste soll helfen, zukünftig die Testumgebung in Projektumwelten in einem sehr frühen Stadium dahingehend analysieren zu können, um so entsprechend Gegenmaßnahmen ergreifen zu können.

Testumgebung

1. Unverständnis

Wenn in einem Unternehmen eine Einstellung a la „warum brauchen wir den Test – es ging doch bisher auch ohne“ existiert, wird man bei der Einführung eines Testprozesses auf vielfache Probleme stoßen, denn mit Testen ist zwangsläufig Aufwand verbunden, der bisher nicht anfiel. Zusätzlich müssten Prozesse befolgt werden, wo es bisher keine gab. Vielfach wird man dies vorfinden, wenn seitens der Unternehmensführung keine Qualitätspolitik aufgesetzt wurde und somit das Leben dieser Denkweise etwas Unbekanntes ist.

2. Multi-System-Umgebung

Es existieren viele (auch geografisch) verteilte Systeme im Verbund. Jedes System stellt eine „Insel“ dar und ist in der Sichtweise der jeweils Zuständigen der Tellerrand, über den nicht geblickt wird. Eine Sicht auf das Gemeinsame existiert nicht – es ist den Beteiligten nicht oder nur wenig bewusst, dass man gemeinsam an einem Strang zieht, um ein Produkt qualitativ hochstehend erstellen und testen zu können.

3. Angst-Kultur

Wenn man in einem Unternehmen keine Fehler machen darf, dann wird das primäre Bestreben beim Auffinden eines „Defects“ jenes sein, den Schuldigen wo anders zu suchen. Ein effizienter Testprozess ist hier nur schwer möglich, weil man in großer Menge zunächst mal gegen Verschleierungen zu kämpfen hat.

4. Geheimwissen

Requirement-Management ist ein Fremdwort und existiert als Tätigkeit nicht. Anforderungen werden nur in den seltensten Fällen schriftlich festgehalten und verwaltet. Meist ist es so, dass die umzusetzende und daher auch zu testende Fachlichkeit einzig in den Köpfen von „Wissenden“ verborgen ist. Dieses Wissen ist oft auch noch schwierig anzuzapfen, und kann nur unvollständig erfasst werden (d.h.: es gibt immer wieder Neuerungen od. Ergänzungen, die bisher nicht zur Sprache kamen). Demzufolge ist die wichtigste Quelle für den Test – die Testbasis – nicht oder nur sehr mangelhaft vorhanden.

5. Geringschätzung

„Test“ als Thema wird in seiner Wichtigkeit unterschätzt und hat unter anderem zur Folge, dass man vom Auftraggeber Mitarbeiter zur Verfügung gestellt bekommt, die anders nicht verwendbar sind bzw. auf ein Abstellgleis gestellt werden sollen. Die Zuteilung zu einem Testteam wird von den betroffenen Mitarbeitern unter Umständen als „Strafe“ empfunden weil sie sich selbst so wahrnehmen: „wir sind für anderes offensichtlich nicht verwendbar“. Weiters bekommt man oft auch unerfahrene Mitarbeiter zugeteilt, weil testen ja ohnehin „jeder kann“.

6. Tool-Phobie

„Warum soll man ein Tool für das Verwalten von Anforderungen oder Defects verwenden, wo man doch E-Mails schreiben kann?“ Diese Frage wird von Personen gestellt, die es gewohnt sind, Probleme bilateral zu klären – ohne störende Zwischenschritte über ein Tool (und dabei wird die Tatsache wohlweislich ignoriert, dass das Schreiben von E-Mails auch nur via Tool möglich ist). Je nach Einfluss solcher Personen wird man teilweise bei der Einführung von Tools auf massiven Widerstand stoßen – bis hin zu völliger Verweigerung!

7. Elfenbeinturm

Die Projektleitung lebt in ihrem Elfenbeinturm und gibt Informationen nur spärlich weiter, meist auch nicht direkt an das Testteam sondern nur über Mittelsmänner. Diese nennt man dann eventuell auch noch „Single Point of Contact“, kurz SPOC genannt, und definiert damit eindeutig, dass nur über diese SPOCs Kontakt gehalten wird. Als Folge kennen die Mitglieder des Testteams ihre Projektleitung nicht – oder nur vom Hörensagen (durch den SPOC) bzw. aus E-Mails. Das Testteam fühlt dadurch, dass seine Arbeit nicht wichtig ist und wird demotiviert – dabei würde eine einzige Besprechung pro Woche durchaus helfen, das Klima zu heben. Das Testteam ist sich in weiterer Folge auch nicht mehr darüber bewusst, dass die eigentliche Arbeit von ihnen erledigt wird und nicht von der Projektleitung – die Projektleitung ist sich dessen übrigens auch nicht bewusst.

8. Fremdherrschaft

Die Testumgebung steht nicht unter der Hoheit des Testteams, sondern wird von den Beteiligten als Spielwiese betrachtet. Es werden nach Gutdünken Software-Releases eingespielt, ohne dass dies zentral abgestimmt und koordiniert wird. Es gibt niemanden, der über den genauen Softwarestand Bescheid weiß. Organisatorische Maßnahmen mit dem Ziel, diesen Wildwuchs einzudämmen, greifen nicht. Technische Maßnahmen (Zugriffs-Sperre) greifen nicht, da die beteiligten Server (s.a. Multi-System-Umgebung) ebenfalls für das Testteam nicht greifbar sind.

9. Verantwortungs-Shift

Mangelnde Eigenverantwortung und/oder fehlendes Streben nach gelebter Qualität führt dazu, daß im Falle des Auffindens von Fehlern durch das Testteam automatisch das Testteam als die Zuständigen angesehen wird. Nicht die Verantwortlichen der am Fehler beteiligten Systeme sind für das Vorantreiben einer Lösungsfindung zuständig, sondern das Testteam muß dafür sorgen, daß alle für die Behebung des Fehlers notwendigen Basisinformationen vorhanden sind. Das Testteam dient in solchen Situationen als „Kommunikator“ und vermittelt zwischen den Beteiligten, anstatt daß die Beteiligten untereinander (aus eigenem Antrieb) kommunizieren.

10. Wasserfall: Test-am-Ende

Sämtliche Empfehlungen aus der Literatur, sämtliche Ratschläge aus erfahrenem Munde, werden ignoriert. Der Test kommt im Projekt ganz zum Schluss ins Spiel und läuft Gefahr, aufgrund der vorliegenden verspäteten Softwareübergaben an das Testteam (dies ist die Regel!), am Ende des Projektes zerrieben zu werden. In weiterer Folge ist auch „der Test“ (pauschal) schuld an eventuellen Termin-Verschiebungen.

 

Haben Sie sich beim Lesen vielleicht zurückversetzt gefühlt in Situationen aus Ihrer Projekt-Vergangenheit? Oft ist es so, dass man Probleme erst dann wirklich für sich selbst greifbar macht, wenn man sie formulieren kann. Sobald sie dann greifbar sind, kann man sie anderen gegenüber ansprechen. Insofern hat mir persönlich diese Liste schon geholfen – ich wünsche mir, dass dies für Sie ebenso zutrifft.

 

Passende Artikel

Kommentare gesperrt.