Software-Test

Die Fehlerdokumentation: Eine Geschichte voller Missverständnisse

„Warum hast du mir diesen Bug zugewiesen? – Ich habe dieses Feature nicht entwickelt. Wieso wurde dieser Bug dokumentiert? – Das hätten wir doch anders lösen können.  Kannst du dieses Ticket nicht einfach schließen? – Das wird ohnehin nie jemand bearbeiten. Ich habe keine Lust mehr mit dir zu arbeiten, du meldest immer so viele Fehler ein.“

Das sind tatsächlich einige der Fragen und Aussagen, mit denen ich in meiner bisherigen Laufbahn als Software-Tester konfrontiert wurde. Doch wie kommt es zu genannten Situationen. Warum sind sie so problematisch und wie können wir sie lösen? Darauf möchte ich in diesem Beitrag eingehen.

Fehlerdokumentation Software-Test

„Das Testen von Software dient durch die Identifizierung von Defekten und deren anschließender Beseitigung zur Steigerung der Softwarequalität. Dabei senkt das Testen lediglich die Wahrscheinlichkeit dessen, dass Fehler im Testobjekt unentdeckt bleiben.“ (ISTQB)

 

  1. Menschen machen Fehler
  2. Software ist fehleranfällig
  3. Menschen entwickeln Software

 

Als Software-Tester ist es meine Aufgabe genau diese Fehler zu finden, zu dokumentieren und in späterer Folge zu überprüfen ob sie auch richtig behoben wurden. Je nach verwendetem Fehlermanagementtool und Workflow, erreicht der von mir erstellte Fehlerreport früher oder später das Entwicklerteam.

 

Ungeklärte Zuständigkeiten

Über die Jahre hinweg arbeiten oft verschiedene Entwickler an ein und derselben Applikation. Wenn bspw. ein Entwickler die Firma verlässt und die Weiterentwicklung einer App einem Kollegen übergeben wurde, muss sich dieser natürlich auch um die Altlasten in dieser App kümmern. „Warum hast du mir diesen Bug zugewiesen? – Ich habe dieses Feature nicht entwickelt.“ Niemand fühlt sich zuständig. Die Bugs werden dann ignoriert oder einfach immer wieder jemand anderem zugewiesen. Verfolgt man die Historie eines solchen Bugs, liest sich das oft wie ein Pingpong Spiel. Was zur Folge hat, dass die Tickets ewig nicht gelöst werden. Bei größeren Teams empfiehlt es sich nach Absprache, die Tickets der Person mit der meisten Entwicklungserfahrung (Lead-Developer) zuzuweisen, welcher sie dann innerhalb der Mannschaft zuteilen kann. Zudem sollten regelmäßig Defect Backlog Meetings abgehalten werden, um genau diese Art von Langläufer frühzeitig identifizieren zu können, noch bevor der Bug graue Haare bekommt.

 

SAG JA zur Dokumentation

Immer wieder kommt es vor, dass Bugs nach mündlichem Reporting direkt unter der Hand gelöst werden. Viel zu oft leider auch ohne dokumentierten Bugreport und in der Regel werden dabei auch sämtliche, mühsam ins Leben gerufene Workflows ausgehebelt. Abhängig von der Komplexität des Bugs und der Größe des Projektes, geht dieser Schuss früher oder später nach hinten los. Handelt es sich nur um einen Rechtschreibfehler oder Ähnliches bekommt man nach der Bugzuweisung vermutlich zu hören: „Wieso wurde dieser Bug dokumentiert? – Das hätten wir doch anders lösen können.“ Klar könnte man das. So arbeite ich aber nicht! Oftmals ist das der Anfang vom Ende. Keine Frage – diese Art der Fehlerbehebung ist unkomplizierter und ohne zusätzlichen Aufwand, schnell zu erledigen. Immer mehr Fehler werden dann auf diese Weise gelöst und die Sache läuft aus dem Ruder. Hier geht es nicht darum eine Bugquote zu erfüllen oder den Entwickler zu ärgern. Es geht um die Nachvollziehbarkeit auf lange Sicht. Oftmals hat man verschiedene Softwareversionen auf unterschiedlichen Environments deployed. Wenn dann parallel auch noch mehrere solcher nicht dokumentierter Quickfixes gemacht werden, geht komplett die Übersicht verloren. Auch wenn der Entwickler solch einen Fix sofort deployed, sollte der Tester einen Bug ein melden, einen passenden Testfall erstellen oder je nach Situation auch Beides. Oftmals ist das eine Angelegenheit von 2 Minuten. Andernfalls kann die ganze Vorgehensweise zu einem sehr bösen Erwachen in der finalen Version auf Produktion führen. Wo man sich dann grün und blau ärgert, wenn plötzlich Fehler auftauchen, die doch schon lange behoben waren. Auf mysteriöse Art & Weise sind plötzlich die Bugfixes unter den Tisch gefallen. Noch schlimmer, wenn die Fehler komplett in Vergessenheit geraten, zumal sie eventuell nur unter bestimmten Umständen auftreten. Da man aber keinen Testfall dafür angelegt hat, wird diese Art von Fehler auch beim Regression Test immer wieder ungeschoren davonkommen. Lieber ein paar Minuten mehr für die Dokumentation aufwenden, dafür im Anschluss ein gutes Gewissen und vor allem am Ende ein sauberes System zu haben.

 

