RAD Studio Quality Portal 2022 – Benutzerhandbuch

Das Qualitätsportal von Embarcadero bietet einen Community-Prozess zum Lösen, Klären und Nachverfolgen von Qualitätsproblemen in Bezug auf die Produkte und Dienstleistungen von Embarcadero. Embarcadero-Kunden mit einem EDN-Konto können Fehlerberichte und Funktionsanfragen erstellen, die Berichte anderer Kunden anzeigen und die für sie wichtigsten Berichte kommentieren und abstimmen. Mitarbeiter von Embarcadero beteiligen sich auch am Qualitätsportal, das eine permanente Verbindung zwischen Embarcadero-Kunden und den Teams herstellt, die die Produkte von Embarcadero herstellen.

Entwickler, die einen aktiven Support- und Wartungsvertrag haben und eine dringende Antwort auf eine Anfrage benötigen, sollten stattdessen ein Support-Ticket erstellen: Ein Quality Portal-Datensatz ist nicht dasselbe wie ein Support-Ticket.

Dieser Leitfaden soll Ihnen dabei helfen, Probleme mit dem Produkt RAD Studio , einschließlich Delphi und C++Builder , zu melden . Dieser Blogpost aktualisiert und ersetzt den Post unter https://blogs.embarcadero.com/rad-studio-quality-portal-user-guide/

Verwendung des Qualitätsportals von Embarcadero

Bevor Sie Quality Portal (QP) verwenden, müssen Sie Ihr EDN-Benutzerkonto erstellen (EDN steht für Embarcadero Developers Network). Gehen Sie zu https://my.embarcadero.com , um Ihr Konto zu erstellen, falls Sie noch kein Konto haben. Dies ist dasselbe Konto, mit dem Sie ein Embarcadero-Produkt registrieren können.

Gehen Sie mit Ihrem Konto zu https://quality.embarcadero.com/ und melden Sie sich beim Quality Portal (oder QP) an.

Gemeinschaftsprozess

Quality Portal ist eine Peer-unterstützte Anwendung, in der andere Mitglieder der Community vorhandene Berichte kommentieren oder abstimmen oder eigene erstellen können. Mit Quality Portal hat die Community einen großen Einfluss darauf, Embarcadero dabei zu helfen, die Anfragen unserer Kunden zu priorisieren. Sie können die Probleme anderer Benutzer „beobachten“, um benachrichtigt zu werden, wenn sie aktualisiert werden.

Ich habe oben bereits erwähnt, aber es lohnt sich zu wiederholen, dass Embarcadero auch ein technisches Support-Programm anbietet, das Sie online unter https://www.embarcadero.com/support erreichen können , einschließlich Installations- und Registrierungsunterstützung sowie eine Reihe von technischen Support-Tickets ( abhängig von Ihrem Support-Level). Wenn Sie sofortige Aufmerksamkeit für ein Problem wünschen, verwenden Sie bitte den Embarcadero-Support und nicht das Qualitätsportal.

Maximieren Sie die Vorteile Ihres Quality Portals

Sie können den größten Nutzen aus QP ziehen, wenn Sie es „richtig“ verwenden. In diesem Abschnitt des Benutzerhandbuchs werden effektive Techniken zum Veröffentlichen von Fehlerberichten, zum Stellen von Funktionsanfragen und -vorschlägen und zum tatsächlichen Erarbeiten der Fehler, Funktionen und Vorschläge beschrieben. Schließlich verwenden Sie QP, weil Sie möchten, dass Embarcadero Probleme angeht, die Ihnen wichtig sind. In diesem Abschnitt des Benutzerhandbuchs werden die verschiedenen Möglichkeiten beschrieben, wie Sie Ihre positiven Auswirkungen mit Quality Portal maximieren können.

Anleitung zum Melden von Fehlern

Für viele Leute werden Fehlerberichte das anfängliche Interesse an QP sein. Die in diesem Abschnitt besprochenen Prinzipien behandeln sowohl offensichtliche als auch subtile Möglichkeiten, Fehlerberichte effektiv zu erstellen und zu verarbeiten.

