このブログはRAD Studio Quality Portal 2022 User Guideの抄訳です

Embarcadero Quality Portalは、エンバカデロの製品やサービスに関する品質問題を解決、明確化、追跡するためのコミュニティプロセスを提供します。(一般的には、バグトラッキング(管理)システムとも呼ばれています)

EDNアカウントをお持ちのお客様は、バグレポートや機能リクエストの作成、他のお客様のバグレポートの閲覧、お客様にとって最もインパクトの大きい、あるいは重要と考えるレポートに対してコメントや投票を行うことができます。またEmbarcaderoのスタッフもQuality Portalに参加しており、お客様とEmbarcaderoのスタッフや製品開発チームとの間に恒久的なリンクを提供しています。

アップデートサブスクリプションが有効なお客様で、Delphi/C++Builderを含むRAD Studio 製品に関する問い合わせが必要な場合は、Embarcaderoのサポートチームへお問合せください。Quality Portalへレポートを投稿しても、直接サポートを受けられるわけではございませんので、どうかその点は区別してご理解ください。

Embarcadero Quality Portalの使用方法

Quality Portalを利用するためには、EDNユーザーアカウントを作成する必要があります（EDNはEmbarcadero Developers Networkの略です）。もしEDNアカウントをお持ちでない場合は、こちらのサポート情報をご参考いただき、EDNアカウントを作成してください。このアカウントは、Embarcadero 製品の登録に使用できるアカウントと同じです。

Quality Portalを利用するには、https://quality.embarcadero.com/のURLヘアクセスしてください。

そしてEDNアカウントを入力することでログインすることができます。(Quality Portalへのログインには、EDNアカウントのユーザー名を入力してください)

コミュニティ プロセス

Quality Portalはピアサポート型のアプリケーションで、他のコミュニティメンバーの既存のレポートに対してコメントや投票を行ったり、お客様自身で独自のレポートを作成したりすることができます。Quality Portalでは、コミュニティがEmbarcaderoのお客様からのリクエストの優先順位付けに大きな影響を及ぼします。他のユーザーの課題を「Watch」することで、その課題が更新されたときに通知を受けることができます。

上述しましたが、Embarcaderoはテクニカルサポートプログラムも提供しており、インストールや使用許諾(ライセンス)に関するサポートおよび技術的なサポートが利用できます。

問題をすぐに解決したい場合は、Quality Portal ではなくEmbarcaderoのサポートプログラムをご利用ください。

Quality Portalのメリットを最大限に活用するには?

Quality Portalを「適切」に利用することで、お客様はQuality Portalから最大の恩恵を受けることができます。お客様がQuality Portalを利用する目的は、自分にとって重要な問題をEmbarcaderoによって対処することを望まれているためだと思います。

そのためには、Embarcaderoへより正確な情報が伝わるように適切かつ明確なレポート内容であることが不可欠です。

このユーザーガイドでは、お客様によるバグレポートの投稿、機能要求や提案、そして実際にバグや機能、提案に取り組んでいただくための効果的なテクニックを説明しています。

バグレポートを行う方法

多くの人にとってQuality Portaに対する最初の関心はバグレポートだと思います。

このセクションでは、バグレポートを効果的に作成および処理するための方法について説明いたします。

バグレポートの説明は、より具体的に

効果的なバグレポートを書くには、バグの内容と実際にどういった症状が発生しているのか、できるだけ完全な再現手順を含んでいることが重要です。バグの内容をより明確にし、修正させる最も効率的な方法は、 再現可能なテストケースを提供することです。もし容易に再現できない場合は、バグが発生する前に何が起こっていたかをできるだけ詳しく説明してください。

バグレポートは、必要な情報をすべて一度に提供する必要があります。また再現可能なテストケースの用意はあるが、お客様のご事情によってパブリックなQuality Portalシステム内でコードを共有したくないケースもあります。その場合は、バグレポート内にその旨をご記入いただければ、Embarcaderoへプライベートな提出プロセスで送付することもできます。

なお、CodeInsight や FireDAC などの一部の製品分野では、このブログの最後にあるヒント セクションで説明されているように、ログ情報を提供するための特定の手順があることにも注意してください。

