Knowledge Management / Software-Test / Test Center / Testmanagement

Erfahrung im Test: Ja lernen wir denn nie?

Erfahrung im Test heißt nicht immer, dass wir wirklich als Organisation daraus lernen. Oft endet es damit, dass man kollektiv die Fehler immer wieder macht. Bleiben wir tatsächlich blind? Das Test Service Center könnte ein Modell sein, um als Organisation im Test wieder lernfähig zu werden.

Trotz Erfahrung blind. Organisationen lernen nicht von allein.

Trotz Erfahrung blind. Organisationen lernen nicht von allein.

 

Warum Erfahrung im Test nicht Lernen ist und was Tucholsky damit zu tun hat.

„Erfahrung heißt gar nichts, man kann seine Sache auch 35 Jahre schlecht machen“.

So treffend kritisierte Kurt Tucholsky die Weltanschauung seiner Zeitgenossen zwischen den beiden Weltkriegen. Ich denke, die Menschen haben dann doch etwas gelernt aus der Erfahrung der damaligen Zeit, aber welchen Preis haben sie dafür bezahlen müssen! Tucholskys Zitat spricht hier eine bittere Erkenntnis aus, die auch auf meinen simplen Alltag in der IT zutrifft.

Lernen wir aus den Erkenntnissen, die wir Jahr für Jahr in den Projekten gewinnen? Wir haben ein Ergebnis erzielt. Aber war es auch gut? Hat es die Erwartungen erfüllt? Haben wir effizient gewirtschaftet?

Vielleicht liegt es daran, dass ich als Testspezialist offenbar eher in jene Situationen geholt werde, in denen es brenzlig ist, denn es braucht viel guten Willen, auch die letzten drei Fragen mit einem Ja zu beantworten. Irgendwie beschleicht mich der Eindruck, als müsse ich mit jedem Projektteam aufs Neue die Vorgehensweise erfinden. Gespräche mit Anderen in der Tester-Community zeigen mir, dass ich mit diesem Eindruck bei weitem nicht der Einzige bin.

Natürlich macht jeder von uns seine eigenen Erfahrungen und optimiert seine Fähigkeiten, lernt etwas dazu. Aber die Gruppe als solches erscheint da resistent. Immer wieder wird der Test in der Praxis ignoriert, trotz beherzter Lippenbekenntnisse. Immer wieder stürzen seine Erkenntnisse ganze Projekte überraschend in eine gestresste Endphase. (Sehr lesenswert in diesem Zusammenhang die testfeindliche Umgebung von Robert Licen.) Erfahrung heißt also noch nichts, so lange die Gruppe an IT-Experten eines Unternehmens nicht gewillt ist zu lernen.

Ich bin überzeugt, dass die meisten Menschen, mit denen ich im Laufe der Zeit zusammen gearbeitet habe, ihre Sache gut machen wollen und an einem Erfolg des gemeinsamen Produkts interessiert sind. Dafür sind sie gerne bereit, auch einmal unschöne Erlebnisse (nervöser Streit mit Kollegen, Überstunden, Stressmomente, etc.) in Kauf zu nehmen. Wenn ich mit wichtigen Ansätzen für einen erfolgreichen Test an ein Projektteam heran trete, habe ich seltener das Problem des Widerspruchs. Eher habe ich das Problem, dass mich beispielsweise Entwickler thematisch auf der rechten Spur überholen und noch viel Ehrgeizigeres anstreben. Aber genau diese Leute vernachlässigen dann in ihrer täglichen Arbeit die ersten Schritte zur Verbesserung, um sich anschließend mit Verweis auf die Umstände dafür zu entschuldigen. „Es geht halt in der Praxis nicht so, wie wir uns das vorstellen.“ Das ist für alle Beteiligten beschämend und letztendlich auch frustrierend.

Was tun? Soll denn jeder Mitarbeiter im Projekt morgens auf sich allein gestellt entscheiden müssen, was jetzt von seinen Aufgaben Priorität hat? Wie er sie jeweils am besten bewältigt? Wenn ja, dann landet die Qualitätssicherung sicher immer ganz hinten – mit Ausnahme bei explizit als solche auserkorenen Testern.

 

Test Center versus Alleingang im Projekt

Vor langer Zeit kam daher die Idee auf, dem Test eine eigene Instanz zu geben: Das Test Center oder ähnlich genannte zentrale Organisationseinheiten, die hierarchisch direkt der Abteilungsleitung berichteten. Eine super Idee: Je größer man diese Stabstellen machte, desto höher wurde die Qualität, je kleiner, desto geringer wurde sie. Perfekt. Man hat so die innerbetriebliche Genehmigungsbehörde geschaffen, die viele der wirklichen Qualitätsprobleme allenfalls am Symptom bekämpft hat. Klar, dass der Streit zwischen Projektleitung und Test Center schnell bis ins obere Management eskalierte. Dort angekommen, war die eigentliche Detailfrage des richtigen Maßes für Qualität sicher komplett falsch aufgehoben. In dieser Zeit habe ich angefangen, mich als Tester unwohl zu fühlen, wenn wir im Test zuweilen sehr gründlich vorgehen und streng urteilen. Etwas, das situationsbedingt durchaus sinnvoll und nützlich ist.

