Jeder Jeck ist anders
Vor„ Das ist ja wohl das grausamste Stück Software, das ich jemals testen musste!“ Ein Tester, der sich so in Wort oder Schrift gegenüber einem Entwickler äußert, sollte nicht mit einer längerfristigen konstruktiven Zusammenarbeit rechnen. Testen hat auch viel mit sozialer Kompetenz zu tun. Daher wollen wir uns in diesem Artikel dem Thema Kompetenzen und Umgangsformen im Testumfeld widmen.
Tester sind auch nur Menschen …
Jeder gefundene Fehler zieht Arbeit nach sich – Fehlerberichte schreiben, mit der Entwicklung kommunizieren, Nachtesten etc. Ein Tester, der diese Aufgaben als lästig empfindet und möglichst keinen Fehler entdecken will, hat entweder seinen Beruf verfehlt oder aber einen grundlegenden Aspekt nicht verstanden. Die Mitarbeiter der Entwicklung und jene Fachkräfte, die testen, bilden ein Team, das voneinander partizipieren und lernen sollte. Entwicklung und Test sitzen in einem Boot, denn sie haben ein gemeinsames Ziel – den erfolgreichen Abschluss ihres Projektes. Wer hier in zwei Lagern denkt, womöglich sogar in Fronten, hat dies noch nicht verinnerlicht.
Natürlich kann es ärgerlich sein, wenn bei einem Tester zum wiederholten Male dasselbe Problem auftaucht und er abermals die gleiche Fehlermeldung erstellen muss. Auch kann es nervenaufreibend sein, wenn innerhalb des Fehlermeldedokuments (Ticket) „Ping-Pong“ gespielt wird – damit ist ein schriftlicher Schlagabtausch zwischen Entwickler und Tester gemeint, ohne dass das eigentliche Problem angegangen wird. Es sollte nicht um Schuldzuweisungen gehen, sondern vielmehr um Problemlösungen. Kein Entwickler macht mit Absicht Fehler. Schon gar nicht, um den Tester zu ärgern.
Der einzige vernünftige Weg, mit solchen Situationen umzugehen, sind Sachlichkeit und Genauigkeit. Eine Fehlermeldung muss eindeutig und vollständig sein, so dass sie keinen unnötigen Zweifel offen lässt. Ein Entwickler muss das Problem nachvollziehen und damit reproduzieren können. Jeder Diskussion ist damit von Beginn an der Nährboden genommen.
Und auch hier macht der Ton die Musik. Es fängt mit Kleinigkeiten an. So hat z.B. ein Satz wie „Der Fehler ist erneut aufgetreten.“ eine andere Wertigkeit als „Leider ist der Fehler schon wieder aufgetreten!“ Insbesondere wenn sich Tester und Entwickler nicht persönlich kennen, kann die Formulierung einen entscheidenden Unterschied machen. Wertende Füllworte haben in einer Fehlermeldung absolut nichts zu suchen!
Ebenso gilt: Führen Sie die Entwickler nicht vor. Das Verhalten eines Oberlehrers ist völlig unangebracht. Seien Sie sich bewusst, dass ein Fehler den Entwickler am meisten selbst ärgert. Hohn und Spott von Seiten des Testers ist das Letzte was hier angebracht wäre.
Zudem sollte ein Tester überlegen, welche der gefundenen Fehler er als „kritisch“ einstuft. Nimmt dies Überhand, läuft er Gefahr, bald nicht mehr ernst genommen zu werden. Nicht jeder Tippfehler ist eine Katastrophe. Das Testmanagement sollte daher klare Regeln aufgestellt haben, wie Fehler klassifiziert werden sollen.
… Entwickler übrigens auch
Beleuchten wir jetzt einmal die andere Seite und nehmen die Sicht der Entwicklung ein. Ein Entwickler, der den Test als destruktiv wahrnimmt, hat das Konzept ebenfalls nicht verstanden. Ein Fehler ist keine persönliche Kritik an den Fähigkeiten des Entwicklers, solange die Formulierung sachlich ist. Fehler sind natürlich ärgerlich, aber man sollte konstruktiv damit umgehen. Es ginge ein wenig zu weit zu fordern, sich über Fehler zu freuen, aber man sollte sie als Chance wahrnehmen, sich zu verbessern.
Eines sollte jedem Entwickler bewusst sein. Der Kunde hat Anforderungen gestellt, die realisiert werden müssen. Der Tester prüft jedoch sehr viel mehr als nur die reine Erfüllung dieser Anforderunen. Die Aufgabe des Testers ist es, Fehler zu finden – und zwar auch jene die links und rechts von der jeweiligen Anforderung liegen könnten.
Ein Beispiel: Der Kunde möchte, dass man auf einer Webseite eine Zahl eingeben kann, von der nach dem Absenden die Quadratwurzel berechnet und anschließend angezeigt wird. Sie setzen diese Anforderung um, machen einen Komponententest und sind mit dem Ergebnis zufrieden. Jetzt tritt der Tester auf den Plan und prüft u.a. folgendes: Eingabe einer ganzen positiven Zahl, einer reellen positiven Zahl, Eingabe einer negativen Zahl, er versucht Buchstaben einzugeben, probiert es mit Vorzeichen und Sonderzeichen, überprüft die Webseite gemäß des Styleguide, usw. Er fordert die entwickelte Lösung also richtig heraus (mathematisch, stilistisch, logisch, etc.).
Wie bereits erwähnt, ist es die Aufgabe des Testers Fehler zu finden! Mit Sadismus oder übertriebener Gründlichkeit hat das nichts zu tun. Würde er das nicht machen, müssteman ihm mangelnde Sorgfalt vorwerfen. Das obige Beispiel erklärt auch, warum eine Anforderung in der Regel mehrere Testfälle zur Folge hat und die Gesamtanzahl der Testfälle sehr schnell ein sehr hohes Ausmaß annehmen kann.
Der Kölner sagt: „Jeder Jeck ist anders.“ Dies gilt nicht nur bei Menschen derselben Nationalität, sondern insbesondere auch dann, wenn man es mit Outsourcing zu tun bekommt. Von sich auf andere zu schließen, kann dabei ungeahnte Folgen haben. Sie schlagen beim Sitzen gern mal ein Bein über das andere? Das ist keine gute Idee, wenn neben Ihnen ein indischer Kollege sitzt. Der könnte dies als Beleidigung auffassen. Sie begreifen nicht, warum einem Kollegen das doch so Offensichtliche verborgen bleibt? Wahrscheinlich liegt es daran, dass es für ihn vermutlich nicht so offensichtlich ist. Menschen sind kompliziert und in Teams wird das erst so richtig deutlich. Ein arroganter Tester ist dann genauso fehl am Platz wie ein Entwickler mit dem Anspruch der Unfehlbarkeit. Die Lösung ist und bleibt das konstruktive und offene Gespräch!
Organisatorisches
Wie schon eingangs dargestellt wurde, sollten Entwicklung und Test als Team aufgestellt sein. Das funktioniert aber nur dann, wenn es auch organisatorisch ermöglicht wird. Und das beutet unter anderem auch, dass beide Gruppen nicht ausschließlich über Werkzeuge miteinander kommunizieren sollten. Werkzeuge zur Fehlerverwaltung, Testerstellung und -ausführung bilden lediglich die Basis für einen sauberen Prozess. Wenn sie dann sogar eine Suite bilden, ist es umso besser. Aber Werkzeuge sind kein Ersatz für den direkten Austausch von Angesicht zu Angesicht. Der kurze Weg ins Nachbarbüro ist in vielen Situationen sehr viel effektiver, als alles, was über gegebenenfalls überflüssige elektronische Tickets oder lange E-Mails erreicht werden kann.
Dies soll natürlich kein Aufruf zum Arbeiten jenseits des Prozesses sein. Ich spreche von Dingen, die bei einem Kaffee oder einem kurzen gemeinsamen Blick auf den Bildschirm geklärt werden können. Wenn eine Organisation durch die starre Trennung von Entwicklung und Test diese Möglichkeiten unterbindet, schränkt sie sich selbst in ihrer Effizienz extrem ein. Projekte in einem solchen Umfeld sind immer teurer als nötig – ohne Ausnahme.
Es geht in erster Linie um räumliche Nähe, nicht darum Verantwortlichkeiten zu vermengen. Entwicklung und Test dürfen und sollen auch weiterhin ihre eigene getrennte Führung haben.
Das letzte Wort
Das letzte Wort in Sachen Fehlerbehebung hat der Test. Was ist damit gemeint? Ein Tester hat eine Fehlermeldung geschrieben und ein Entwickler hat das Problem angegangen und gelöst. Das heißt, die Fehlermeldung hatte bis dahin vielleicht den Status „gemeldet“ (durch den Test) und danach „in Bearbeitung“ (bei der Entwicklung). Jetzt aber ist die Entwicklung fertig und gibt die Meldung an den Test zurück. Es findet also wiederum ein Statusübergang statt. Sinngemäß wäre so etwas wie „fertig zum Testen“ ein angemessener Folgezustand. Der Tester prüft daraufhin die Änderung und setzt anschließend die Fehlermeldung auf „gelöst“ oder aber er weist die Lösung erneut zurück mit einem Status wie beispielsweise „ungelöst – zurück an die Entwicklung“.
Vielleicht denkt sich nun der Eine oder Andere, dass dieser beschriebene Prozess nicht ungewöhnlich ist und dem aktuellen Status Quo entspricht. Leider ist dem aber in der Praxis häufig nicht so. Es gibt Projekte in denen die Entwicklung entscheidet, dass eine Fehlermeldung geschlossen wird, sobald eine vermeintliche Lösung programmiert wurde. Völlig ungeachtet der Tatsache, ob bereits getestet wurde oder nicht. Stellt der Tester anschließend aber doch noch einen Fehler fest, müsste er eine komplett neue Fehlermeldung erstellen (denn die Ursprüngliche wurde ja bereits geschlossen). Das ist nicht nur ineffektiv, sondern auch der komplett falsche Ansatz. Nur der Ersteller eines Tickets (oder sein Stellvertreter) hat das Recht und die Kompetenz es zu schließen. Grund dafür ist nicht zuletzt auch die Tatsache, dass eine Testumgebung viel eher den Produktionsbedingungen entspricht, als eine Entwicklungsumgebung.
Doch selbst wenn dieses Verfahren etabliert sein sollte, gibt es dabei mindestens eine zusätzliche Spielregel zu beachten. Eine Fehlermeldung wird auch dann geschlossen, wenn ein Folgefehler entdeckt wurde, der mit dem ursprünglichen Problem nichts oder nur indirekt zu tun hat. Jeder Fehler ist ein eigenständiges Objekt, das auch aus Statistikgründen (für die Testmanager und Projektleiter besonders wichtig) einzeln gezählt werden muss. Also auch in diesem Umfeld sollten klare und sinnvolle Regeln zwischen Entwicklung und Test verbindlich festgelegt werden.
100 % gibt es nicht
Dieser Tage kam einer meiner Kollegen ins Schwitzen, weil ihm seitens der Entwicklung folgende Frage gestellt worden war: „Warum hat der Test diesen Fehler nicht gefunden?“ Eigentlich ist diese Frage völliger Humbug. Man fragt einen Entwickler ja auch nicht, warum er den Fehler überhaupt erst eingebaut hat. Auch Tester können Fehler machen, was meistens bedeutet, dass sie Probleme übersehen. Doch selbst wenn es den perfekten Tester gäbe, der niemals etwas übersieht, wäre ein hundertprozentiger Test, der alle Eventualitäten berücksichtigt, überhaupt nicht möglich. Gerade in komplexen Systemen gehen die Permutationen von Testkombinationen schnell in die fünf- bis sechsstelligen Bereiche (zur Erinnerung: eine Anforderung führt zu n Testfällen). Darum ist eine Priorisierung der Testfälle unerlässlich.
Selbstverständlich wird das Testteam versuchen, die Qualität aller Testobjekte zu sichern. Sie werden aber üblicherweise den sensiblen Bereichen mehr Aufmerksamkeit schenken (in Form von Zeit und Anzahl der Testfälle) als den weniger erfolgskritischen.
Könnte man nicht durch eine Testautomatisierung eine 100%-ige Testabdeckung schaffen? Auch hier lautet die Antwort: Nein. Bei einer vollautomatisierten Quellcodeanalyse, wäre das zwar denkbar. Doch diese sagt nichts über die Richtigkeit der Abläufe aus. Sobald wir also von Benutzeroberflächen und User-Interaktionen sprechen, ist es vorbei. Solche Tests automatisieren sich nicht von alleine – auch sie müssen entwickelt werden. Auch hierbei können Fehler enstehen. Baut man eine Automatisierung über mehrere Releases hinweg auf, verbessert sich natürlich die Situation für alte Funktionalitäten. Aber es kommen auch stetig neue hinzu. Daher ist eine hundertprozentige Testabdeckung aus rein mathematischen Gesichtspunkten gar nicht möglich.
Schuster bleib bei deinen Leisten
Stellen sie sich vor, Sie haben ein Bild gemalt und präsentieren es einem potenziellen Bewunderer. Sie hoffen natürlich auf Anerkennung und Lob, denn Sie sind stolz und überzeugt von Ihrem Werk. Wenn die angesprochene Person sich jedoch eher kritisch äußert, kratzt das an Ihrem Ego und man tendiert dazu, dem Kritiker seine Kompetenz abzusprechen. Möglicherweise hatte er aber einfach Recht und die eigene Begeisterung war größer als das Können.
Kaum jemand ist im Bezug auf die eigenen Arbeitsergebnisse unvoreingenommen eingestellt. Daher sollte ein Entwickler auch nicht die von ihm programmierten Funktionalitäten testen. Unterbewusst wird der Entwickler tendenziell so testen, dass die eigene Erwartungshaltung bestätigt wird. Ein Tester, wie oben bereits beschrieben, hat da eine ganz andere Herangehensweise. Steht kein Tester zur Verfügung, fragen Sie einen Kollegen aus der Entwicklung, der mit Ihrem Code nichts zu tun hatte. So ist zumindest eine gewisse Objektivität gewährleistet.
Bildnachweis: pixabay.com | buddy chat person messaging