重要なルール：各レポートに含める課題は1つだけにしてください。絶対に1つのレポート( ケース)に複数の課題は記述しないでください。

Quality Portal内で「Create」というボタンを押すと、下図のようにQuality Portalの投稿フォームが表示されます。各項目名にある赤アスタリスクは必須項目を意味します。

Quality Portalの投稿フォームにあるConfigure Fieldsを選択することにより、入力項目の表示・非表示を設定することができます。下図は、入力項目をすべて表示した状態です

では、投稿フォームで入力すべきそれぞれの項目について見ていきましょう。

(1) Project

報告を行う製品を選択します。(ここでは、RAD Studio (RSP)を選択してください。)

(2) Issue Type

• Bug：製品の不具合に関する問題
• Documentation bug: ヘルプや製品のドキュメントの不具合に関する問題
• New Featuret:  製品の将来のリリースで実装して欲しい新しい機能

New  Feature は、Bugとは異なり、別の経路をたどることに注意してください。この課題はQAチームではなく、製品のプロダクトマネージャーによって吟味/精査され、将来のリリースでの研究または実装のためにEmbarcadero開発チームに割り当てられます。

なお、投稿いただいたバグレポートの内容をエンバカデロのスタッフが確認し、もしそのレポート内容が適切なIssue Typeではない場合は、別のタイプに変更することがあります。(例えば、お客様による誤ったレポートの報告や、製品に重要な機能を実装することで報告されたバグが解決できる場合など)

(3) Summary

バグレポートのSummaryの項目には、できるだけ簡潔、かつ説明的な要約文を記述してください。

例えば、「TButtonが動作しない」というタイトルは抽象的で、必要な情報が十分に含まれていないため適切ではありません。これを「[Android] TButtonをダブルタップで呼び出すとエラーが発生する」のように記述することで、より具体的で、どういう状況で発生するエラーなのか理解できるため、適切なタイトルとなります。

必要に応じてタイトルにタグを使用して、このレポートを読む人が文脈をより理解できるようにしましょう。

良いSummary(タイトル)の文章は、何が起こっているのかを迅速に特定でき、同じレポートが重複する問題を減らすことができます。

Summaryには、一般的な問題を記述することは避けましょう。

以下は、非常に漠然とした誤った記述例です。

• XYZに問題がある
• XYZが正しく動作しない

悪いSummary文の例と、それを少し改良した例をいくつか挙げてみましょう。

悪い例: IDEでアクセス違反が発生する

修正例:  空の .pas ファイルを開くとアクセス違反が発生する

悪い例: プッシュ通知バグ

修正例: プッシュ通知の回数が1回追加される

(4) Component

Componentの項目では、このバグの影響を受けるのは、ソフトウェアのどの部分に該当するのか、そのカテゴリを選択します。

• Install
• FireMonkey
• VCL
• C++ Compiler (see C++ Compiler / Linker bug submitting hints)
• C++ RTL
• Delphi Compiler
• Delphi RTL
• Linker (see C++ Compiler / Linker bug submitting hints)
• Database
• Debugger
• IDE (Development Environment)
• Help and Doc
• Demos

(5) Affects Version/s

報告を行う製品のバージョンを選択します。(例えば、 11.2 Alexandria)

(6) Build No

報告を行う製品のビルド番号を入力します。ビルド番号は、IDEメニューの[ヘルプ]-[バージョン情報]画面でビルド番号(バージョン)を確認することができます。(例えば、28.0.46141.0937 )

(7) Language Version

報告を行う製品の言語を選択します。(例えば、Japanese L10N)

(8) Edition

報告を行う製品のエディションを選択します。(例えば、Professional)

(9) Description

Descriptionの項目には、バグレポートとして報告すべき情報を記述してください。

(Quality Portalへのレポートは、日本語での報告は可能ですが、お客様のレポートを日本以外の他のお客様と共有できるようにするため、日本語ではなく英語で記述いただくことを推奨いたします)

以下で挙げられている項目は、発生している症状をより明確に、あるいはレポートを見やすくするための情報で、バグレポートとして報告する上で必要な簡単なガイドラインとなります。