Die Qual der Wahl

Nicht von schlechten Eltern war mein Gesichtsausdruck bei folgendem Feedback: „Kannst du dieses Ticket nicht einfach schließen? – Das wird ohnehin nie jemand bearbeiten.“ Dieser Aussage zugrunde liegend war zum einen ein gewaltiger Mangel an Entwicklerressourcen und zum anderen ziemlich demotivierte Kollegen, die schon mehrfach an selbigem Bugeintrag gescheitert waren. Das hat im Endeffekt dazu geführt, dass niedriger priorisierte Bugs vom Reporter selbst geschlossen wurden. Mit der Begründung: „Won’t fix – Keine Resourcen.“ Hier sollten eigentlich bei jedem Teammitglied die Alarmglocken läuten. Ganz offensichtlich existiert hier keinerlei Fehlermanagement und falls doch, hat es gründlich versagt. Der einzige Grund ein Bug-Ticket zu schließen ist, wenn dieses ordnungsgemäß durch einen Fix behoben wurde. Immer davon ausgehend, dass es sich hierbei um einen vom Fachbereich bestätigten Fehler und nicht um einen Userfehler bzw. falsch durchgeführten Test handelt. Jede andere Vorgehensweise wird früher oder später dem Reporter selbst oder einem anderen Tester auf den Kopf fallen. Wird man also mit einer Projektsituation konfrontiert, in der man vor der Wahl der Qual steht, entscheiden zu müssen, ob man den Fehler nun dokumentiert oder nicht, egal unter welchen Umständen, so sollte die Entscheidung immer zu einem neuen Ticket führen. Bugs verschwinden in der Regel nicht von selbst, egal wie lange man sie ignoriert. Sie sind wie die Sterne am Himmel. Auch wenn man sie nicht immer sehen kann…sie sind da und warten auf ihre Gelegenheit einem produktivem Anwender aufzufallen.

 

Die Schuldzuweisung

„Ich habe keine Lust mehr mit dir zu arbeiten, du meldest immer so viele Fehler ein.“ Ja das ist tatsächlich der exakte Wortlaut, den ich in einem Projekt zu hören bekommen habe. Eine Problemmeldung klingt nicht nur wie eine Schuldzuweisung, sie wird leider Gottes nach wie vor gerne als solche aufgefasst und das ist ein absolutes Unding. Das Reporten und adressieren eines Fehlers ist kein persönlicher Angriff auf einen Entwickler.  Bei der Softwareentwicklung geht es nicht darum, dass sich Entwicklung und Test gegeneinander behaupten müssen. Es geht darum, gemeinsam ein Projekt an sein Ziel zu bringen. Beispielsweise eine Applikation bis zu ihrer Marktreife zu begleiten, um sie dann mit gutem Gewissen voll funktionsfähig und unter Umsetzung aller gesteckten Ziele auf ein Produktivsystem und deren User loslassen zu können. Teamwork ist das Stichwort.

 

Ja, die Geschichte des Fehlermeldeverfahrens ist eine Geschichte voller Missverständnisse. Allerdings lernen wir durch jede dieser Geschichten dazu. Als Tester, als Entwickler, als Mensch!

Passende Artikel

Kommentare gesperrt.