Die hohe Kunst, einen Entwickler zu fragen, was er eigentlich gefixt hat.

Die meisten Tester und Testteams kennen genau diese Problematik. Der Hochmeister des Schweigens, auch Entwickler genannt, hat einen Bug gefixt, ihn eingecheckt, mit kryptischen Wörtern wie „Gefixt“,“Problem gelöst“,“Bug behoben“, in Git als Revisionsnummer hinterlegt.

Mehr Informationen liegen erstmal nicht vor. Und wie genau verhält sich dies nun im Testteam? Man checkt aus, fragt sich aber wie und was der Entwickler eigentlich gefixt hat. Also Rückfragen, mündlich, via Teams, und ein elender Mailpingpong, bis man entsprechend alle Informationen zusammenhat.

Im Gegensatz zu den vielen Antworten, die besagen, dass die Tester die Änderungen im Quellcode überprüfen können, habe ich an mehr als einer Stelle gearbeitet, wo die Tester keinen Zugang zum Quellcode haben. Ihre einzige Informationsquelle über die Änderungen sind die Informationen, die im Ticket enthalten sind.

In dieser Situation müssen die Entwickler den Testern unbedingt Informationen über die von ihnen vorgenommenen Änderungen zur Verfügung stellen, und zwar in Bezug auf Dinge wie:

• Auf welche Konfigurationseinstellungen sich die Änderungen auswirken oder auf welche sie zutreffen. Viele Bugs treten nur unter bestimmten Konfigurationseinstellungen auf, aber ich habe schon erlebt, dass First-Pass-Fixes aufgrund der Annahmen des Codes Probleme mit verschiedenen Konfigurationen verursacht haben.
  Alle verwandten Teile der Anwendung, von denen der Entwickler weiß, dass sie betroffen sein könnten. Erfahrene Tester haben eine allgemeine Vorstellung davon, welche Module in der Software zusammenhängen, aber es gibt keine Garantie dafür, dass es keine subtilen Abhängigkeiten gibt, die der Entwickler erkennen kann, die den Testern aber nicht bekannt sind.
• Alle damit zusammenhängenden Probleme, die der Entwickler im Rahmen der Fehlerbehebung behoben oder umstrukturiert hat: Wenn es eine laufende Umstrukturierung gibt, ist es für die Tester wichtig, dies zu wissen, damit sie auch die anderen Änderungen überprüfen können.
• Es ist auch viel schneller für einen Entwickler, eine Reihe von Notizen zu einem Ticket mit diesen Informationen hinzuzufügen, als für den Tester, sich durch den Code zu wühlen, um herauszufinden, was betroffen gewesen sein könnte, einfach weil der Entwickler diese Notizen machen kann, während er an dem Objekt arbeitet.

 

Unter welchen Bedingungen tritt der Fehler auf?

Dies ist etwas anders als „Wie kann der Fehler reproduziert werden?“. Ein Fehlerbericht enthält normalerweise mindestens eine Möglichkeit, einen Fehler zu reproduzieren, und möglicherweise einige Szenarien, die das gleiche Problem zu verursachen scheinen. Aber ziemlich oft, wenn ich die Ursache eines Problems entdecke, stelle ich fest, dass es eigentlich allgemeiner ist, als die gemeldeten Szenarien, und/oder nur in Abhängigkeit von etwas anderem, was nicht in dem Bericht beschrieben ist, auftreten würde.

Zum Beispiel könnte ein Fehlerbericht vermerken, dass das Problem reproduziert wird, wenn man „Aktionen A und dann B mit Widget C ausführt“, aber eigentlich gibt es ein Problem immer dann, wenn man „eine bestimmte Klasse von Aktion A‘ und dann Aktion B mit einem beliebigen Widget mit Eigenschaft D ausführt, während mindestens ein E aktiv ist“.

Oder noch besser, ich könnte mit einem Problem beginnen, das zwar häufig, aber nicht zuverlässig auftritt, und einen Weg finden, es konsistent zu reproduzieren.

