live project bug tracking
これが私たちの「 ライブプロジェクトでのソフトウェアテストトレーニング 」シリーズ。
STLCのテスト実行フェーズの完了を示す欠陥と残りのいくつかのトピックについて説明します。
の中に 前の記事 、テストの実行中に、テストケースの期待される結果が満たされない状況が発生しました。また、探索的テスト中に予期しない動作を特定しました。
これらの逸脱に遭遇するとどうなりますか？
これらの逸脱が処理され、最終的にAUTで修正されることを確認するために、明らかにそれらを記録および追跡する必要があります。
＃1） これらの逸脱は、欠陥/バグ/問題/インシデント/エラー/障害と呼ばれます。
＃二） 以下のすべてのケースは欠陥としてログに記録できます
- 要件がありません
- 正しく機能しない要件
- 追加要件
- 参照ドキュメントの不整合
- 環境関連の問題
- 拡張の提案
＃3） 欠陥の記録は、ほとんどの場合、Excelシートで、または欠陥管理ソフトウェア/ツールを使用して行われます。ツールを介して欠陥を処理する方法については、次のリンクを使用してみてください。
- HP ALM
- アトラシアンJIRA
- また、のリストについては、この投稿を参照してください 最も人気のあるバグ追跡ツール 市場で。
学習内容：
欠陥を効果的に記録する方法
前回の記事で遭遇した欠陥をExcelシートに記録する方法を見てみましょう。いつものように、標準のフォーマットまたはテンプレートを選択することが重要です。
Team FoundationServerの使用方法
通常、次の列は欠陥レポートの一部です。
- 欠陥ID： 一意の識別用。
- 欠陥の説明： これは、問題を簡単に説明するタイトルのようなものです。
- AUTのモジュール/セクション： これはオプションであり、問題が発生したAUTの領域を示すために明確にするためです。
- 再現する手順： バグを再現するためにAUTで実行される操作の正確なシーケンスは、ここにリストされています。また、入力データが問題に固有である場合は、その情報も入力する必要があります。
- 重大度： 問題の強度と、最終的にはこれがAUTの機能に与える可能性のある影響を示すため。このフィールドで割り当てる方法と割り当てる値に関するガイドラインは、テスト計画ドキュメントに記載されています。だから、参照してください 第3条のテスト計画文書 。
- 状態： この記事でさらに説明します。
- スクリーンショット： エラーが発生したときにエラーを表示するためのアプリケーションのスナップショット。
これらは「必須」フィールドの一部です。このテンプレートは、拡張（たとえば、問題を報告したテスターの名前を含める）または縮小（たとえば、問題を報告したテスターの名前を含める）できます。 例えば、 必要に応じてモジュール名を削除）。
上記のガイドラインに従い、上記のテンプレートを使用すると、サンプルの欠陥ログ/レポートは次のようになります。
OrangeHRM Liveプロジェクトのサンプル欠陥レポート：
=> ライブプロジェクトの欠陥レポートをダウンロードするには、ここをクリックしてください
以下は、qTestテスト管理ツールで作成されたサンプルの欠陥レポートです。 （画像をクリックすると拡大します）
欠陥をログに記録して自分自身に保管する場合、欠陥は良くありません。関係するチームに行動を起こさせるには、正しい順序でそれらを割り当てる必要があります。プロセス–誰を割り当てるか、またはどの順序に従うかは、テスト計画ドキュメントにも記載されています。それはほとんどに似ています （画像をクリックすると拡大します）
欠陥サイクル：
上記のプロセスから、バグは特定されて修正される過程で、さまざまな人やさまざまな決定を経ることに注意できます。特定のバグがどのような状態にあるかを追跡し、透明性を確立するために、バグレポートで「ステータス」フィールドが使用されます。プロセス全体は「バグライフサイクル」と呼ばれます。すべてのステータスとその意味の詳細については、こちらを参照してください バグライフサイクルチュートリアル 。
バグ追跡中のいくつかのポインタ
- クリエイティブなチーム/プロジェクト/ AUTを初めて使用する場合は、常に次のことを行うのが最善です。 発生した問題について話し合う 同僚と協力して、欠陥の実際の原因についての理解が正しいかどうかを確認します。
- に すべての情報を提供する それは問題を再現するために必要です。ステータスが「情報が不十分」に設定された状態でテストチームに戻ってきた欠陥は、私たちにあまり積極的に反映されていません。この投稿をチェックしてください– 「無効なバグ」ラベルなしですべてのバグを解決する方法 。
- 新しい問題を作成する前に、同様の問題が発生したかどうかを確認してください。 「重複」の問題 QAチームにとっても悪いニュースです。
- 問題がある場合、それはランダムに発生し、問題を再現できる正確な手順/状況がわかりません。同じように問題を提起します。問題がに設定されるリスクがあります 「IrReproducible /不十分な情報」 –考えられるすべての誤動作を、可能な限り最大限に処理したことを確認する必要があります。
- 一般的な慣行 QAチームは、1日の間にエクセルシートに各自の欠陥を作成し、1日の終わりにそれを統合するということです。
完全な欠陥ライフサイクル
私たちのライブプロジェクトでは、欠陥1の欠陥ライフサイクルに従う場合
無料のシンプルなyoutubeからmp3へのコンバーター
- 私（テスター）が作成したときのステータスは 「」新着」。 QAチームリーダーに割り当てると、ステータスは「新規」のままですが、所有者がQAリードになります。
- QAリードが問題を確認し、それが有効な問題であると判断すると、その問題は開発リードに割り当てられます。このフェーズでは、ステータスは 「」割り当て済み「」 所有者は開発者のリーダーです。
- 次に、開発リーダーは、この問題の修正に取り組む開発者にこの問題を割り当てます。ステータスは次のようになります 「」進行中の作業「」 （またはその効果に似たもの）、所有者は開発者です。
- 欠陥1の場合、開発者はエラーを再現できないため、QAチームに割り当て、ステータスを次のように設定します。 「」再現できません」。
- または、開発者が問題に取り組み、問題を修正できた場合、ステータスは次のように設定されます。 「」解決しました「」 問題はQAチームに割り当てられます。
- QAチームはそれをピックアップし、問題を再テストし、修正された場合はステータスを次のように設定します。 「」閉まっている「」 。問題がまだ存在する場合、ステータスはに設定されます 「」再開する「」 プロセスは続行されます。
- 他の状況に応じて、ステータスは次のように設定できます。 「」延期「」 、「情報が足りない」、 「」複製「」 、 「」意図したとおりに機能する「」 、開発者によるなど。
- 欠陥を記録し、報告して割り当て、管理するこの方法は、テスト実行フェーズ中にQAチームメンバーによって実行される主要なアクティビティの1つです。これは、特定のテストサイクルが完了するまで、毎日行われます。
- サイクル1が完了すると、開発チームは1〜2日かけてすべての修正を統合し、次のサイクルで使用される次のバージョンにコードを再構築します。
- 同じプロセスがサイクル2でも続行されます。サイクルの終わりに、アプリケーションで「開く」または修正されていない問題がまだある可能性があります。
- この段階で、まだサイクル3を続行しますか？はいの場合、いつテストを停止しますか？
OrangeHRMライブプロジェクトテストの終了基準
ここで、「終了基準」と呼ばれるものを採用します。これは、テスト計画ドキュメントで事前に定義されています。サイクル2の後でテストを終了するか、もう1サイクル進むかを決定するのは、単にチェックリストの形式です。 OrangeHRMプロジェクトに関する以下の質問に対するいくつかの仮説的な回答を考慮して記入すると、以下のようになります。
上記のチェックリストを注意深く見ると、以前に説明しなかったメトリックとサインオフがそこに記載されています。それについて話しましょう。
テストメトリクス
テスト実行フェーズでは、他のすべてのプロジェクトチームメンバーにレポートが送信され、 QA実行フェーズで何が起こっているか 。この情報は、最終製品の全体的な品質に関する検証を得るために、すべての人にとって重要です。
10個のテストケースが合格したか、100個のテストケースが実行されたと報告したと想像してみてください。これらの数値は単なる生データであり、状況についてあまり良い見通しを示していません。
メトリックは、このギャップを埋める上で重要な役割を果たします。指標は簡単な言葉で、 テストチームが収集して維持するインテリジェントな数値 。 例えば、 テストケースの90％が合格したと言った場合、150のテストケースが合格したと言うよりも理にかなっています。そうですね。
テスト実行フェーズ中に収集されるさまざまな種類のメトリックがあります。どのメトリックを正確に収集し、どの期間維持するか-この情報は、テスト計画ドキュメントに記載されています。
以下は、ほとんどのプロジェクトで最も一般的に収集されるテストメトリックです。
- テストケースの合格率
- 欠陥密度
- 重大な欠陥の割合
- 欠陥、重大度に関する数値
チェックしてください この記事に添付されているステータスレポート これらのメトリックがどのように使用されるかを確認します。
テストサインオフ/完了レポート
テストが開始されたことをすべての利害関係者に通知する必要があるため、テストが完了したことを全員に通知し、結果を共有することもQAチームの義務です。そのため、通常、QAチーム（通常はチームリーダー/ QAマネージャー）から電子メールが送信され、QAチームがテスト結果と未解決/既知の問題のリストを添付して製品を承認したことが示されます。
サンプルテストサインオフEメール：
に： クライアント、PM、開発チーム、DBチーム、BA、QAチーム、環境チーム（および含める必要のあるその他の人）
Eメール： こんにちはチーム、
QAチームは、Webサイトの機能テストの2サイクルが正常に完了した後、OrangeHRMバージョン3.0ソフトウェアを承認します。
テストケースとその実行結果は、電子メールに添付されています。 （または、それらが存在する場所について言及します。または、テスト管理ソフトウェアを使用している場合は、同じことに関する詳細を提供します。）
既知の問題のリストも電子メールに添付されています。 （繰り返しますが、意味のある他の参照を追加できます。）
ありがとう、
QAチームリーダー。
添付ファイル： 最終実行レポート、最終問題/欠陥レポート、既知の問題リスト
QAチームからテストサインオフメールが送信されると、STLCプロセスは正式に完了します。これは、SDLCの「テスト」フェーズの完了を必ずしも示すものではありません。それを実現するために、まだUATテストを終了する必要があります。検索 UATテストの詳細はこちら 。
UATが完了すると、SDLCは展開フェーズに移行し、そこで稼働し、顧客/エンドユーザーが利用できるようになります。
それでおしまい！
これは、QAプロジェクトのような最もライブな体験を読者に提供するための私たちの取り組みです。この無料のオンラインソフトウェアテストQAトレーニングシリーズに関するコメントや質問をお知らせください。
推奨読書
- ソフトウェアテストトレーニング：ライブプロジェクトのエンドツーエンドトレーニング–無料のオンラインQAトレーニングパート1
- SRSドキュメントからのテストケースの作成（ライブプロジェクトのサンプルテストケースをダウンロード）
- ソフトウェアテストQAトレーニングコースのFAQ
- 2021年の手間のかからないトレーニングのための11の最高のオンライントレーニングソフトウェア
- キーワードビューの操作-QTPトレーニングチュートリアル2
- ソフトウェアテストの欠陥/バグライフサイクルとは何ですか？欠陥ライフサイクルチュートリアル
- JIRAバグ追跡ツールチュートリアル：JIRAをチケットツールとして使用する方法
- SRSドキュメントを確認してテストシナリオを作成する方法–ライブプロジェクトでのソフトウェアテストトレーニング– 2日目