Konstruktive Destruktion

Seit nunmehr einem Vierteljahr habe ich einen neuen Job und arbeite in einem IT-Unternehmen in der Softwaretestung und -entwicklung. Auch wenn ich durch meinen letzten Job in Köln der Informationstechnologie etwas näher gerückt war, so ist dies immer noch ein mir fremdartiger Bereich, in dem ich mich dort bewege. Dennoch macht es Spaß, da es nicht nur neue Herausforderungen bietet, an denen man wachsen kann, sondern dies in einem Bereich stattfindet, der für einen selbst bis dato ein Buch mit sieben Siegeln war. Somit erschließen sich mir ganz neue Sichtweisen und Aspekte – quasi Welten. Ich könnte bei Weitem nicht nur einen Beitrag über Gedanken diesbezüglich schreiben; über die Tatsache beispielsweise, dass ich als Geisteswissenschaftler mein imaginäres Bild eines Informatikers komplett redefinieren musste oder erfahren durfte, dass selbst ein Programmierer nicht nur kreativ im Sinne von Kreation, sondern eben auch in künstlerisch konnotiertem Sinne ist oder wie spannend es sein kann Sprachen zu lernen, in denen man nicht sprechen kann und die lediglich ein Konstrukt sind, um mit Maschinen zu kommunizieren, klar definiert und lediglich den strengen Gesetzen der formalen Logik unterworfen, die ich nebenbei gesagt sehr mag, weil dort alles sowohl Anfang und Ende findet, wenn man es bis zur letzten Konsequenz denkt. Dennoch möchte ich mich erst einmal darauf beschränken, was jetzt meine täglichen Aufgaben sind.

Die Abteilung also, in der ich tätig bin, führt Software- und Systemtests durch und für alle die, die damit nun, wie ich noch vor kurzem, nichts anfangen können, versuche ich es in ganz einfache Worte zu fassen. Es geht schlicht darum ein Programm, eine Website oder eine Applikation (was auch immer) auf „Herz und Nieren“ zu überprüfen, damit es nach Auslieferung keine unerwünschten Fehler oder Funktionalitätsschwächen hat. Dies bezieht sich einerseits auf rein funktionale Aspekte, also ob ein Programm seine Aufgabe erfüllt, als auch über Fragen der Bedienbarkeit, Tippfehlern auf der Oberfläche oder was auch immer. Idealerweise sollte also das Programm für alle erdenklichen Situationen gewappnet sein, sofern es unter diesen Bedingungen laufen soll. Es wäre also ein guter Test zu schauen, ob ein Textprogramm für Buchautoren eine Million Zeichen verarbeiten kann, wäre jedoch per definitionem kein Test, dass es auch noch läuft, wenn ich ein Glass Wasser über den Computer kippe. Also alle eventuellen Situationen sollten in Betracht gezogen werden, die als zu erwartende Situationen auftreten könnten – inwiefern es realiter überhaupt möglich ist, wirklich alle Situationen durchzutesten sei dahingestellt.