Sie sehen ein ähnliches Formular wie:

Sei präzise

Schreiben Sie effektive Fehlerberichte. Seien Sie so vollständig wie möglich, wenn Sie den Fehler beschreiben und was passiert. Schritte einbeziehen. Der effizienteste Weg, einen Fehler zu beheben, besteht darin, einen reproduzierbaren Testfall bereitzustellen. Wenn Sie es nicht ohne weiteres reproduzieren können, beschreiben Sie so vollständig wie möglich, was passiert ist, bevor Sie den Fehler gesehen haben. Fehlerberichte müssen alle erforderlichen Informationen an einem Ort bereitstellen . Falls Sie einen reproduzierbaren Testfall haben, aber den Code aus irgendeinem Grund nicht im öffentlichen QP-System teilen möchten, können wir einen direkten und privateren Einreichungsprozess arrangieren: Bitte geben Sie dies im Bericht selbst an. Beachten Sie auch, dass es für einige Produktbereiche wie CodeInsight und FireDAC spezifische Schritte gibt, um uns Protokollinformationen bereitzustellen, wie im Abschnitt mit Tipps am Ende dieses Blogbeitrags erläutert.

Goldene Regel: Nehmen Sie in jeden Bericht nur ein Problem auf.

Problemtyp

• Fehler: Ein Problem mit dem Produkt
• Dokumentationsfehler: Ein Problem mit Hilfe oder Produktdokumentation.
• Funktionsanfrage: Eine neue Funktion, die Sie gerne in dem Produkt sehen würden

Beachten Sie, dass Funktionsanfragen einem anderen Weg folgen: Sie werden von Produktmanagern (und nicht vom QA-Team) geprüft und Entwicklern zur Recherche oder Implementierung in einer zukünftigen Version zugewiesen.

Gelegentlich wandeln wir ein Problem von einem Typ in einen anderen um, z. B. wenn ein Fehlerbericht wirklich adressiert werden kann, indem dem Produkt eine wichtige Funktion hinzugefügt wird, oder im Falle einer falschen Einreichung durch den Kunden.

Zusammenfassung

Geben Sie dem Bericht eine kurze, aber aussagekräftige Zusammenfassung. „TButton funktioniert nicht“ ist kein guter Titel, aber „[Android] Ein Fehler wird ausgelöst, wenn TButton durch doppeltes Tippen aufgerufen wird“ ist besser.

Verwenden Sie gegebenenfalls Tags im Titel, damit der Leser den Kontext besser versteht.

Eine gute Zusammenfassung hilft dabei, schnell zu erkennen, was vor sich geht, und doppelte Probleme zu vermeiden. Vermeiden Sie es, allgemeine Probleme in der Zusammenfassung zu beschreiben. Sie sollten niemals verwenden:

• Ich habe ein Problem mit XYZ
• XYZ funktioniert nicht richtig

Ein paar Beispiele für schlechte Zusammenfassungen und ihre guten Äquivalente:

Schlecht:  Zugriffsverletzung in IDE

Besser:  Das Öffnen einer leeren .pas-Datei löst eine Zugriffsverletzung aus

Schlecht:  Push-Benachrichtigungsfehler

Besser:  Die Anzahl der Push-Benachrichtigungen fügt eine zusätzliche Benachrichtigung hinzu

Komponente

Identifizieren Sie, welcher Teil der Software von diesem Fehler betroffen ist.

• Installieren
• Feueraffe
• VCL
• C++-Compiler (siehe C++-Compiler/Linker-Fehlermeldungen)
• C++-RTL
• Delphi-Compiler
• Delphi RTL
• Linker (siehe C++ Compiler / Linker Bug Submitting Hints)
• Datenbank
• Debugger
• IDE (Entwicklungsumgebung)
• Hilfe und Dok
• Demos

Beschreibung

Alle durch das Problem generierten Informationen. Wenn verfügbar, fügen Sie Folgendes hinzu:

