Richtig Fehler melden

So gerne man es hätte, dass Xojo fehlerfrei wäre: Das erste Gesetz der Informatik spricht dagegen: Kein Programm ist fehlerfrei. Jedenfalls wurde mir das (womöglich nur zur Beruhigung) seinerzeit beim Informatik-Studium so erklärt.

Und da die Xojo-IDE ein ziemlich komplexes Programm ist und sich darüberhinaus in beständiger Fortentwicklung befindet, bleibt es nicht aus, dass man hier und da mal über einen Bug stolpert. Betrifft dieser die IDE selbst – im Volksmund: „Xojo ist abgestürzt“, ist dieser Fehler einfach zu melden. Sofern nämlich Feedback, das Programm zur Fehler- und Featurewunsch-Reportage, installiert ist, geht beim nächsten Xojo-Start ein Fenster auf, das nachfragt, ob man diesen Absturz berichten möchte. Man tippt dann nur eine kurze Beschreibung dessen ein, was zum Crash führte, und es wird automatisch ein Bericht eingereicht.

Was aber tun, wenn man einen Programmfehler bemerkt, der nicht zur Verabschiedung des Programms führte? Ein Eintrag im Forum reicht dafür nicht. Nur Fehler, die via Feedback berichtet werden, finden auch die Kenntnisnahme der Ingenieure. Zunächst also mal sollte man sicherstellen, dass Feedback installiert ist. Es findet sich unter den Extra-Downloads bei Xojo.

Idealerweise sollte man den Bericht mit einem Beispielprogramm garnieren, damit seine Gültigkeit schnell nachgeprüft werden kann. Also: Wenn irgend möglich, extrahieren Sie die Problemstelle in ein kleines Projekt.

Um das alles nicht zu theoretisch werden zu lassen: Ein Anwender und Blogleser hat mich kürzlich mit einem Problem konfrontiert, das ich zunächst nicht nachvollziehen konnte. Wie sich zeigte, hat er einen Fehler des 64 Bit-Frameworks gefunden. Also gehen wir dies mal zusammen an:

Ich erstelle ein Desktop-Projekt und benutze dort den Open-Event des Standardfensters. Der bekommt den Code

Dim m As currency = 1.1
Dim v As currency = 1.21
If (v < M And v <>0) Or m = 0 Then
 Dim i As Integer = 1
Elseif (v > M And M <>0) Or v = 0 Then
 Dim j As Integer = 2
Elseif v = m Then
 dim k as integer = 3
End If

(Ich habe hier einfach Werte des mir zugeschickten Code-Auszuges verwendet. Es zeigte sich nämlich, dass unter 64 Bit – zumindest auf den Mac – die erste ElseIf-Klausel übersprungen wird und das Programm nach der If-Abfrage fröhlich in die letzte ElseIf-Bedingung springt.)

Das Projekt speichere ich ab und wechsle nach Feedback, wo ich mich mit meinen Xojo-Accountdaten anmelde. Das geht ganz bequem durch Klick auf das Feedback-Symbol in Xojos Werkzeugleiste.

Feedback-Symbol

Nun mag es ja sein, dass jemand dieses Problem schon berichtet hat. Deshalb schnell ein paar aussagekräftige, aber kurze Worte zum Thema in das Suchfeld eingegeben und Return gedrückt:

Feedback Search.png

Nichts da zu „ElseIf 64 Bit“, jedenfalls nichts, dessen Beschreibung in die angestrebte Richtung deutet. Also ein Klick auf „Create New Case“, und ich komme in den Fall-Editor von Feedback.

Feedback Report.png

Dort erweitere ich zunächst die von der Suchabfrage übernommene Summary, sodass sie in kurzen Worten eine möglichst präzise Darstellung des Problems ergibt.

Unter dem PopupMenu „Case Type“ wähle ich „Bug“ – um so etwas handelt es sich hier wohl. Für Teilnehmer der Betatests gibt es noch „Beta Bug“ – dann wird die Sichtbarkeit auf den Testerkreis beschränkt –, und für alle noch „Feature Request“, wenn es also nicht um einen Fehler geht, sondern man eine neue Funktion voschlagen möchte.

Die Angaben zum Betriebssystem trägt Feedback selbstständig ein, ebenso die Version.