Die Gegenbewegung war für mich bald spürbar. Projektleiter waren gut beraten, ihre Projekte im Alleingang zu organisieren, ohne eine Bürokratie an ihrer Seite, die Innovation eher verhindern würde, anstatt zielstrebig das Projekt nach vorne zu bringen. Damit hat man die partielle Amnesie einer Organisation geradezu perfektioniert. Jedes Projekt startet quasi bei Null und muss versuchen aus den individuellen Fähigkeiten seines Teams ein sinngebendes Ganzes zu formen. Dabei spielt es übrigens keine Rolle, ob diese Projekte agil oder klassisch organisiert sind. Eine agile Vorgehensweise bringt zwar die Optimierung mit, garantiert sie leider auch nicht – genauso wenig, wie klassische Prozessmodelle.

Irgendwie kann es das aber auch nicht sein! Als Berater fühlt man sich da als Sisyphos, der nach jedem Projekt zusehen muss, wie der Stein wieder talwärts rollt. Wo bleibt das kollektive Gedächtnis in der Organisation? Wie kann ich die Erinnerung wach halten? Erfahrung heißt noch gar nichts, ich muss auch als Gruppe aus ihr gelernt haben. Wir brauchen also einen Kompromiss aus einer kompetenten Gruppe an Testern und einem autarken Projektteam. Im agilen Umfeld muss ich dieses Wissen sogar breit im Team verankern – und brauche immer noch hier und da Spezialisten (z.B. für Sicherheitstests).

Software-Testautomatisierung_gescheitert

Als Berater im Test fühlt man sich wie Sisyphos, wenn jedes Projekt wieder von vorne anfängt, Erfahrung zu machen.

 

Auf den richtigen Mix kommt es an

Derzeit formt sich in vielen Unternehmen eine Art Dachorganisation für Test heraus, die das Testvorgehen projektübergreifend koordiniert und fördert, andererseits aber die Projekte nicht unnötig bevormundet. Einige nennen das Test Service Center, nicht einfach nur Test Center, oder auch Test Competence Center. Das Problem ist hier der richtige Mix aus Weisungsbefugnis und reinem Experten-Treff. Hier ist noch viel zu tun. Der einflusslose Experten-Treff ist weder neu, noch wirklich hilfreich. Die Weisungsbefugnis mit Blick auf die Tradition der Testcenter als unternehmenseigene Behörde auch nicht. Dennoch gibt es eine Reihe von Aufgaben, die sich gemeinsam koordiniert bzw. projektübergreifend besser lösen lassen: Wer kennt sich gut mit Sicherheitstests aus? Welche Testumgebungen kann ich verwenden? Gibt es gemeinsam nutzbare Testdaten? Wer übernimmt die Systemintegrationstests? Welche Best Practice im Fehlermanagement nutzen wir? Gibt es schon Werkzeug-Lizenzen, die wir im Projekt nutzen können? Auch in agil arbeitenden Projekten entwickeln sich derzeit übergeordnet koordinierende Teams (wie z. B. beim Nexus Framework). Der Kniff liegt also im richtigen Mix der Maßnahmen und Zuständigkeiten.

Aber nicht nur. Die eigentliche Kunst ist, die Menschen im Projekt mit dem jeweils nötigen Wissen zu versorgen und dann begleitend im Alltag das Wissen immer wieder zu festigen, sodass die kollektive Erfahrung sich irgendwann wie selbstverständlich in die Handlungen jedes Einzelnen einprägt. Das richtige Wissen kann man gut aus den Teststandards ableiten, muss es aber unbedingt über die Erfahrung im Unternehmen an die Bedürfnisse anpassen. Wie man beispielsweise am Besten den Testaufwand schätzt, sollte nicht mit Allgemeinplätzen, sondern mit konkret belegten Erfahrungen aus dem Unternehmen unterlegt sein. (Siehe dazu auch den Beitrag von Andrea Kling zum Schätzen des Testmanagementaufwands.) Auch die Techniken eines Change-Managements sind nicht neu, sie müssen nur überzeugend angewendet werden. Und – ja leider – man braucht einen ganz, ganz langen Atem. Wie zu Beginn zitiert von Tucholsky: „Erfahrung heißt noch gar nichts.“ Denn nur was ein Mensch aus freien Stücken angenommen hat, das behält er auch.

 

Eventtipp:

22. ANECON Expertenfrühstück: Qualität hautnah – Erfolgsmodelle flexibler Test Service Center
11.11.2015 | Albert Hall | Wien >> Jetzt anmelden!

 

 

Passende Artikel

Ein Kommentar

  1. Tobias Braunbeck sagt:

    Sehr geehrter Herr Klonk,

    ein sehr interessanter Artikel;
    ähnliche Erfahrungen habe ich als Test Spezialist sehr oft gemacht.
    Über weitere Beiträge von Ihnen freue ich mich!

    Mit freundlichen Grüßen
    Tobias Braunbeck