Keiner will sie haben – und doch gehören sie fast zwangsläufig zur Software-Entwicklung dazu: Bugs bzw. Fehler. Muss das wirklich sein? Können die Entwickler nicht aufpassen? Und wenn ihnen etwas durchgeht, warum findet die Qualitätssicherung die Fehler nicht, bevor die Lieferung an den Kunden geht?
Der Teufel steckt hier – wie bei vielen anderen Dingen – im Detail. Und darum soll es in diesem Beitrag gehen. Es gibt viele Beteiligte, viele Ursachen für Fehler und viele Aktivitäten, die in diesem Umfeld möglich und nötig sind.
Natürlich ist es für jeden Benutzer ärgerlich, wenn er mit einer Anwendung etwas tun möchte, das aber nicht gewünscht funktioniert. Ärgerlich ist es im nächsten Schritt für unser QS-Team, das sich selbstverständlich fragt, warum ihm der Fehler verborgen geblieben ist. Und das gleiche gilt anschließend für die Entwickler.
Wenn ein Fehler aus Anwendersicht gefunden wird, geht es zunächst darum, die Ursache im System zu finden und zu korrigieren. Ist das erledigt, werden besondere Fälle in unseren QS-Review-Meetings analysiert, um herauszufinden, ob wir in unseren internen Prozessen Veränderungen vornehmen können, die das Sicherheitsnetz noch engmaschiger knüpfen.
QS-Spürnasen
Manche Fehler sind offensichtlich, andere rufen tatsächlich die „Landshut Cops“ auf den Plan. Es gilt, eine zunächst diffuse Lage zu strukturieren und so viele Details wie möglich zusammenzutragen, damit die Entwickler schneller zum Ziel kommen können. Ihnen bleibt damit trotzdem oft noch genug Arbeit, ihre Code-Spürnasen zu aktivieren und die Stelle im Code zu finden, wo der Fehler passiert und anschließend eine bessere Lösung zu entwickeln.
Reproduzierbarkeit
Angenommen, ein Fehler wird von unserem QS-Team gefunden. Wenn es im Rahmen eines Volltests beim Abarbeiten des Test-Protokolls passiert, sind die Schritte bekannt. Wird der Fehler eher zufällig entdeckt, muss als erstes rekonstruiert werden, welche Schritte den Fehler ausgelöst haben. Darauf folgt die Frage, ob hier „Ein Mal ist kein Mal“ geltend gemacht werden kann. Passiert der Fehler beim gleichen Vorgehen ein zweites oder drittes Mal? Passiert er mit einem anderen Dokument, Element oder Daten ebenfalls? Ausprobieren, Fakten sammeln und dokumentieren lautet die Devise mit den Schritten, die in den nächsten Absätzen vorgestellt werden.
Jeder Fehler, der vom Kunden gemeldet wird, schmerzt in der QS-Seele. Gegen diesen Schmerz hilft erstmal eine Portion Skepsis, denn wenn der Fehler bei uns nicht reproduzierbar ist, hatten wir keine Chance, ihn zu entdecken. Das erleichtert die QS zunächst, macht es aber in der Folge schwieriger. Was ist beim Kunden anders als bei uns? Gibt es verschiedene Wege zum Ziel, und wählen wir (vielleicht aus Gewohnheit) den einen Weg, während der Kunde den anderen Weg wählt, den wir gar nicht in Betracht ziehen?
Bei manchen Fehlern hat sich auch später gezeigt, dass sie auf Mengenprobleme zurückzuführen waren. Eine Löschfunktion kann beispielsweise an ihre Grenze stoßen, wenn sie auf einer Datenbank ausgeführt wird, die mit vielen tausenden Datensätzen gefüllt ist. Dann liegt es nicht an der Software, die bei begrenzten Mengen einwandfrei funktioniert, sondern in anderen Bereichen.
Hier sind wir ganz eindeutig auf die Mitarbeit des Kunden angewiesen, brauchen eine genaue Beschreibung seines Vorgehens, Beispiele, Exportpakete oder Logs, um Erkenntnisse zu sammeln.
Browser ist nicht gleich Browser
Firefox, Edge und Chrome: Die Liste der unterstützten Browser ist überschaubar, zumal Edge und Chrome die gleiche Basis aufweisen und zusammengefasst werden können. Trotzdem gibt es immer wieder Überraschungen, weil sich die Browser in manchen Fällen unterschiedlich verhalten. Wenn also ein gemeldeter Fehler nicht reproduzierbar ist, kann die Verwendung eines anderen Browsers manchmal ein anderes Bild ergeben.
Was die Reproduzierbarkeit erleichtern kann, ist Pflicht für die QS bei einzelnen Tickets und Volltests. Es reicht leider nicht, nur einem Browser zu testen. Ernsthaft durchgeführt verdoppelt sich der Aufwand für jeden Test – man weiß ja nie…
Normaler Benutzer oder Admin
Der durch die Browser verdoppelte Testaufwand lässt sich weiter steigern, wenn der Test mit unterschiedlichen Benutzerrollen durchgeführt wird. Abgesehen von den Möglichkeiten oder Einschränkungen, die eine Benutzerrolle von Haus aus mit sich bringt, kommt es durchaus mal vor, dass sich eine Anwendung in Details anders verhält, wenn der Benutzer mit oder ohne Admin-Rechten angemeldet ist.
Wenn die Zeit zum Testen knapp ist, verwenden wir zumindest Kreuz-Kombinationen und testen beispielsweise mit Admin-Rechten im Firefox und ohne Admin-Rechte im Edge.
Fehlerquelle Merge
Fehlerquelle Seiteneffekte
Vorne aufbauen, hinten abräumen – diese Aussage kennt man für den sprichwörtlichen Porzellanladen, und sie gilt auch für die Software-Entwicklung. Es kann also sein, dass sich eine Änderung an einer Stelle des Codes in verschiedenen Bereichen der Anwendung auswirkt. Ein Fehler wird behoben, aber dafür tritt ein anderer neu auf. Wenn sich das Ganze im gleichen Bereich der Anwendung, z.B. im gleichen Dialog abspielt, sollte es der Entwickler bei seinen Tests bereits merken. Je weiter der Ort des Seiteneffekts aber vom Ort der ursprünglichen Fehlerbehebung entfernt ist, desto schwieriger wird es, den Seiteneffekt zu finden. Es ist unmöglich, nach jedem neuen Deployment einen Volltest durchzuführen, der mehrere Personenwochen in Anspruch nimmt.
Seiteneffekte können auch auftreten, nachdem Bibliotheken aktualisiert wurden, um CVEs zu beseitigen. Je größer der Sprung von der aktuell verwendeten Version auf die Zielversion ist, desto höher ist die Wahrscheinlichkeit für ungewollte Seiteneffekte. Wir achten deshalb darauf, möglichst regelmäßig Updates vorzunehmen, um dieses Risiko zu minimieren.
Was Logfiles können oder nicht
Log-Dateien enthalten jede Menge an Informationen und können einige MB Speicherplatz belegen. Dass dort so etwas drin steht wie „Der Fehler tritt in Funktion Sowieso in Zeile 33 auf.“ ist leider nur ein Wunschtraum. Natürlich gibt es verwertbare Hinweise, aber die müssen zunächst gefunden und anschließend richtig interpretiert werden. Sehr hilfreich ist es, wenn der Zeitpunkt, zu dem der Fehler aufgetreten ist, bekannt ist. Dann beschränkt sich die Suche auf eine überschaubare Zahl an Zeilen.