• 全てのエラーメッセージの情報
• 全てのコールスタックの情報
• もし関連性がある場合は、お客様がご利用の開発/実行環境に関する情報（例：AndroidのバージョンやWindowsのロケール設定など）を含めてください。
• 視覚的に再現するバグ（例：コントロールが正しく表示されない、IDEレイアウトの問題）については、レポートを見た人が評価しやすいようにスクリーン(画面)ショットを添付してください。
• 必要に応じて、Androidのlogcat出力のようなデバイスログも添付してください。
• エラーメッセージやコールスタックには、{code}タグまたは{quote}タグを使用してください。
• 外部からのソース情報（例えば、APIコールに関するMSDNページなど）をベースにレポートを作成する場合は、その情報へのリンクを含めてください。
• バグレポートにコードが含まれている場合、再現するプロジェクトを添付するか、Stepsセクションに追加してください。レポート内でコードを記述する際は、読みやすくするために必ず {code} タグを使用してください。
• レポートに添付するファイルのサイズは最小限に留めてください。ファイルをZIPで圧縮し、コンパイルして生成されたバイナリ（例：DCUやEXE）は絶対に含めないでください。圧縮するファイルはZIP形式のみを使用し、解凍するためにサードパーティプログラムを必要とする他の圧縮形式は決して使用しないでください。
• 1つのバグレポートに複数の課題を記載しないでください。もし複数の課題がある場合は、それぞれ別々のバグレポートとして報告し、必要に応じて互いのケースをリンクさせてください。

上述した{code}タグに関する補足となりますが、以下は{code}タグを使用している場合と使用していない場合を比較した例です。

コードを記述する際、{code}タグで括っていない場合:

コードを記述する際、{code}タグで括っている場合:

上記の比較例をご覧いただくとその違いは明白ですが、コードを記述する際に{code}タグで括っていると、コードがハイライトされたり、インデントがつくため、コードがより見やすくなります。なお、{code}タグはメニューバーの「コードスニペットを追加または更新」より挿入することができ、{quote}タグは段落の書式メニューより指定することも可能です。

(10) Steps

Stepsの項目には、バグを再現する手順や方法を記載します。

(Quality Portalへのレポートは、日本語での報告は可能ですが、お客様のレポートを日本以外の他のお客様と共有できるようにするため、日本語ではなく英語で記述いただくことを推奨いたします)

Stepsは簡潔で読みやすく、バグを再現するためのレシピのように記述してください。できるだけ最小限のステップ数で、バグの再現手順や方法が記載されていることが望ましいです。

注意：エラーメッセージやコールスタックは、Stepsの項目ではなく、Descriptionの項目に記載してください。

例えば、Descriptionには「AndroidデバイスでTButtonをダブルタップして起動すると、次のエラーが発生します。[エラーメッセージ]」と記述し、Stepsには、その問題を再現する方法を記述してください。

実際に起こった症状と期待される結果

Stepsの説明の最後に、実際に起こった症状(Actual)と期待される結果(Expected)を記述してください。

説明が不十分な例:

Expected: アプリケーションがクラッシュしない

Actual: アプリケーションがクラッシュした

良い説明の例:

Expected:  アプリケーションが XYZ メニューを表示する

Actual: アプリケーションがアクセス違反を起こす（添付のスタックトレースを参照）

(11) Platform

このバグの影響を受けるプラットフォームを（複数選択可）選択します。 ( 例えば、Windows 11、Win 64-bitなど)

Isolate reports

意見を補足するときは、既存のバグレポートに対してコメントを入れるのではなく、新しいレポートを作成するように意識してください。これにより、問題が追跡され、最終的に対処されるようになります。

Duplicate Report（重複レポート）について

内容が重複しているレポートは、EmbarcaderoのQAチームによって「Duplicate」としてマークされます。 どのレポートが「マスター」としてマークされ、どのレポートが「重複」としてマークされているかの判断は、どちらのレポートが最も正確かつ詳細な情報を提供しているかによって決まります。

時間の経過と共に、もし他にもっと良いレポートが投稿されたときは、マスターレポートは変更されることがあります。ただし、今までマスターだったレポートは「Duplicate」としてマークされても、現在のマスターレポートの内容を補足する良い説明になります。

