Gameproject Blog

GameProject

Teras Testertext

Dieser Text erschien hier im Blogs bereits, allerdings, nicht eben lesefreundlich, in drei Teilen.

Aufgrund der großen Nachfrage entschlossen wir uns dann letztens zur Wiederveröffentlichung – allerdings machte uns da prompt der ominöse Fehler 404 zu schaffen, dem ausgerechnet der erstmals am Stück veröffentlichte Testertext zum Opfer fiel.

Nicht nur aufgrund der immer noch erstaunlich großen Nachfrage, sondern auch, weil wir Teradachs Testerelend-Beschreibung sehr lieben (auch im Hinblick auf die bald startende Beta) haben wir uns nun entschlossen, dem Text dauerhaft einen eigenen Platz einzuräumen. Et voila:

Der geregelte Projektablauf oder “Warum man als Softwaretester zum Trinker wird” von Teradach

Am Anfang war das Wort. Und auf das Wort folgten viele weitere Worte. Und die Worte flogen mehr oder minder sinnbeladen hin und her und die Protagonisten dieses regen philosophischen Austausches nannten sich Kunde und Projektmanager. Und das Wort ward niedergeschrieben und in eine Form gebracht und diese Form da nannte sich Spezifikation, auf daß Kunde und Projektmanager und alle, die da noch beteiligt sein würden, das Projekt erkennen und es war ein grosses Jauchzen und Frohlocken!

Dann gelangt das Pamphlet, die groteske Absichtserklärung, die Ansammlung unfertiger Halbdefinitionen (und aufgemerkt, wir sprechen immer noch von derselben Schrift!) zum jähzornigen, alles-wissenden und merkwürdige Floskeln wie zeus’sche Blitze um sich schiessenden Entwickler sowie zum sich seiner Belanglosigkeit bewussten, zitternden Mitarbeiter der Qualitätssicherung. Was ist auf dem Weg von der Entstehung zur Umsetzung geschehen?

Ab jetzt läuft das typische Projekt ungefähr so:

Tag 1

9:30 Uhr: Der Projektmanager verschickt die Spezifikation per Mail an den Entwickler und den Tester. Diese machen sich sofort mit Feuereifer daran, das Traktak umzusetzen, so wie der Kunde es wünscht.

09:37 Uhr: Der Kunde rufe den Projektmanager an. Er übermittelt ihm seine sonnigsten Grüsse und beide gratulieren sich zu ihrer verdammt guten Arbeit. Bei der Gelegenheit äussert der Kunde den Wunsch, doch statt der Radio-Buttons auf dem dritten Tab der Hauptmaske zum Anlegen der Personen ein paar Check-Boxen anzulegen, und ausserdem sollte dieser Tab doch besser statt “Merkmale” ganz allgemein “Allgemeines” heissen.

15:45 Uhr: Der Projektmanager hat die letzten fünf Stunden damit verbracht sich mit seinem Broker auszutauschen, den Hausbau zu organisieren, seine Tochter zu trösten dass die Ferien auf dem Ponyhof statt sechs doch nur vier Wochen dauern werden und bei der Gelegenheit noch schnell die Spezifikation angepasst.

Tag 2

10:15 Uhr: Der Projektmanager verschickt die Spezifikation an den Entwickler. Dieser hatte Tab3 bereits seit 9:45 fertig und flucht leise in sich hinein, während er ein motiviertes “Klar, kein Problem, ich war eh noch nicht fertig” in den Hörer heuchelt.

12:30 Uhr: Der Kunde schreibt eine Mail an den Projektmanager und übermittelt einen Änderungswunsch für Tab “Allgemeines”, der bitte in “Optionen” umbenannt werden sollte. Des weiteren möge dieser Tab um die Kernfunktionen aus Tab 2 “Optionen” erweitert werden, Tab 2 – ab jetzt “Kompetenzen” genannt – wird entsprechend umgerüstet und dafür wäre es hübsch, wenn ein Photo des Bewerbers hochgeladen werden könnte. Der Projekt-Endtermin müsse leider um zwei Wochen vorverlegt werden, da dies der Geschäftsleitung bereits so mitgeteilt worden sei.

