3

しばらく前 (約 3 か月) に TFS 2013 をバグ追跡ツールとして使用し始めました。これ以前は、TFS をソース管理としてのみ使用していました (バグ追跡は別のソフトウェアで実行されていました)。今のところ、いくつかのプロセスを開発しました。このプロセスが正しいかどうかを理解するのに役立つコメントをいただければ幸いです。したがって、ここにそれらがあります：

一般的な情報：

  • 一つの大きな製品を開発しています。
  • 私たちのチームには 5 人の開発者と 2 人の QA がいます。
  • 多くの場合、1 ～ 2 か月ごとに新しいバージョンをリリースしています。
  • 1 週間のスプリントがあります。

TFS の使用方法は次のとおりです。

  • 1 つのチーム プロジェクトと、その中にいくつかの領域があります。各領域は製品の一部を表しています。
  • 私たちのチーム プロジェクトでは、スクラム 2.2 テンプレートを使用しています。
  • チーム プロジェクトでは、リリースごとに「大きな」イテレーションを作成します (たとえば、「リリース 01.2014」、「リリース 03.2014」)。これは、前のイテレーションの終わりから始まり、1 ～ 2 か月続きます。
  • タスクとバグの 2 つの標準作業項目タイプを使用します。
  • すべてのバグとタスクは、適切な「大きな」反復と領域に属します。
  • タスクは 2 つの方法で使用されます: 改善や新機能のためのスタンドアロンの作業項目として、およびバグを修正するときはバグの子として。
  • 現在の状況を監視するために、TWA の一連のクエリを作成しました。それらの一部は共有されています (「新しいバグ」、「テスト用のバグ」、「進行中のタスク」など)。一部は各開発者/QA によって作成されます (「進行中の私のタスク」、「私のタスク」など)。 Bugs done」など）。

バグの作業プロセスの説明は次のとおりです。

-->QA (or dev) creates a bug (State: New)
-->QA (or dev) assigns this bug to some dev (State: Approved)
-->When dev starts to fix a bug, he does the following:
---->changes state of bug to Committed
---->creates child task and changes its state to InProgress
-->When dev commits some code, that should fix the bug, he bounds checkin to task (created on previous step)
-->QA understands, that bug is fixed and ready for testing, when bug is in Committed state and EACH child task is in Done state
-->QA tests fixing of bug:
---->if bug is not fixed he changes state of bug to Approved
---->if bug is fixed he changes state of bug to Done

このプロセスは悪くないように見え、何とか機能します。しかし、改善や新機能のために作成されたスタンドアロン タスクには問題があります。

スタンドアロン タスクのプロセスの説明は次のとおりです。

-->QA (or dev) creates a task (State: ToDo)
-->QA (or dev) assigns this task to some dev (State: ToDo)
-->When dev starts working on this task, he changes its state to InProgress
-->When dev has finished working on task, he changes its state to Done
-->QA tests this task:
---->if new features work fine ?
---->if new features work with errors ?

主な問題は次のとおりです。QA はタスクをテストに合格または不合格としてマークするにはどうすればよいでしょうか。 現時点での解決方法: QA はテスト済みのタスクに「クローズ」タグを付けて、すべて問題がなければタグ付けし、エラーがある場合はタスクの子バグを作成します。しかし、この方法でタグを操作するのは良くないようです。

編集 もう 1 つの質問: バグが開発者に割り当てられたときに、バグ/PBI のどの状態が最も適しているか?

コメントや提案は大歓迎です。

4

2 に答える 2

4

スクラム テンプレートを意図したとおりに使用していません。

典型的なアプローチは、プロダクト バックログ アイテムを使用して機能を表し、子タスクを使用して PBI またはバグに必要な作業を表すことです。

多くの場合、チームには、各 PBI/バグに対して実行する必要があるテスト作業を表す 1 つ (または複数) のタスクがあります。次に、タスクのステータスを確認することで、テストが完了したかどうかを追跡できます。

于 2014-03-16T18:48:19.090 に答える
1

投資に関心があるよりも多くの作業/オーバーヘッドがあるかもしれませんが、「テストケース」作業項目タイプの使用を検討しましたか? テスト ケースに関する 2 つの気の利いた点:

  • タスクにアタッチして、タスクがそのテスト ケースによって「テストされる」ことを指定できます。
  • それらは結果を持つことができ、テストの定義を反復間で再利用可能にします
  • テストの現在のステータスが何であるかを示すための組み込みのレポートがたくさんあります (合格、失敗、実行されていないなど)。
  • テスト結果を入力し、TFS Web インターフェイスでテスト ケースを管理するための UI もあります。
  • テストは自動化する必要はありませんが、自動化されていると便利です。「手動」テストのみを使用している場合でも、上記のすべての利点が得られます

詳細はこちら: http://msdn.microsoft.com/en-us/library/dd380763.aspx

于 2014-04-08T23:05:19.130 に答える