Software-Test / Test Center / Testmanagement

Anleitung zur Bruchlandung mit Ihrem Testcenter

Der Volksmund behauptet, guter Rat sei teuer.
Und schlechter Rat? – der ist doch noch viel teurer!
Denn: wer sich an schlechten Rat hält, muss dafür oft viel „Lehrgeld“ bezahlen.
– und das Hinterhältige daran ist: auch der schlechteste Rat tarnt sich oft als gut gemeinter Tipp.

Damit räume ich jetzt auf. Sie bekommen hier von mir – völlig gratis und ohne Tarnung –  meine persönlichen „Lowlights“ an Ratschlägen, die den Verpackungshinweis „enthält Spuren von Scheiterpotential“ verdienen.

Testcenter_Scheitern

Scheitern leicht gemacht!

  1. Stellen Sie Ihr Testteam aus verfügbaren Ressourcen zusammen
    Sie brauchen (zusätzliche) Tester? Fragen Sie doch einfach mal in anderen Abteilungen oder im Personalbüro nach! Es gibt fast überall Kollegen, die gerade keine Aufgaben haben und daher zur Unterstützung angeboten werden. Schnell wird Ihre Test-Abteilung zu einer „Rest-Abteilung“ und Sie haben in Ihren Mitarbeitern eine hervorragende Ausrede wenn die gelieferte Qualität nicht passt.
  2. Geizen Sie mit Fortbildungsmaßnahmen
    Es reicht doch, wenn die Personen zum Einstellungszeitpunkt mit der aktuellen Technik vertraut waren – was vor 10 Jahren gut war, wird doch jetzt genauso gut sein! Wer will denn schon in die Ausbildung von Mitarbeitern investieren, wenn das Risiko besteht, dass diese danach das Unternehmen verlassen. Da riskieren wir doch lieber, dass die schlecht ausgebildeten Mitarbeiter mit zusehends veraltetem Wissen bleiben!
  3. Überlassen sie den Test sich selbst
    Teamleiter verursachen doch nur Kosten – und die Projekt- und Ressourcen-Koordination obliegt der Durchsetzungskraft der einzelnen Projektleiter. Sollten Sie dennoch einen Test-Teamleiter ernennen, dann am besten nur nach technischen Kenntnissen, denn Soft Skills werden überbewertet – schließlich handelt es sich um einen technischen Beruf. Machen Sie einfach den besten Tester zum Teamleiter. Dann haben Sie gleich zwei Fliegen mit einer Klatsche erschlagen: Sie verlieren einen hervorragenden Tester und gewinnen einen vermutlich maximal mittelmäßigen Teamleiter.
  4. Messen Sie nur die Testkosten aber niemals den Testerfolg
    Qualität ist teuer – und es interessiert doch keinen, was man sich durch die gefundenen Fehler an Kummer und Kosten im Echtbetrieb erspart.  Gerade in finanziell angespannten Zeiten können Sie plakative kurzfristige Ergebnisse erzielen, indem Sie die Testkosten senken. (Bis das auf Sie zurückfällt, sind Sie längst nicht mehr da, wenn Sie die bisherigen Tipps befolgt haben.)
  5. Opfern Sie keine Funktionen oder Termine zugunsten der Qualität
    Schließlich wollen die Anwender zeitgerecht ein vollumfängliches Produkt haben – wen kümmert es, ob sie es dann auch wirklich verwenden können und bereit sind, dafür zu bezahlen? Wenn Sie ganz gründlich sein wollen, werfen Sie jedem Tester, der einen Fehler findet vor, den Liefertermin zu gefährden und feiern Sie den Meilenstein „Feature Complete“ ohne Rücksicht auf offene Fehler.
  6. Testen Sie nicht, um Fehler zu finden
    Damit gefährden Sie nur den Projekterfolg und das Image des Projektes! Welcher Projektleiter hört gerne, dass er seine Software auf einem instabilen Fundament, mit hohem Fehlerrisiko oder gar mit Qualitätsmängeln baut? Wer möchte denn mit der technischen Schuld konfrontiert werden, die er vor sich herschiebt? Um nicht als Überbringer schlechter Nachrichten zu gelten, sollten sie sich auf bekannte „Gutfälle“ konzentrieren und stets auf denselben Pfaden Testen, die sie schon zig Male zuvor erprobt haben und auf denen das Fehlerpotential bekannt gering ist. Sollten im Echtbetrieb andere Anwendungsfälle zu Fehlfunktionen führen, können Sie sich bestimmt auf die unzureichende Requirements-Definition ausreden, die idealerweise ebenfalls nur die Funktionalität und nicht die Fehlerfälle beschreibt.
  7. Automatisieren Sie die Regressionstests nur wenn Zeit dafür bleibt
    Dieses Automatisieren kostet doch nur Zeit – nicht nur im Test, sondern auch in der Entwicklung, die den Code auch noch automatisierbar und nach bestimmten Qualitätsrichtlinien gestalten soll. Während der Entwicklung wollen Sie sich nicht mit dem Gedanken an spätere Regression oder Wartbarkeit befassen – hier geht es um schnellen Fortschritt. Mit ein wenig Glück, scheitert das Projekt auch aufgrund der Instabilität oder der explodierenden Aufwände für manuelle Tests bevor Sie die Zeit zur Automatisierung gefunden haben – dann haben Sie sich wieder etwas erspart.
  8. Betrachten Sie Entwickler, Operatoren, Analysten und Anwender als Feinde
    Das was Analysten und Entwickler Ihnen zum Test vorlegen kann doch nur als Fehdehandschuh interpretiert werden. Verwenden Sie den Hauptanteil Ihrer Kraft und Zeit für Schuldzuweisungen. Operatoren behindern nur unnötig Ihre Arbeit durch Hinweise auf Sicherheitsvorgaben oder Einschränkungen bei der Gestaltung Ihrer Testumgebung – und nennen das dann auch noch „Realität“. Und erst die Anwender! Jeder Fehler, den Anwender im Echtbetrieb finden, ist ein persönlicher Angriff den es sofort abzuschmettern gilt (hier helfen oft dieselben Sätze, die Sie bei den Schuldzuweisungen an die Entwickler gehört haben). Wo kämen wir denn hin, wenn wir die anderen Projektbeteiligten verstehen oder gar versuchen würden, von ihnen zu lernen? Ein Tipp: am besten gelingt dieser Punkt, wenn Sie gänzlich auf direkte Gespräche verzichten und lediglich über Ticketsysteme oder allenfalls miss-interpretierbare E-Mails kommunizieren.
  9. Interpretieren Sie unvollständige Anforderungen
    Direktes Nachfragen kostet nur Zeit – treffen Sie stattdessen lieber Annahmen – und wenn die Software diesen nicht entspricht, schreiben Sie lange E-Mails mit großem Verteiler oder Mengen an Bugreports. Damit generieren Sie nicht nur viel an Missverständnis-Potential sondern auch eine gute Grundlage für eine dauerhaft schlechte Zusammenarbeit (das erleichtert die unter Punkt 8. genannte Feindschaft).
  10. Verschwenden Sie keine Zeit für Dokumentation oder Reporting
    Gute Dokumentation kostet Ihre Zeit, schlechte Dokumentation zusätzlich die der anderen! Wozu also eine gute, nachvollziehbare Fehlerbeschreibung erstellen, wenn es ein Einzeiler auch tut? Der Entwickler wird schon nachfragen, wenn er sich nicht auskennt! Schließlich hat es Mühe gekostet den Fehler zu finden – da soll es auch Mühe kosten, ihn nachzuvollziehen! Sollte der Entwickler den Fehler als „nicht nachvollziehbar“ abweisen, haben Sie einen Grund mehr, ihn gemäß Punkt 8. als unkooperativ zu bezeichnen. Weitere Zeitfresser sind Reports über Testfortschritte oder Fehleranalysen. Sollte jemand derartiges von Ihnen erwarten betrachten Sie es als Misstrauen und den Versuch, sie zu kontrollieren. Mangelnde Transparenz ist viel besser geeignet um mangelndes Vertrauen zu pflegen!