Tag 3-6

Der Projektmanager hatte viele viele viele Meetings, in denen Verantwortlichkeiten definiert, Aufgaben delegiert, fingerpointing blasphemiert und Aufgabenfelder spezifiziert werden, darüber hinaus werden die wirklichen Themen des Unternehmens, Europas und der Welt besprochen und gelöst, seien es cash-flow, work-rate, human capital, human ressources, mindset im Generellen und Speziellen sowie die capability, das Richtige vom Wichtigen und das alles just-in-time zu tun. Diese Meetings – und besonders die nachfolgenden Nachbereitungen im kleinen Kollegenkreis in der Kaffeeküche oder im Büro – fordern beinahe so viel Kraft wie das Anpassen der Spezifikation um Tab2, was an Tag6 gegen 16:25 in 5 Minuten erledigt wird.

Tag7

12:30 Uhr: Der Projektmanager ruft den Kunden an, um noch den einen oder anderen Punkt zu klären und stimmt im Übrigen in allen Punkten zu. Gleichzeitig bedauert er die Verzögerung, welche sich durch ein ungenaues Lesen der Spezifikation durch den Entwickler ergeben hat und erklärt sich bereit, dem Kunden zum Ausgleich 12 Manntage Entwicklungsaufwand zu erlassen.

16:00 Uhr: Der Projektmanager ruft – bereits im Mantel und die Laptop-Tasche in der Hand – noch schnell beim Tester an… dieser möge sich “doch schnell mal mit dem Entwickler absprechen wegen Tab3 und Tab2 und wegen den anderen Änderungen, ich schicke euch noch eine Mail darüber.”

16:01 Uhr: Der Tester überprüft den Projektplan, der noch in seiner alten, ca. sieben Wochen alten Ausgangsform ist und verschickt eine Mail an seinen Abteilungsleiter. Darin berichtet er von möglichen Komplikationen im Endtermin. Anschließend begibt er sich ins Zimmer des Entwicklers.

16:15 Uhr: Der Entwickler blickt erstmals vom Monitor auf. Er entdeckt den Tester, der es mittlerweils aufgegeben hat, sich über Lautäusserungen bemerkbar machen zu wollen… bei der Geräuschkulisse aus Rechnerlüftern, piepsenden Prozess-Monitoren, der röchelnden Kaffeemaschine und der plärrenden mp3-Sammlung fällt so etwas nicht auf. Der Entwickler grunzt, was soviel bedeutet wie “Ja bitte, lieber Kollege, was kann ich für Dich tun?”. Der Tester berichtet vom Anruf und von seinem Auftrage, woraufhin der Entwickler ihm mit einer den Haaransatz berührenden, hochgezogenen Augenbraue zu verstehen gibt, dass ihn per definitionem keinerlei mündlich getätigte Änderungen an einer schriftlichen Arbeitsanweisung interessieren und dass sie ohnehin von der falschen Person kommen.

16:30 Uhr: Der Leiter der Abteilung Entwicklung eilt ins Zimmer des Entwicklers, neugierig, warum sich Entwickler und Tester anschreien. Er gibt dem Entwickler in allen Punkten recht und schickt den Tester zurück in seinen dunklen Kabuff. Daraufhin informiert er sich beim Entwickler über den Grund des Aufruhrs.

Tag 8

Der Projektmanager hat “home office”. Das bedeutet, er arbeitet zu Hause, wo er vom Tagesgeschäft ungestört endlich den ganzen Papierkram nachholen kann und konsequent und kontinuierlich arbeiten kann, mit anderen Worten: er liegt auf dem Sofa und sieht fern.

12:30 Uhr: Der Leiter der Abteilung Qualitätssicherung – genauestens und objektiv informiert über die Abläufe im Projekt-Team – zitiert den Tester zu sich und faltet ihn fein säuberlich zusammen. Begriffe wie Teamfähigkeit, Toleranz, pragmatisch und kundenorientiert flitzen durch den Raum.

Tag 20