Meine Aufgabe in diesem Prozess ist es nun durch kleine, selbstgeschriebene Programme oder aber manuell Anwendungen zu testen, wobei eine besondere Unterart der möglichen Tests mir besonders zusagt, nämlich eben jene, bei denen etwas auf Belastung und Extrema getestet wird. Auch wenn es sehr viel Vergnügen bereitet, zum Grund dafür später mehr, so kann dies doch recht anstrengend sein, da man sich ja ständig in Dinge hineinzuversetzen sucht, die direkt an der Grenze des nicht mehr Beabsichtigten liegen. Um ein konkretes Beispiel hier aus Gayromeo zu geben: Man ist mit dem Aufbau der Seite beschäftigt, hat jedoch bisher noch keine Erfahrung mit Userverhalten und programmiert nun eine Funktion, mit der man Messages verfassen kann. Aufgabe des Testers ist es nun zu schauen, ob diese Funktion richtig programmiert ist. Dies ist im ersten Schritt recht einfach, denn man muss nur eine Message verfassen, sie abschicken und wenn sie ankommt, dann klappt es. Hier können dann „bugs“ auftreten, zum Beispiel wenn eine Message nicht ankäme, sobald sie eine Zahl enthält. Die interessantere Frage jedoch ist nun, wann sie funktioniert und wann nicht und, was passiert, wenn letzteres der Fall ist. So, um beim Beispiel zu bleiben, ist die Anzahl der Zeichen auf 5.000 begrenzt und früher (ja, ich bin schon so lange auf dieser Seite, dass der Begriff „früher“ adäquat ist) war es so, dass dann zwar eine Fehlermeldung kam (was ein weiteres zu überprüfendes Kriterium wäre), jedoch der geschriebene Text verloren war, was dann im Falle eines Test zu einem „feature request“ führen würde, da man es eben aus Sicht des Users für sinnvoll hält, dass der Text, auch wenn er nicht verschickt werden kann, so doch zumindest nicht verloren gehen sollte. Soweit klingt dies ja nicht wirklich an der Grenze, jedoch muss man bedenken, dass man ja meist im Teststadium (wenn es um neue Anwendungen geht, mit denen man nicht schon anderweitig Erfahrungen hat sammeln können) nicht weiß, welche Fälle auftauchen können und man vielleicht gar nicht auf die Idee kommt, dass es einen User geben könnte, der mehr als 5.000 Zeichen versenden will.

Es ist also Kreativität gefragt und man sitzt da und sucht nach Ideen, welche abstrusen Dinge denn so vorkommen könnten. Nicht selten kommt es dann vor, dass man über eigene oder auch die Ideen anderer insgeheim denkt: „Interessant und wichtig das zu testen, aber wie kommt man auf so einen Scheiß?“ Doch kommen wir nun zum eigentlichen Spaßfaktor des Ganzen. Es geht für den Tester ja nicht darum, dass etwas funktioniert, denn das ist Intention des Entwicklers. Für ihn ist es ein Erfolg, wenn er etwas „kaputt macht“, also nachweisen kann, dass ein noch zu verbessernder Fehler vorliegt. Wie wir ja alle dank „Murphy’s Law“ wissen, so es immer einen sechsten/siebten Fehler geben, wenn man die bekannten fünf/sechs beseitigt hat und selbst ich als gnadenloser Idealist bin Realist genug einzugestehen, dass der status quo nie das Ideal wird erreichen können. Somit ist es Pflicht des Testers, damit seine Tätigkeit Sinn macht, etwas zu zerstören, ein Programm zu „zerschießen“ oder im Extremfall ein ganzes System zum Absturz zu bringen, denn besser es passiert ihm und somit noch im Entstehungsprozess als später dem Kunden. Und „kaputt machen“ macht Spaß, Spaß, Spaß…

Klein Benny – selbiger, der einst in einem anderen Beitrag sein Zimmer aufzuräumen hatte – sitzt nun in der Spielecke mit Freunden, die alle ganz hohe Türmchen bauen. Klein Benny selbst kann keine Türmchen bauen, da ihm die nötigen Klötzen fehlen, allerdings sitzt er nicht nur daneben und schaut zu, sondern er ist von allen gefragt. Es ist nämlich ein Türmchenbauwettkampf, den jeder gewinnen möchte. Da aber natürlich jedes Kind davon überzeugt ist, dass sein Türmchen nicht nur das höchste ist, sondern auch nicht von den anderen kaputt gemacht werden kann, denn die eigenen Türmchen sind immer unkaputtbar, wären sie viel zu zögerlich und wohl auch zu stolz, die eigenen Türmchen solchen Strapazen auszusetzen, dass diese in sich zusammenfallen. Darum gehen sie zu klein Benny und behaupten: „Mein Türmchen bekommst du nicht kaputt!“

