UATの管理/欠陥とバグの発生
ユーザー受け入れテスト（UAT）を管理するための最良のアプローチと、ユーザーが欠陥/バグをどのように提起するかを理解するための支援を探しています-あらゆる小さなエラーのすべてに無料で対処する必要がある前の状況にありました多くの無効な欠陥/バグをふるいにかける間、実際のバグ修正から貴重な時間がかかるバグとして発生します。
私を誤解しないでください、私は「欠陥ではない」と言ってユーザーをシフトするのではなく、プロセスをよりスムーズにして問題が修正されるようにしようとしています。
まず、まだ課題追跡ツールを使用していない場合は、取得してユーザーがアクセスできるようにします。このようにして、彼らは電子メールや電話で直接あなたをせがむのではなく、バグをそこに入力できます。もちろん、ツールを正しく使用するようにトレーニングする必要があります。これは大きな初期投資になる可能性がありますが、すぐに成果が得られます。
バグと思われるものをユーザーが自由に報告できるようにしますが、それらは各バグに重大度や優先度を割り当てますです。これにより、最も重要な/緊急なものに集中できますが、すべてを追跡できます。すべての適切なバグトラッカーには、これらのプロパティのサポートが組み込まれており、バグに応じてクエリ/フィルター/順序付けを行うことができます。バグの重大度または優先度が正しくない場合は、ユーザーと話し合って修正できます。一部のユーザーが実際のバグではない、または再現できない問題を頻繁に報告する場合、あなた（またはあなたの管理者）はこれについて彼らと話し合う必要があるかもしれません。開発プロセスで。
A 変更制御ボード（CCB） は、ユーザーの要求から開発者を保護するのに役立ちます。 CCBは、定期的に会合して、提出された最新の欠陥をレビューし、その影響を特定し、優先順位を付け、場合によっては開発チームのメンバーに割り当てるグループです（個人でもかまいません）。
CCBは、前回の会議以降に提出されたすべての不具合と機能リクエストを確認します。それぞれについて、有効なリクエストであるかどうかを判断します。そうでない場合、それは理由で閉鎖されます。それが有効である場合、重要性が割り当てられ、設立日または締切日のマイルストーンが割り当てられる可能性があります。 CCBの開発リーダーは、使用しているプロセスに応じて、特定の開発者にタスクを割り当てることさえできます。
開発者が気にする必要があるのは、CCBによって承認された欠陥と機能のリクエストだけであり、ユーザーが提出したすべての欠陥ではありません。 CCBは、ユーザーの要求を、正式なバグレポート、優先順位付けされたユーザーストーリー、または更新された要件仕様など、開発チームへの予想される入力に変換する役割も果たします。
状況によっては、ユーザー/顧客に問題追跡ツールへのアクセスを提供できない場合があります。このような場合は、CCBが選択した問題追跡ツールのバグレポートまたは機能リクエストに変換するために必要なすべての情報を含むレポートを全員が送信できるようにする別の標準化された方法が必要になります。ほとんどの場合、品質保証は、使用している問題追跡ツールに直接送信しますが、開発者が作業を開始する前に、CCBによって確認、優先順位付け、および割り当てられます。
この質問に答える方法は、一歩下がって、あなたの開発プロセスを定義することだと思います。スクラム、またはリリーススケジュールが定義されている他のアジャイル開発方法論、および各リリースで何が行われるかを決定するプロセスを使用している場合は、次のリリース計画セッションまでバグへの対処をプッシュできます。 （もちろん、「ショーストッパー」のバグはすぐに修正する必要があります。）リリース計画セッションでは、新機能のリクエストとともにバグに優先順位を付け、何を取得し、何を除外するかを決定する必要があります。かなり短いリリースサイクル（1〜2週間ごとなど）を実行している場合、ユーザーは重要なものがすぐに修正されていることを確信できます。
ピーターが上で言ったこと、ユーザーがバグを捕らえ、優先順位を設定することを可能にする問題追跡システムを持つことは重要です。ただし、「チーム」が同意しない限り、バグ修正はリリースに含まれないため、これは最初のステップにすぎません。
これは実際には素晴らしい質問であり、簡単な答えはありません。どのソリューションを使用する場合でも、組織に適合する必要があります。
このリンクは、どの方法論が最適であるかをさらに調査するための出発点として、興味深い読み物である場合があります。