09:30 Uhr: Der Kunde ruft den Projektmanager auf dessen Firmenhandy an, während dieser irgendwo zwischen Kassel und Frankfurt im Auto sitzt und zu einem Kundentermin fährt (aka sich Gartenmöbel anschauen will). Bei diesem Gespräch werden der Endtermin um 2 Wochen vorverlegt sowie 37 marginale Änderungswünsche an Aussehen, Funktion, Leistungsfähigkeit und Umfang der in einer Woche zu liefernden Software besprochen. Nach dem Gespräch wirft der Projektmanager das Handy auf den Beifahrersitz, schreit die Autobahn an “ich kann so nicht arbeiten!” und legt eine Pinkelpause ein, bevor er den Entwickler und Tester informieren wird.

12:30 Uhr: Der Tester bespricht im Statusmeeting der Abteilung den nicht vorhandenen oder im günstigsten Falle nicht sichtbaren Projektfortschritt mit seinem Abteilungsleiter. Dieser sagt zu, sich darum zu kümmern und die Lage mit den Abteilungsleitern Projektmanagement und Entwicklung in der grossen Häuptlingsrunde zu bereden.

Tag 22

09:30 Uhr: Der Projektmanager trommelt den Entwickler und den Tester zum Eskalations-Status-Meeting zusammen und berichtet über die “gerade eben reingekommenen, unabdingbaren Änderungen, alles absolute No-Gos wenn nicht drin, blocking condition, verstehens”. Er kann sich an insgesamt noch 15 Change Requests und Features erinnern, “da gab es noch was, aber das blocke ich weg, kein Problem, das verargumentiere ich.”

10:30 Uhr: Der Entwickler und seine vier schnell noch ins Projekt geworfenen Kollegen arbeiten wie besessen an Tab 5 bis Tab7 sowie den Reporting- und Billing-Funktionen. Gleichzeitig färbt sich unter der Wucht der ausgestossenen Verwünschungen die Luft im Gang langsam grün.

10:35 Uhr: Der Tester fragt den Projektmanager nach einer schriftlichen Dokumentation, quasi einer angepassten Spezifikation. Der Projektmanager lächelt süffisant und kommentiert dieses Ansinnen mit einer längeren Antwort, deren Quintessenz in etwa lautet: “Als ob ich für so etwas auch noch Zeit hätte, ihr seht doch, was ich alles stemmen muss und zwar ganz alleine, wenn ihr in Entwicklung und Test weniger Zeit auf Meckern verbraten würdet und auf das Suchen nach Gründen, warum etwas nicht geht, dann wären wir schon lange fertig.”

11:22 Uhr: Der Tester bespricht die Situation mit seinem Abteilungsleiter. Dieser bedauert, bislang noch nicht dazu gekommen zu sein, sich intensiver einzuschalten und um das Projekt gekümmert zu haben. Aber “kein Problem, das kriegen wir schon.”

Tag 25

10:38 Uhr: Während des siebten Eskalationsmeetings und nach nunmehr der zwölf Status-Abfragen durch Projektmanager, Leiter Qualitätssicherung, Leiter Entwicklung und Geschäftsführer (der seinem Duz-Freund auf Kundenseite ein seit Jahren in verschiedenen Umgebungen reibungslos laufendes, tausendfach bewährtes Gesamtsystem versprochen hat) stellt sich für den Tester die Frage, wie er die veranschlagten 25 Manntage Testaufwand in die verbliebenen fünf Kalendertage packen soll… zumal die Software nach Auskunft des Entwicklers erst in drei Tagen testbar sein wird. Auf Nachfragen bei seinem Chef bekommt er die entsetzte Frage zu hören: “Warum kommst du damit denn erst jetzt? Wie soll ich denn gegensteuern, wenn ich nicht weiss, dass der Termin in Frage steht?!”

Tag 28

23:34 Uhr: Der Tester hat die letzten drei auf den Testserver gespielten Versionen seit nunmehr 38 Stunden ohne Schlaf getestet und wimmert nun leise vor sich hin, bis er über der Tastatur zusammen bricht.
Tag 29

06:30 Uhr: Eskalationsmeeting zwischen allen sieben Entwicklern und dem Tester. Der Projektmanager hat heute home office. Die Reste der kalten Pizza von gestern nacht um 02:15 Uhr riechen unangenehm.