• Vollständige Fehlermeldung
• Voller Call-Stack
• Wenn Sie es für relevant halten, fügen Sie Informationen zu Ihrer Umgebung hinzu (z. B. Android-Version oder Windows-Gebietsschemaeinstellungen).
• Für Fehler, die sich visuell manifestieren (z. B. werden Steuerelemente nicht richtig angezeigt oder Probleme mit dem IDE-Layout), fügen Sie einen Screenshot bei, um jedem, der Ihren Bericht liest, zu helfen, ihn zu bewerten.
• Fügen Sie bei Bedarf Geräteprotokolle hinzu, z. B. logcat-Ausgabe für Android.
• Verwenden Sie für Fehlermeldungen oder Call-Stacks entweder {code}- oder {quote}-Tags.
• Wenn Sie Ihren Bericht auf eine externe Informationsquelle stützen (z. B. MSDN-Seite für einen API-Aufruf), fügen Sie einen Link zu diesen Informationen ein
• Wenn Ihr Fehlerbericht Code enthält, hängen Sie ihn entweder an das Projekt an oder fügen Sie ihn dem  Abschnitt „ Schritte “ hinzu  . Wenn Sie Ihrem Bericht Code als Text hinzufügen, stellen Sie sicher, dass Sie {code}-Tags verwenden. Dies hält JIRA davon ab, Ihren Code zu interpretieren und ihn durcheinander zu bringen, und hilft auch bei der Lesbarkeit des Berichts (vermeidet, ein paar Seiten zu scrollen, um zu relevanten Feldern zu gelangen).
• Beschränken Sie die Größe des Anhangs auf das Minimum. Komprimieren Sie Ihre Dateien und schließen Sie niemals Binärdateien ein, die durch Kompilieren generiert werden (z. B. DCUs oder EXEs). Verwenden Sie nur das ZIP-Format, verwenden Sie niemals andere Formate, die ein Drittanbieterprogramm erfordern.
• Fügen Sie nicht mehr als ein Problem in einen Bericht ein. Berichten Sie separat und verknüpfen Sie sich nach Bedarf.

Schritte

Ziel ist es, zu zeigen, wie der Fehler reproduziert werden kann. Halten Sie es kurz und einfach zu lesen, Sie sollten es als Rezept beschreiben, um den Fehler zu reproduzieren. Versuchen Sie, das Ziel mit der minimalen Anzahl von Schritten zu erreichen.

Hinweis: Fehlermeldungen oder Aufruflisten gehören in die Beschreibung, nicht in die Schritte. Die Beschreibung sollte beispielsweise lauten: „Der folgende Fehler wird beim Aufrufen von TButton durch Doppeltippen auf meinem Android-Gerät ausgelöst: [Fehlermeldung]“, und die Schritte sollten nur Anweisungen zum Reproduzieren des Problems enthalten.

Erwartete und tatsächliche Ergebnisse

Am Ende Ihrer Schritt-für-Schritt-Beschreibung müssen Sie beschreiben, was das erwartete Ergebnis sein soll und was tatsächlich passiert.

Beispiel für eine  schlechte Beschreibung:

Erwartet: Die Anwendung stürzt nicht ab

Tatsächlich: Anwendung stürzt ab

Besser verwenden:

Erwartet: Die Anwendung zeigt das XYZ-Menü an

Tatsächlich: Die Anwendung löst eine Zugriffsverletzung aus (siehe beigefügten Stack-Trace)

Berichte isolieren

Seien Sie gewissenhaft, wenn Sie Folgegedanken als  neue Berichte einreichen, und nicht nur als Kommentare zu einem bestehenden Bericht. Dadurch wird sichergestellt, dass das Problem nachverfolgt und schließlich bearbeitet wird.

Doppelte Berichte verstehen

Ein „duplizierter“ Bericht wird vom QA-Team als solcher gekennzeichnet. Welcher Bericht als „Master“ und welcher als „Duplikat“ gekennzeichnet ist, basiert darauf, welcher Bericht die genauesten und detailliertesten Informationen liefert, die das Problem beschreiben, das in beiden (oder vielen) Berichten erörtert wird.