通常「Duplicate」としてマークされたレポートは、Resolutionは「Duplicate」として問題は解決されます。そして下図のようにIssue Linksの項目にマスターケースがリンクされています。バグレポートの報告者は自分のケースが「Duplicate」としてマークされてもリンク先のマスターケースの状況を監視することができます。

Quality Portalの一部のフィールドの説明について

Quality PortalはEmbarcadero内部のバグトラッキングシステムと同期(連動)しているため、内部プロセスにとって意味を持つフィールドでも、Quality Portalでは明確に意味を持たないフィードがあります。以下の表は、内部プロセスと同期される一部のフィールドの値と説明です。

Status フィールド

値	説明
Reported	新規ケースの問題で、テスター(QA)によるレビューが必要
Open	未解決なケース問題で、テスター(QA)によってレビューが開始された状態。エンバカデロ内部で処理している間は、このステータスのままです。
Resolved	問題が特定された状態で、不具合の修正はリリースされた製品に反映されています。報告者は問題が解決しているか検証、あるいは異議を唱えることができます。
Needs Feedback	問題を特定するための情報が不足している状態で、この状態の時は、ケースに対する追加情報や再現手順等の提出が必要
Closed	問題が解決し、ケースがクローズされた状態

バグレポートは、「Reported」というステータスで開始されます。EmbarcaderoのQAテスターによって社内のバグトラッキングシステムでレビューが開始されると、ステータスは「Reported」から「Open」に変更されます。報告されたケースの処理が完了し、その修正がリリースされた製品に反映されると、ステータスは「Open」から「Resolved」に変更されます。ただし「Resolved」と表示されるのは、修正プログラムがリリースされ、利用可能になった場合のみで、開発部門によって内部的に実装されたタイミングではないことに注意してください。

Resolution フィールド

値	説明
Fixed	不具合が修正済み
Cannot Reproduce	最新バージョンの製品で報告された不具合が再現されなかった
Works as Expected	報告された問題が規定の動作、または現行の仕様である
Duplicate	このケースは別のケースと重複 。重複したケース番号 (RSP-xxxxx)を参照ください。まだ未解決の可能性があります。
Test Case Error	報告された問題(不具合)の説明文が無効
Needs More Info	再現のための情報/デモ/手順が必要
No Longer Applies	機能が削除されている、または不具合の関連性を失っている
Won’t Fix	問題が修正できない、あるいは修正されない

「Needs More Info」になっているケースについては、報告者が情報を追加できるように、ステータスが「Needs Feedback」と表示されます。追加情報を提出する場合は、「Update Content」ボタンを押してください。「Update Content」によって提出された変更は、ステータスが「Reported」に戻り、Embarcadero内部のQAチームが再びレビューを行います。「Update Content」は、既に報告された問題に修正が加えられた場合にも使用されます。

効果的なバグレポートを書く方法は、上述した推奨事項を参考いただき、問題や不具合に関する詳細な症状の情報や再現手順を記載してください。症状の説明は文章だけではなく、発生している症状に関する画面ショットや動画、そして再現可能なプロジェクトを添付することも効果的です。 

ログとその他のヒント

CodeInsightのLSPエンジンに関する問題については、こちらのdocwikiの情報を参照してください。LSPログは解析されたソースコードの重要な部分を含んでいる可能性があるため、機密保持が必要な場合は、ログファイルをパブリックな QP レポートへ添付するのではなく、ログファイルをバグレポートのケース番号と一緒に、安全な電子メールアドレス [email protected] に非公開で送信できます。

同様に、FireDACの問題を報告する場合、環境データとトレースログを提供する必要があります。その手順については、こちらのdocwikiを参照ください。

またRAD Studio/C++Builder/Delphiのインストールに失敗した原因に関する追加情報を収集する方法として、こちらのdocwikiの情報のように GetItInstall.log ファイルの作成を有効にすることができます。インストールログはデフォルトで無効になっていますが、有効にすると GetItInstall.log ファイルからインストールに関する問題のトラブルシューティングに有用な情報を得ることができます。