06:50 Uhr: Die erste halbwegs lauffähige Version steht zur Verfügung. Der Tester schafft den ersten Testdurchlauf der ersten Funktionalität des ersten Tabs mit beinahe keinen nennenswerten Problemen.

08:00 Uhr: Statusmeeting mit sieben Entwicklern, dem Tester und allen Abteilungsleitern des Unternehmens. Es wird eindringlich auf die Wichtigkeit des Projektes verwiesen und betont, dass man es sich nicht leisten könne, diesen Kunden zu verärgern.

10:00 Uhr: Der erste Tab ist fertig getestet. Er funktioniert! Euphorie schwappt durch die Gänge! Tab2 und Tab3 ebenfalls! Hurra!

10:15 Uhr: Der Projektmanager ist aufgestanden und macht sich Kaffee. Er ruft kurz beim Tester an, lässt sich die Lage schildern und informiert daraufhin telephonisch den Geschäftsführer, dass er alles im Griff habe und es sehe gut aus, nur der Test mache ihm Sorgen.

22:15 Uhr: Der Tester erklärt den letzten Testlauf für abgeschlossen. Es gäbe zwar noch 277 offene Bugs, die meisten seien aber nicht wirklich schwerwiegend oder es gäbe einen Workaround. Er schreibt eine Mail an den Projektmanager und fällt in einen unruhigen Schlaf auf der Tastatur.

Tag 30

08:45 Uhr: Der Projektmanager schreibt eine Mail an einen 20 Personen umfassenen Verteiler und erklärt, dass er in einer Kraftaktion die Kuh vom Eis gezogen habe. Der Tester habe ihm das vollumfängliche Funktionieren alles Kernfunktionalitäten garantiert und “das look&feel sowie die Ergonomie ist bei uns sowieso immer state of the art.”

11:00 Uhr: Der Kunde ruft den Geschäftsführer an und bedauert, dass durch eine saublöde Verkettung unglücklicher Umstände die Hardware noch nicht bereit steht, so dass die neue Software noch gar nicht eingesetzt werden kann. “Die Lieferprobleme wäre zwar schon seit drei Wochen im Hause bekannt, aber anscheinend habe keiner der Einkäufer den eigenen Projektmanager informiert, in den fraglichen Tagen konnte dieser ohnehin nichts machen weil er home office hatte und naja, dann lassen wir uns halt noch vier Wochen Zeit, ich habe sowieso noch den einen oder anderen Vorschlag, was man noch einbauen könnte. Dann sind wir ja immer noch vor dem ursprünglich ins Auge gefassten Termin fertig.”

Tag 32

Der Projektmanager wird für seine aussergewöhnlich aufopferungsvolle Arbeit in einer Rundmail an alle Mitarbeiter gelobt. Der Tester muss sich in einem Gespräch mit dem Betriebsrat dafür rechtfertigen, dass er die maximale Arbeitszeit über einen längeren Zeitraum immer wieder überschritten hat. Der Betriebsratsvorsitzende schickt ihm eine förmliche Abmahnung wegen wiederholten Verstosses gegen das Arbeitszeitgesetztes nach mündlich erteilter Aufforderung, dieses zu unterlassen.

Tag 35

Im Review-Meeting des bisherigen Projekt-Ablaufes ermahnt der Projektmanager den Tester, sich künftig sorgsamer an den Kundenwünschen zu orientieren. Schliesslich sei man keine Bastelbude, sondern ein Systemhaus und es gäbe auch einen Ruf zu verlieren. Manchmal müsse man eben auch mal mitdenken und könne sich nicht nur darauf verlassen, alles vorgekaut zu bekommen…

… es wurde rot…

… es wurde Nacht….

… es wurde weisses Licht…

Tag 40

Der Tester wacht schreiend auf. Die Opiate wirken nur bedingt. Er ist immer noch ans Bett fixiert und eine Kamera mit Bewegungsmelder überwacht ihn permanent. Gestern waren ein paar Kollegen da und haben sich nach ihm erkundigt. Dem Projektmanager geht es auch schon wieder besser, die meisten Bisswunden konnten genäht werden und mit etwas Glück wird nur ein leichtes Hinken bleiben.