Klein Benny jedoch nimmt sich nun einen Ball und wirft ihn auf das Türmchen, welches natürlich prompt dem Erdenboden gleich gemacht wird, woraufhin klein Benny sich kaputt lacht und sich amüsiert wieder zurückzieht. Nachdem das Türmchen dann wieder steht und diesmal abgesichert scheint, passiert das gleiche erneut. Dieses Mal jedoch muss klein Benny sich wesentlich mehr anstrengen, das Türmchen zu zerstören. Doch je größer der Aufwand, desto größer ist auch die daraus resultierende (Schaden-)Freude und gerade dann, wenn Ball, Playmobilwand und Hammer nicht mehr greifen und klein Benny mühsam einen Stuhl auf eine Leiter hinauf schleppen muss, um ihn von dort auf das Türmchen fallen zu lassen, kennt die anschließende Freude fast keine Grenzen mehr.

Dieser kleine Benny meldet sich sozusagen täglich bei mir und man hat nicht nur Freude daran zu schauen, wie weit man gehen kann und muss oder sich zu überlegen, wie man den anderen überlisten kann, sondern man weiß auch abends, was man getan hat, da man ja dazu beigetragen hat, dass durch die Zerstörung ein Fehler entdeckt wurde, der nun, da er bekannt ist, behoben werden kann und man somit dem unerreichbaren Ideal doch ein Stück zu Leibe gerückt ist.

In einem Aspekt hinkt dieser Vergleich jedoch noch, da klein Benny männlich ist. Groß Benny, eben selbiger, der gerade diesen Text tippt, jedoch verfügt, warum auch immer, über „weibliche Intuition“ – hierbei sei angemerkt, dass mir generell weibliche Denkstrukturen angerechnet werden können insofern man dem Test in dem Buch „Warum Manner nicht zuhören und Frauen schlecht einparken“ Glauben schenken kann. Nehmen wir mal an, es gibt zehn verschiedene Objekte auf einer Seite, in die man einen Text eintragen kann. Bei neun von ihnen treten keine Fehler auf, bei einem jedoch liegt ein kleiner Fehler vor, insofern man kein Ausrufezeichen benutzen kann in diesem Feld, obwohl dies in allen anderen Feldern möglich ist und auch in diesem sein sollte. Zu meiner eigenen und der Verblüffung meiner Kollegen würde ich in einem solchen Fall, wieso auch immer gerade in diesem Feld ein Ausrufezeichen eintragen. Keine Ahnung, wie ich darauf komme und im Grunde setze ich dieses ja auch nicht bewusst sondern „einfach mal so“ – übrigens die häufigste Antwort auf die Frage, warum ich denn ausgerechnet diesen Fall gewählt habe . Langsam beginne ich selber an meinem Geschick zu zweifeln, denn es sind wie gesagt in solchen Fällen meist keine großen Fehler, bei denen der Spaßfaktor ja auch nicht so groß wäre, sondern wirklich kleine, versteckte Fehler. Im Grunde genommen schaffe ich das gleiche wie als ich einmal mit Freunden noch in Teenagertagen Billard spielte und es doch tatsächlich schaffte die Kugel so dermaßen ungeschickt anzustoßen, dass sie vom Tisch heraussprang, auf den Nachbartisch flog und dort die schwarze (!!!) Kugel versenkte – sehr zum Ärger der Nachbarn, doch zum aller Umstehenden.

Vielleicht stimmt auch einfach der Satz „Nomen est Omen“ und es liegt schlicht daran, dass der hebräische Name „Benjamin“ die Bedeutung „Sohn des Glücks“ trägt. Daher freue ich mich schon wieder auf die Arbeit und hoffe, dass ich weiterhin soviel „Glück im Unglück“ haben werde und mit Donald Duckscher Tollpatschigkeit irgendwann einer der erfolgreichsten Tester werde.