[All]
QualityCentral 共通ユーザーガイド
By: Tomohiro Takahashi
Abstract: このQualityCentralの概要を読まれた後に、クライアント別のユーザーガイドをお読みください。
このドキュメントについて問題を発見した場合には、QualityCentralプロジェクトの[Documentation]-[User Guide]エリアに報告してください。
QualityCentral (QC)は、Embarcaderoの製品やサービスの品質に関する問題の解決や明確化、および追跡を行うためのコミュニティプロセスを提供します。Embarcadero Developer Network (EDN)のメンバーの方は、不具合(バグ)報告/機能追加要求(提案)の作成、他の参加者の報告の閲覧、また特に重要と思われる報告に対しコメントや投票を行うことができます。Embarcaderoの社員もQualityCentralに参加しており、常にEmbarcaderoのユーザーとEmbarcadero製品の開発チームとの間の橋渡しを行っています。
クライアント別ユーザーガイド
Microsoft® Windows向けクライアントのユーザーガイドはこちらです。
Javaベースのクライアントのユーザーガイドはこちらです。
QualityCentralを使う
QualityCentralクライアントを使用するには、予めEDNのユーザーアカウントを作成する必要があります。https://members.embarcadero.com/jp にてアカウントを作成するか、既にアカウントをお持ちであればログインしてください。
EDNのメンバーシップは無料で、QualityCentralも含め、Embarcadero Developer Networkが提供するサービスにアクセスすることができます。
コミュニティプロセス
QuliatyCentralは、コミュニティのメンバーの方々が報告に対する重み付けやコメント、および投票を行うことができる、お互いに協力する仕組みを提供します。QualityCentralによって、Embarcaderoがお客様からのリクエストに優先順位を付ける際に、コミュニティは大きな影響力を持ちます。
QCにはワークフロープロセスがあり、QCに報告された問題の明確化/分類/検証を行う際Embarcaderoを手助けしていだけるユーザーには階層も設けています。これらのユーザーの協力によりEmbarcaderoは、間違って報告されたものを削除したり、Embarcaderoコミュニティのメンバーの方やお客様から報告された問題をより明確にすることができます。
Level 0
すべてのコミュニティメンバーの方は Level 0 のQualityCentralユーザーです。Level 0 のユーザーの方は、以下のことを行えます。
- 自分で登録した報告に対して
- すべての報告に対して
- 報告の重み付け
- 報告への投票
- 報告の追跡
- 報告へのコメントや、コメンに対する返答
- 報告に関するワークアラウンド(回避策)の登録
- 検索
Level 1
Level 1 のユーザーは、シスオペとしての最初のレベルです。Level 1 のユーザーは、Level 0 のユーザーが行えることに加えて以下のことが行えます。
- 報告を再分類する
- ワークアラウンド(回避策)を承認する
- コメントを管理する
- エスカレート(”Needs Attention”を設定)を行う
Level 2
Level 2 では、Level 1 の権限に加えて以下のことが行えます。
- 正式な不具合として報告を検証する
- マイグレーションのために、報告に ”official status” を設定する
- ユーザーを Level 1 に昇格させる
Level 3
Level 3 のユーザーは、Level 2 のユーザーが行えることに加えて以下のことが行えます。
- Embarcaderoの正式なデータベースにある不具合報告をQualityCentralに登録する
- ユーザーを Level 2 に昇格させる
Webサービスの機能
QCのWebサービスは、QualityCentralのリポジトリに関するあらゆる機能を提供します。QualityCentralのWebサービスでは、すべてのインターフェースがドキュメント化されています。いくつかのメソッドを利用するには、より上位レベルのユーザーのアクセス権限が必要です。QCのWebサービスのインターフェースはこちらで参照できます。
QCを効果的に利用する
QCは、”適切に”使用することで効果的に活用できます。このセクションでは、不具合報告を投稿したり、機能追加要求や提案を作成したり、実際にそれらの不具合/機能/提案に取り組めるようにするための、効果的なテクニックを記述します。Embarcaderoに懸案事項を解決させるためにQCを使用しますので、このセクションではQualityCentralを使って前向きで大きな影響を与えるための様々な方法を記述します。
不具合を報告する
多くの方々にとって、QCで最初に興味を持つのは不具合報告でしょう。このセクションで議論する原則は、不具合報告を効果的に作成/処理するための明白かつ上手な方法です。
具体的に報告する
効果的な不具合報告を作成してください。不具合と発生する内容を記述する際には、できるだけ完全なものにしてください。手順を含めてください。最も効率良く不具合を修正する方法は、再現可能なテストケースを提供することです。もし簡単に再現できない場合には、その不具合に遭遇する前に何を行ったのかをできるだけ完全に記述してください。
分けて報告する
別の結論が導き出されると考える場合には、既存の報告へのコメントとして入力するのではなく、新規の報告として登録してください。これにより、確実にその問題を追跡し、結果的に(あなたの関心事について)取り組めるようになります。
不具合報告のテクニックを調べる
以下のリストは、Web上で見つけることのできる、様々な不具合報告ツールのためのサンプルページです。そこで提供されている情報や例すべてが役立つわけではありませんが、一般的には、QCを効果的に利用し、Embarcaderoが懸案事項に取り組むのに役立つ、良いプラクティスが議論されています。
提案をする
議論について
重複している報告について理解する
重複している報告は、シスオペによって”duplicate”の印が付けられています。どの報告が”master”、どの報告が”duplicate”なのかは、それらの報告で議論している問題についてどの報告が最も正確に詳細な情報を記述しているかに基づきます。”master”の報告は、誰かが別の報告を登録するにつれて変更されることも有り得ますが、このような重複は実際には問題をより良く説明することになるでしょう。”master”や”duplicate”は、誰が最初に作成したのかとは関係無く、どの報告が最も正確に問題をカバーしているかに関係しています。
すべての”duplicate”な報告は、”master”報告と同じステータスを共有します。ですので、その報告のステータスを確認するために、実際の”master”報告を参照する必要はありません。”master”報告のステータスがOpen/Close/Fixed等に設定された場合、すべての”duplicate”な報告にも同じステータスが設定されます。
”duplicate”への得票はすべて、自動的に”master”報告の得票として集計されます。ですので、最終的に”duplicate”の印が付けられてしまったものに対して投票したからといって、その投票が無視されたり失われたりすることを心配する必要はありません。
”duplicate”なレコード(報告)が残されたままになっているのは、”完璧なmaster”報告というものは無く、また”duplicate”な報告がその問題をより良く説明するための貴重な情報を提供しているかもしれないからです。いったん報告が”duplicate”と印付けられると、それを削除出来なくなります。その報告を分類したり、他の方々にとっては依然として価値があるかもしれないからです。
もし誰かが報告に”duplicate”の印を付けたり、コメントした場合などには、その作業は捨てられることはありません。シスオペのみがその項目を完全に削除する権限を持っており、その権限は極めて特殊なケースでのみ使用されます。
QCの各フィールドの見方
QualityCentralは、Embarcadero内部のシステムと同期されているので、いくつかのフィールドは内部システム向けで、内部システムの外では明らかな意味を持たないかもしれません。次の表は、それらの同期されるフィールドの値を説明しています。
Statusフィールド |
値 |
説明 |
Open |
オープンされた欠陥、解決が必要 |
Resolved |
解決された欠陥、検証が必要 |
Pending |
さらなる詳しい情報/手順が必要 |
Closed |
クローズされた欠陥、作業の必要無し |
Reported |
新規の欠陥、テスターによるレビューが必要 |
Withdrawn |
報告は提出者によって取り下げられた |
|
|
報告は、”Reported”ステータスからスタートします。その報告がシスオペによってEmbarcaderoの内部的なバグトラッキングシステムに昇格された場合には、そのステータスは”Reported”から”Open”に変わります。その報告に対する作業が完了した場合には、そのステータスは”Open”から”Closed”に変わります。
”Withdrawn”ステータスは、報告の作成者がそれを妥当では無いと判断して取り下げた場合に使用されます。
Verificationフィールド |
値 |
説明 |
Verified |
解決し検証された |
Not Resolved |
解決されていないと判断された |
Closed |
不具合を解決済みの製品が出荷された |
Reopened |
欠陥報告が再度オープンされた |
Disputed |
QAが解決策を議論している |
|
|
QCで最もよく見られる3つのVerificationステータスは、新しい報告については”空白”、クローズされた報告については”Closed”、クローズされたがまだ修正すべき問題があるために再度オープンされた報告については”Reopened”です。
Resolutionフィールド |
値 |
説明 |
Fixed |
不具合が修正された |
Deferred to Next MS |
不具合は、次のマイルストーンに延期された |
Cannot Reproduce Bug |
不具合は、報告にあるように再現できなかった |
As Designed |
動作は仕様です |
Duplicate Bug |
不具合は重複している(重複した不具合Noを示す必要がある) |
Test Case Error |
登録された不具合の説明が妥当ではない |
Need More Info |
より詳しい情報/デモ/手順が必要 |
Deferred to Next Release |
不具合は、次の製品リリースに延期された |
Retest |
現在のビルドで再テストしてください |
Checked In |
配布される予定 |
Third Party |
サードパーティの問題 |
Cannot Fix |
修正出来ない(ベンダーの問題) |
Defer to Inline |
インラインによるリリースで修正する |
Readme |
Readmeへの記述 |
Feature Removed |
この不具合はもはや意味が無い |
Web Update |
RTM後、Webアップデートで修正する |
Won't Do |
この問題は実装/修正されない |
Inactive |
欠陥は非活性化された |
|
|
”Inactive”を除き、ほとんどの”Resolution”の値は自明です。
”Inactive”な報告とは、現在お客様が問題に直面していない限り、R&DやQAが調査に時間を費やさないでおくため”Inactive”と印付けられた欠陥のことを言います。一般的に、これらは製品の旧バージョンについて報告されたものです。
”Needs More Info”または”Cannot Reproduce”として返された問題においては、シスオペやコミュニティのメンバーの方が追加情報を添えてコメントを追加できるよう、そのステータスは”Pending”の印が付けられます。一般的に、Embarcaderoが再現困難な問題の調査が行えるよう、連絡先や必要な情報/手順の説明を提供します。
もしQCのユーザーが、現在依然として「問題あり」と認識している事項が”Inactive”とされていることを知った場合には、QC/R&Dに対して再度オープンしてレビューするよう働きかけることが推奨されます。もしその報告の所有者であればその報告を自分でオープンすることもできますし、そうでなくとも代わりに Level 2 のシスオペがオープンしなければなりません。
Connect with Us