Der Hauptbericht kann sich im Laufe der Zeit ändern, wenn jemand anderes ein weiteres Duplikat einreicht, aber dieses Duplikat beschreibt das Problem tatsächlich besser. „Master“ und „Duplikat“ haben nichts damit zu tun, wer zuerst eingestiegen ist, sondern welcher Bericht das Problem am genauesten abdeckt.

Typischerweise hat ein „Duplikat“-Problem den Status „Gelöst“, eine „Duplikat“-Lösung und ist mit dem „Master“-Problem mit einem „Duplikat“-Link verknüpft. Sie müssen den Status überprüfen und Aktualisierungen der „Master“-Ausgabe beobachten.

Wie man einige der Felder in QP interpretiert

Da Quality Portal mit internen Systemen synchronisiert wird, gibt es einige Felder, die für unsere internen Prozesse von Bedeutung sind und außerhalb unserer internen Prozesse möglicherweise keine offensichtliche Bedeutung haben. Die folgenden Tabellen erläutern hoffentlich einige der Werte für diese synchronisierten Felder.

Statusfeld

Ein Bericht beginnt mit dem Status „Gemeldet“. Wenn ein QA-Tester von Embarcadero es im internen Fehlerverfolgungssystem von Embarcadero validiert, wechselt der Status von „Gemeldet“ zu „Offen“. Wenn die Arbeit mit dem Bericht abgeschlossen ist und der Fix Teil eines freigegebenen Produkts ist, wechselt der Status von „Offen“ zu „Gelöst“. Beachten Sie, dass ein Problem nur dann als behoben markiert wird, wenn der Fix verfügbar ist, nicht wenn er intern von R&D implementiert wird.

Auflösungsfeld

Für Probleme, die mit Needs More Info zurückgegeben werden, wird der Status als „ Feedback erforderlich “ markiert, damit der Melder zusätzliche Informationen hinzufügen kann. Sie müssen die Schaltfläche „ Inhalt aktualisieren “ verwenden, wenn Sie zusätzliche Informationen übermitteln. Sobald Änderungen über „Inhalt aktualisieren“ eingereicht wurden, wechselt der Status wieder auf „Gemeldet“ und das QA-Team wiederholt die Validierung intern. „ Inhalt aktualisieren“ kann auch verwendet werden, wenn Korrekturen an einem bereits eingereichten Problem vorgenommen werden.

Versuchen Sie im Allgemeinen, die Beschreibung zu verdeutlichen, indem Sie weitere Details und/oder Kontextinformationen hinzufügen, indem Sie die oben angegebenen Empfehlungen verwenden, oder Schritte zum Reproduzieren hinzufügen/überprüfen. Das Anhängen von Screenshots und/oder Projekten wäre ebenfalls hilfreich. Auch ein kurzes und fokussiertes Video kann gut verständlich sein.

Noch ein paar Tipps

Bei Problemen im Zusammenhang mit der CodeInsight LSP-Engine lesen Sie bitte die Informationen am Ende dieses docWiki-Artikels . Beachten Sie, dass die LSP-Protokolle erhebliche Teile des zu analysierenden Quellcodes enthalten können. Wenn es also Gründe gibt, sie reserviert zu halten, fragen Sie bitte nach einem direkten Kommunikationskanal, anstatt die Protokolldatei einem öffentlichen QP-Bericht hinzuzufügen.

Wenn Sie FireDAC-Probleme melden, sollten Sie in ähnlicher Weise Umgebungsdaten und Ablaufverfolgungsprotokolle bereitstellen. Die Schritte werden in diesem Artikel behandelt .

Sie können auf die QP-Textformatierungstipps des Originalartikels unter https://blogs.embarcadero.com/rad-studio-quality-portal-user-guide/#Hints_and_Tips verweisen

Schließlich ist eine gute Quelle für Empfehlungen zum Melden von Fehlern unter http://www.mozilla.org/bugs/bug-reporting.html verfügbar