Dies ist eine wichtige Information für einen Tester, um die Tragweite der Änderung richtig zu testen. Wenn ich zum Beispiel den ursprünglichen Fehler wie oben beschrieben habe, möchte ein Tester vielleicht auch überprüfen, ob das Problem für eine Stichprobe von Aktionen A‘ und Widgets mit der Eigenschaft D behoben ist und ob das System in denselben Szenarien weiterhin korrekt funktioniert, außer wenn kein E aktiv ist.

Man könnte diese Frage umformulieren: „Gibt es andere Möglichkeiten, den Fehler zu reproduzieren?“. Eine Unterkategorie der Frage ist: „Gab es irgendwelche bestehenden Konfigurationseinstellungen, die den Fehler beeinflusst hätten?“

Wurde etwas anderes als der beobachtete Fehler behoben?

Natürlich sollten völlig unzusammenhängende Änderungen nicht an dasselbe Ticket angehängt werden. Aber vielleicht haben zwei verschiedene Funktionen eine gemeinsame Funktion verwendet, die einen Fehler hatte, der sich in jeder Funktion auf unterschiedliche Weise manifestierte. Oder vielleicht beinhaltete die Korrektur eine Umstrukturierung des Codes, die mehr als ein während der Arbeit identifiziertes Problem löste.

Euer Testteam sollte auf jeden Fall darauf aufmerksam gemacht werden, wenn ein positiver „Nebeneffekt“ wie dieser festgestellt wurde, damit es auch das testen kann.

Welche Funktionen üben den geänderten, hinzugefügten oder entfernten Code aus?

Dies ist die Kehrseite der vorherigen Frage. Manchmal hat eine Codeänderung angenehme Nebeneffekte, aber es besteht fast immer das Risiko, dass eine Codeänderung etwas anderes kaputt macht. Die Entwickler sollten sich bemühen, die Änderungen zu analysieren, um herauszufinden, was sonst noch falsch beeinflusst werden könnte, aber sie könnten auch etwas übersehen oder einfach zu dem Schluss kommen, dass das Restrisiko akzeptabel ist.

Wenn einige andere Funktionen einen Teil des gleichen geänderten Codes verwenden, kann es sich lohnen, alle automatisierten Tests für diese Funktionen im Auge zu behalten und/oder ein paar einfache Regressionstests für diese Funktionen durchzuführen.

In einem Extremfall kann die Antwort lauten: „Ich habe eine Kernfunktion der Bibliothek geändert, so dass die Auswirkungen überall zu sehen sind“. (Und vielleicht ist die Änderung „offensichtlich“ korrekt, aber ein anderer Code hat sich versehentlich auf das alte falsche Verhalten verlassen…) Es ist wahrscheinlich nicht machbar, alle manuellen Regressionstests durchzuführen, die Sie dokumentiert haben und/oder an die Sie denken können, wenn so etwas passiert, aber zumindest sind Sie sich des möglichen Problems bewusst.

Nun jeder denkt über das Thema anders, einfach dazu hier auch gerne mal eine Diskussion dazu.

Verkürzt würde ich also raten:

• Fixes sind nicht nur einzuchecken durch den Entwickler, sondern entsprechend auch sind die Fixes zu beschreiben.
• Man muss kein Entwickler sein, um eben zu verstehen, was der Entwickler gefixt hat, endlose Source-Änderungen braucht man sich nicht anzuschauen. Aber wenn es um inhaltliche Änderungen geht, muss auch deutlich für das Testteam klar definiert sein, was gefixt wurde. Anpassungen im Source schaue ich mir persönlich sogar gerne im Diff von Git an. Eben, weil ich wissen will, was der Entwickler angepasst hat. Alles andere macht auch keinen Sinn, dann ist man im Glaskugel Testing angelangt.
• Ein Tester muss kein Fachexperte sein, der jeden erdenklich Source Code kennen muss, aber bei relevanten Änderungen muss ihm klar sein, was im Source, und welche Bereiche geändert wurden.
• Gerade hinsichtlich Regressionstest sind meistens entsprechende Anpassungen vorzunehmen, auch und gerade hinsichtlich Testautomatisierung.