Vermutlich lässt sich diese Liste noch munter fortsetzen, doch eigentlich reichen auch schon zwei oder drei konsequent umgesetzte schlechte Ratschläge um grandios zu scheitern. Da bleibt mir nur die Warnung auszusprechen: Achtung Rutschgefahr! 😉

Fallen Ihnen noch einige weitere derartige Ratschläge ein? Sei es aus eigener Erfahrung, Beobachtung oder gar aus der Erkenntnis, dass Sie ohne das eine oder andere ziemlich schlecht beraten wären? Dann schreiben Sie doch einen Kommentar und teilen diesen mit uns! Ich freue mich auf viele kostenlose schlechte Ratschläge um grandios zu scheitern.

Passende Artikel

2 Kommentare

  1. Susanne Albinger sagt:

    Sehr gut getroffen und unterhaltsam zu lesen 🙂

    Zwei Ratschläge zum Scheitern würden mir auch noch einfallen:
    11. Betrachten Sie Tester als „Ressourcen“, die man möglichst oft in unterschiedlichen Projekten einsetzen sollte. So lassen sich Kosten sparen (weil man ja nicht während der gesamten Entwicklungszeit testen muss) und man läuft nicht Gefahr, dass der Tester auch weiß, was er testet.
    12. Involvieren Sie Ihr Testteam möglichst spät in ein Projekt. Analyse und Entwicklung der Testpläne gemeinsam mit Development und Stakeholdern kosten nur unnötig Zeit und treiben die Projektkosten in die Höhe, weil man eventuell schon von Anfang an die benötigten Testaufwände mit berücksichtigen würde.

    • Ursula Mayer-Schwalb Ursula Mayer-Schwalb sagt:

      Vielen Dank für die Erweiterung!
      Vor allem der Punkt mit der späten Mitarbeit im Projekt hat viel Potential! 😉