Kürzlich kamen mir meine Jahre im Qualitätsmanagement in den Sinn. Wie geht das eigentlich bei Softwarefirmen? Ein Bericht aus den Nuller-Jahren und die Wahrheit hinter dem Begriff ‚bug‘!
In den jungen Jahren als Student war auch ich gezwungen, mir etwas dazu zu verdienen. Ich fand einen recht gut bezahlten Job bei einer IT-Firma, die ich zwar gut fand, aber sie dennoch nicht nennen will. Ja, es waren die wilden Nuller-Jahre, als ich für 10 Euro die Stunde Softwareprogramme nach Fehlern durchsuchte. Ich war im Testteam. Der Dorn im Auge des Tech-Teams, das sich mit den Testberichten herumschlagen muss.
Man saß in einem Raum mit vielen anderen Studierenden. Jeder hatte einen Computer vor sich. Bevor man beginnt, setzt man den Computer zurück. Dies gelang damals mit einem Image. Heute ist das bei den meisten Systemen integriert. Der Chef der Abteilung hat die Computer zusammengestellt, sodass sie gut funktionieren und ein Abbild davon gemacht. Das Abbild, genannt Image, konnte man jederzeit hochladen, dann war der Computer wie frisch eingestellt. Man nutzt also ein cleanes System, um etwaige Störfehler auszuschließen.
Dann installiert man das zu testende Programm. Selbstverständlich können dabei schon Fehler entstehen. Das kontrolliert aber meist das Bootup-Team. Es kommt jedoch vor und dann macht man einen Screenshot – notfalls mit dem Handy. Dann musst Du einen meist vorgefertigten Testbericht dazu ausfüllen und das Problem beschreiben.
Inzwischen geht man zu Systemen über, die den Fehler selbst erkennen und eine entsprechende Meldung anzeigen. In vielleicht durch die KI nicht allzu ferner Zukunft, wird sich die Software womöglich selbst schon bugfixen – also reparieren. Diese bereits in Arbeit befindliche Software nennt man selbstheilend. Auch beim Qualitätsmanagement setzt man natürlich zwischenzeitlich auf KI. Man muss dieser Technologie nur Ohren und Augen geben und ihr beibringen, worauf sie zu achten hat. Dann kann es auch schon losgehen. Diese Entwicklung steht meines Erachtens auch schon in den Startlöchern.
Das Ausfüllen des Fehlerberichts erfordert dann die ganze Kunst eines Softwaretestenden. Denn aus dem Bericht will der Programmierer oder die Programmiererin einen Rückschluss auf den eigentlichen Fehler ziehen. Es gibt selbstverständlich eine Vielzahl von möglichen Fehlerquellen. Daher sendet man auch einen Systembericht mit, der Hinweise auf den Fehler geben kann. Es kann also die Konfiguration sein, die Verbindung zum Betriebssystem (OS) oder ein Fehler innerhalb der Software selbst.
Die exakte Vorgehensweise zu beschreiben ist dann von enormer Wichtigkeit. Dabei ist es auch wichtig, in welcher Reihenfolge man vorgegangen ist. Wenn man sich wild durch die Knöpfe drückt, ist das schwer nachzuvollziehen. Es bietet sich also an, strukturiert vorzugehen. Die Kund*innen des Produkts sind aber nicht so nachsichtig und klicken sich eben durch die Software. Daher stehen meines Erachtens beide Konzeptionen im Clinch miteinander.
Eine gute Übersicht über die Ziele und Vorgehensweise des Qualitätsmanagements bin ich selbstredend auch gestolpert. Schließlich gibt es Leute, die das nicht nur gemacht, sondern auch studiert haben. Übrigens sollte man als Softwaretester*in folgende Geschichte kennen:
Der Begriff Bug, das englische Wort für Wanze (auch wenn überall Käfer steht), ist der Begriff für einen Fehler in der Software. Der geschichtliche Hintergrund ist, dass die ersten Computer über mechanische Schaltungen funktionierten. Wenn aber nun ein Bug, eine Wanze, zufällig unter die beweglichen Teile krabbelte, als die Leitung schaltete, dann war die Übertragung gestört. Denn die Klappen schlossen sich nicht richtig, wenn das zermatschte Insekt es verhinderte. Dann riefen die Ingenieure „Bug“ und alle wussten, es geht jetzt los zum Reinigen der Kontakte.
