FAQ zu Unternehmens-Testing: Antworten auf Fragen, die Sie sich nicht zu stellen trauten
Man könnte sein ganzes Leben lang Schach mit dem Tischnachbarn gespielt haben, dessen Stil, Schwächen und Lieblingseröffnungen in- und auswendig kennen. Doch plötzlich sitzt man einem Großmeister gegenüber, der gleichzeitig an zehn Brettern spielt und dessen Figuren sich alle nach völlig eigenen Regeln bewegen.
Lassen Sie uns die wichtigsten Fragen durchgehen, die Tester zu Beginn ihrer Arbeit in einem großen Unternehmen haben – und die sie sich irgendwie nicht laut zu stellen trauen.
Wie ist Testing in einem Unternehmen überhaupt organisiert? Ist das nicht derselbe Prozess?
Man denkt, der Prozess sei einfach: Aufgabe nehmen – prüfen – abgeben. Im Startup funktioniert das auch so. Im Unternehmen nicht.
Stellen Sie sich vor, Sie bauen ein Einfamilienhaus. Sie entscheiden selbst, wo die Fenster sind, wie hoch die Decken sind und wann das Fundament gegossen wird. Stellen Sie sich nun vor, Sie bauen einen Wohnkomplex mit 10.000 Wohnungen. Es tauchen Planer, Kostenschätzer, Qualitätskontrolle, technische Aufsicht und Abstimmungen mit der Stadt auf.
Im Startup testen Sie eine Funktion, die morgen released wird. Im Unternehmen prüfen Sie ein Modul, das 50 angrenzende Systeme beeinflusst. Sie haben im Admin-Bereich auf „Speichern“ geklickt – und irgendwo ist in diesem Moment die Gehaltsabrechnung der Buchhaltung kaputtgegangen. Weil sich herausstellte, dass Ihre Codezeile das Datenformat für SAP geändert hatte.
Unternehmens-Testing ist nicht einfach nur Fehlersuche. Es geht um die Stabilität eines Systems, das 24/7 läuft und Millionen von Anfragen verarbeitet. Hier kann man nicht einfach sagen: „Ich habe alles geprüft, wir releasen“ – man muss nachweisen, dass die Änderung nichts kaputtmacht, was seit Jahren funktioniert.
Ist Automatisierung im Unternehmen ein Muss? Ich möchte einfach nur manueller Tester sein
Das ist möglich. Aber nicht lange.
Im Unternehmen bedeutet manuelles Testing nicht „auf Knöpfchen drücken“. Es geht um exploratives Testing komplexer Szenarien, die von Autotests nicht abgedeckt werden. Aber den Regress (die erneute Überprüfung alter Funktionen nach jeder Änderung) erledigt für Sie ein Roboter. Sonst gehen Sie einfach unter.
💡 Rat: Lernen Sie Automatisierung nicht nur „der Ordnung halber“. Verstehen Sie, wie Ihre CI/CD aufgebaut ist. Selbst wenn Sie keinen Code schreiben, bewahrt Sie das Verständnis der Pipeline vor Situationen, in denen Sie sagen „ich habe geprüft“, die Tests aber gar nicht liefen, weil ein Job kaputt war. Lesen Sie die Ausführungslogs – das erweitert Ihren Horizont mehr als jeder Kurs.
Der typische Weg sieht so aus: Zuerst automatisieren Sie den Regress. Dann das API-Testing. Dann die Vorbereitung von Testdaten. Und nach einem Jahr stellen Sie fest, dass Sie den Großteil der manuellen Arbeit bereits automatisiert haben, und Ihre Aufgabe jetzt darin besteht, Szenarien zu entwerfen, die nicht automatisiert werden können, und bestehende Tests zu verbessern.
Wie kommuniziere ich mit Entwicklern in einem großen Team, wenn sie nicht hören?
In einem kleinen Team können Sie zu einem Kollegen gehen und mit dem Finger auf den Monitor zeigen. Im Unternehmen nicht. Hier ist Kommunikation eine eigene Disziplin.
Typische Situation: Sie haben einen Bug gefunden, ein Ticket erstellt, der Entwickler hat es mit dem Kommentar „lässt sich nicht reproduzieren“ geschlossen. Und dann geht es los: Sie öffnen es wieder, er schließt es wieder, das Ticket beginnt ein Eigenleben.
Eine der größten Fallen im Unternehmens-Testing ist die Gewohnheit, Tickets im Stil „Button funktioniert nicht, bitte korrigieren“ zu schreiben. Ein Entwickler öffnet so ein Ticket und weiß nicht, was er tun soll. Er sieht eine vage Beschreibung ohne Reproduktionsschritte. Am Ende lebt das Ticket jahrelang, wächst mit Kommentaren wie „Bug weiterhin aktuell“ und wird dann einfach wegen „Nichtreproduzierbarkeit“ geschlossen.
Die Regel ist einfach: Jedes Ticket ist eine Geschichte mit Anfang, Mitte und Ende. Reproduktionsschritte. Erwartetes Ergebnis. Tatsächliches Ergebnis. Umgebung. Logs. Screenshots. Wenn der Bug in drei von zehn Fällen auftritt – beschreiben Sie die Bedingungen genau für diese drei.
💡 Rat: Bevor Sie ein Ticket für einen Entwickler erstellen, fragen Sie sich: „Kann ich diesen Bug einem anderen Tester so zeigen, dass er ihn beim ersten Mal reproduziert?“ Wenn nicht – gehen Sie und beschreiben Sie es genauer.
Wie vermeide ich Burnout, wenn ich das Gefühl habe, nichts zu schaffen?
Die Arbeit in einem Unternehmen ist ein endloser Strom: Aufgaben, Bugs, Regressionen, Releases, Meetings. Wenn Sie keine Grenzen setzen, tritt Burnout innerhalb eines Jahres ein.
Am gefährlichsten ist die Einstellung „Ich muss alles prüfen“. Das ist unmöglich. Es wird immer etwas geben, das Sie nicht geprüft haben. Dies zu akzeptieren ist der erste Schritt zur professionellen Reife.
Arbeiten Sie mit Risiken. Versuchen Sie nicht, 100 % der Funktionalität durch Tests abzudecken – das ist nicht nötig. Definieren Sie, was für das Geschäft kritisch ist. Wenn das Hauptkauf-Szenario ausfällt – das ist ein Release-Stopper. Wenn ein Bug im Button „Mehr anzeigen“ auf einer Seite steckt, die niemand nutzt – kann man releasen und im nächsten Sprint korrigieren.
💡 Rat: Führen Sie eine Regel ein: Sie beenden die Arbeit pünktlich. Nicht um 23:00 Uhr, sondern um 18:00 oder 19:00 Uhr, wie üblich. Wenn Sie merken, dass Sie es nicht schaffen – sagen Sie es sofort dem Teamleiter oder PM. Stillschweigende Überstunden werden nicht geschätzt. Geschätzt wird die Fähigkeit, Zeit einzuschätzen und die Wahrheit vor dem Deadline, nicht danach zu sagen.
Wie entwickle ich mich vom einfachen Tester zum Testarchitekten?
Das ist kein Sprung, sondern eine Reihe von Schritten. Jeder Schritt fügt eine neue Kompetenz hinzu, ersetzt keine alte.
Die erste Stufe – manuelles Testing. Sie prüfen Funktionen, suchen Bugs, lernen gute Tickets zu schreiben. Sie machen sich mit Tools vertraut: Postman, DevTools, Datenbanken.
Die zweite Stufe – Automatisierung. Sie schreiben Skripte in Python oder Java. Entwickeln Testszenarien. Verstehen, wie CI/CD, Docker und Integrationstests funktionieren.
Der Übergang vom manuellen zum automatisierten Testing ist wie der Umstieg vom Fahrrad aufs Auto. Sie können immer noch Fahrrad fahren und das ist manchmal praktisch. Aber für lange Strecken brauchen Sie ein Auto. Ein Unternehmen ist eine lange Strecke.
Die dritte Stufe – Testarchitektur. Sie schreiben nicht jeden Test. Sie entwerfen ein Framework: Welche Tests sind nötig, auf welcher Ebene werden sie ausgeführt, welche Daten werden eingespeist, wie wird die Ausführungszeit minimiert. Sie denken über Skalierung nach.
💡 Rat: Wenn Sie Architekt werden wollen, beginnen Sie damit, ein Framework zu schreiben, das andere Tester in Ihrem Team verwenden. Zunächst holprig, nicht ideal. Dann verbessern Sie es auf Basis von Feedback. Das gibt Ihnen ein Verständnis dafür, wie man ein System aufbaut, nicht nur Tests schreibt.
Die vierte Stufe – Management von Testprozessen. Es geht um Metriken: Wie viel Zeit wird für den Regress benötigt, wie viele Bugs gelangen in die Produktion, wie kann die Release-Zeit verkürzt werden. Sie implementieren Prozesse, nehmen nicht nur daran teil.
Wie verliere ich mich nicht in der komplexen Infrastruktur eines Unternehmens?
Legacy-Code, Hunderte von Microservices, fünfzehn Umgebungen, unverständliche Build-Artefakte – das ist im Unternehmen normal. Wenn Sie etwas sehen, das wie Chaos aussieht, ist es kein Chaos, sondern über Jahre angesammelte Komplexität.
Versuchen Sie nicht, alles auf einmal zu lernen. Lernen Sie das, womit Sie heute arbeiten. Sie haben ein Ticket erstellt – verstehen Sie, wie dieses Stück System aufgebaut ist. Sie haben einen Test geschrieben – verstehen Sie, wie die Umgebung funktioniert. Im Laufe eines Jahres bauen Sie sich eine Karte des Systems im Kopf auf.
💡 Rat: Dokumentieren Sie. Wenn Sie ein unverständliches Stück Architektur verstanden haben – notieren Sie sich schematisch, was mit was verbunden ist. In einem Monat wird dieses Wissen nützlich sein, und Sie haben es vergessen. Das Führen einer persönlichen Wissensdatenbank (in Confluence oder einfach in Obsidian) ist eine Superkraft im Unternehmen.
Kann man überhaupt eine Karriere im Unternehmens-Testing aufbauen, oder ist das eine Sackgasse?
Ja, das kann man. Und es ist sogar nötig – wenn Ihnen Komplexität und Maßstab gefallen.
Ein Unternehmen bietet, was Startups nicht haben: Stabilität, Struktur, Zugang zu komplexen Technologien, die Möglichkeit, ein Produkt zu beeinflussen, das von Millionen genutzt wird. Der Karriereweg endet nicht bei der Position „Senior Tester“. Es gibt Richtungen in Automatisierung, DevOps, Management oder Architektur.
Was mache ich, wenn ich das Gefühl habe, festzustecken?
Die häufigste Falle ist, sich an die Stabilität zu gewöhnen und aufzuhören, sich weiterzuentwickeln. Die Arbeit ist da, das Gehalt kommt, die Aufgaben sind klar. Nach zwei Jahren wachen Sie mit dem Gedanken auf: „Ich kann nichts Neues, und der Markt ist schon weiter.“
💡 Rat: Stellen Sie sich vierteljährlich die Frage: „Was habe ich in den letzten drei Monaten gelernt?“. Wenn die Antwort „nichts“ lautet – ändern Sie etwas. Gehen Sie zu einem internen Kurs, übernehmen Sie eine Aufgabe aus einem anderen Team, bitten Sie um einen Mentor in einem verwandten Bereich. Oder wechseln Sie den Job. Stagnation im Unternehmen ist keine Besonderheit des Unternehmens, sondern eine Gewohnheit, an der man arbeiten kann.
Die Schlüsselkompetenz eines Unternehmens-Testers ist nicht die Fähigkeit, Bugs zu finden. Es ist die Fähigkeit, Prozesse so zu gestalten, dass es weniger Bugs gibt. Nicht heldenhaft manuell einzugreifen, sondern in ein System zu investieren, das auch ohne Sie funktioniert.