Konnte ich sicherstellen, dass das Problem in einer früheren Version nicht existiert hat, setze ich einen Haken bei „This worked in a previous version“. Damit wird den Ingenieuren eine Regression signalisiert, also ein Rückschritt in der Funktionalität. Meiner Erfahrung nach werden diese Fehler mit Vorrang behandelt. In diesem Fall ist es vermutlich nicht so, also lasse ich das Kästchen leer.

Unter „Steps to reproduce“ folgt eine kurze Anleitung, wie der Tester auf Xojo-Seite den Fehler reproduzieren kann.

Das „Expected Result“ beschreibt, was eigentlich passieren sollte – nämlich eine Funktion analog zur 32 Bit-Version, und unter „Actual Result“ fasse ich zusammen, was stattdessen passiert.

Sind mir Workarounds bekannt, füge ich diese in das entsprechende Textfeld ein.

Ein Klick auf das kleine grüne + erlaubt mir, das Demo-Projekt anzuhängen. Oftmals sind auch kleine Videos sinnvoll, insbesondere wenn die Nachricht kommt, dass der sich selbst so bezeichnende Hausmeister von Xojo – in der Regel kümmert sich ein Mitarbeiter um Neueingänge und gibt diese ggf. zur weiteren Überprüfung an die Ingenieure weiter – das Problem nicht rekonstruieren konnte.

Falls es nicht möglich war, das Problem in ein Demoprojekt zu verpacken, kann man auch sein vollständiges Projekt schicken und die Sichtbarkeit auf „Only me and Xojo“ reduzieren. Alle diese Projekte stehen dann automatisch unter einer Verschwiegenheitsvereinbarung und werden vertraulich behandelt.

Nun also nur noch ein Klick auf „Submit“, und der Bericht wird erstellt.

Dann werde ich gefragt, ob ich den Report sehen möchte. Das ergibt dann das folgende Bild:

BugReport ready.png

In der Seitenleiste und auch oben sehe ich die Berichtsnummer. Ich kann aber auch auf das Zahnradsymbol unten klicken und „Copy Sharing Link“ anwählen. Will ich z.B. im Forum auf meinen Report hinweisen, wird dann der Link via Paste-Befehl eingetragen.

Habe ich weitere Erkenntnisse zum Problem gewonnen oder möchte ich meinen Senf zu einem anderen Bugreport beisteuern, hilft dazu das Bleistift-Symbol.

Weitere Features

Unter dem Dashboard sehe ich den Zustand einiger meiner Fälle:

Report Dashboard.png

Die Rubrik „My Top Cases“ wiederum erlaubt mir, Punkte zu verteilen. Damit wird den Ingenieuren eine Gewichtung mitgeteilt – Fälle, die viele Punkte erhalten haben, stehen also weit oben auf der Wunschliste der Entwickler, erkennbar am Rang:

Pers.Top cases.png

Die Top 20 der Entwickler lässt sich unter „Library – Top Cases“ betrachten:

Top20.png

Interessant ist dann hier auch der Status: Das „Scheduled“ bei Punkt 6 etwa deutet darauf hin, dass in absehbarer Zeit die Kompilierung aus der Kommandozeile möglich sein wird – wobei der Fahrplan auch mal ein Jahr oder länger sein kann.

„Newest“ dürfte selbsterklärend sein – da steht gerade mein Report ganz oben mit dem Vermerk „needs Review“. Ist dieser passiert und gibt es etwa Nachfragen, erhalte ich eine E-Mail und finde die Nachfrage auch unter dem Dashboard.

„Recently active“ schließlich erlaubt mir einen Blick über die Schultern der Ingenieure. Hier sehe ich, was gerade angeschaut, behoben, nachgefragt, aufgrund Nichtreproduzierbarkeit oder weil es kein Fehler war geschlossen wurde und was womöglich einem schon bestehenden Fall zugeordnet wurde – dann steht da „Closed (Duplicate)“.

In diesem Sinn: Es würde mich freuen, wenn die kleine Anleitung es möglich macht, Xojo noch schneller zu einem noch besseren Produkt zu machen. Sollte es an den Englisch-Kenntnissen hapern: Sie wissen ja, wie Sie mich erreichen.

2 Gedanken zu “Richtig Fehler melden

  1. Hallo Ulrich,

    laut Murphys Gesetz „Jede Lösung bringt neue Probleme“, hast du die Grundlagen geschaffen, zukünftig die endeckten Fehler, an die Xojo Ingenieure weiter zu leiten. Du machst einen Super Job, vielen Dank dafür.

    Gefällt mir

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s