開発者として、バグを特定し、要件が満たされていることを確認するためにユーザーがテストしたいさまざまなバージョンのアプリケーションをリリースすることがよくあります。
私はユーザーに、私が変更したことやテストが必要な新機能の大まかなアイデアを提供しますが、これは少しばかげているようで、あまりよく構成されていません。
反復型開発中にUATを要求するときに、他の人がどのようなアプローチや手順をとるか知りたいです。
ありがとう。
開発者として、バグを特定し、要件が満たされていることを確認するためにユーザーがテストしたいさまざまなバージョンのアプリケーションをリリースすることがよくあります。
私はユーザーに、私が変更したことやテストが必要な新機能の大まかなアイデアを提供しますが、これは少しばかげているようで、あまりよく構成されていません。
反復型開発中にUATを要求するときに、他の人がどのようなアプローチや手順をとるか知りたいです。
ありがとう。
テストスクリプトの作成には非常に時間がかかり、多くの場合、修正を実施するのにかかる時間よりも長くなります。ここで行う作業量が多いため、効果的なテストスクリプトを作成する時間がありません。
私たちの変更により、アプリケーションのサポートとビジネスの受け入れという2つのレベルでテストを推進します。技術的アプローチとビジネス的アプローチで、変更のほとんどの側面がテストされることを願っています。何をテストする必要があるかを知らせるために、変更によって影響を受けたアクションのリストを添付します(製品の追加、製品の削除、製品の編集)。
これを強力な単体テストアプローチと組み合わせると、大量の環境に対する最良のアプローチであると私は考えています。
ユーザーストーリーやユースケースはあなたが探しているものかもしれません、最初にどのように変更を決定し、どのようにそれを指定しましたか。小さなストーリー、または実際の構造化されたユースケースを作成する場合は、それを変更の仕様として使用できます。その後、ユーザーはそのストーリーに対してテストして、実装が説明と一致するかどうかを確認できます。
通常、各機能リストと「期待される結果」および「実際の結果」列を含むスクリプトを Excel で作成し、期待される結果の列には何が発生するかを記入します。私自身の使用のために、アイテムの ID である列を含めます。これは、Team System のタスク ID または作成されたプロジェクト計画の WSB に対応します。
構造化された方法で UAT を実施するための効率的かつ効果的な方法を探しています。ペアワイズまたはコンビナトリアル テスト デザイン アプローチを使用することを強くお勧めします。私はこのアプローチを 20 以上の概念実証プロジェクトで使用してきましたが、手動でテスト ケースを特定する従来の方法と比較して、このアプローチでは一貫して、テスター 1 時間あたりに検出される欠陥が劇的に多くなることがわかりました。実際、私が共同執筆した IEEE Computer の最近の記事で報告されているように、平均して、テスター 1 時間あたり平均で 2.4 倍の欠陥が見つかりました。
このアプローチは、こちらのビデオで説明されています。これが「私のツールを使用する」プラグインのように見える場合は、お詫び申し上げます。というつもりはありません。これは、テストの設計に使用する特定のツールではなく、劇的なメリットをもたらすアプローチです。James Bach も彼の satisfice.com サイトで AllPairs という無料ツールを提供しています。私のポイントは、これらのツールは最小限のテストで最大のカバレッジを生成するように設計されているため、そのようなツールを使用すると劇的に優れた結果が得られるということです。彼らは繰り返しを避けます。さらに、手動のテスト ケース識別方法では埋められないカバレッジの潜在的なギャップを自動的に識別して埋めます。
Hexawise のようなツールが、テスターが (数日で) 識別して文書化できるよりも、実行すべき UAT テスト ケースを (数秒で) 識別できるというのは直観に反するかもしれませんが、それでも真実です。自分で試してみてください。チームの 1 人の UAT テスターに、Hexawise で作成された 20 のエンドツーエンドの「ブラック ボックス」または「グレー ボックス」テストを実行させ、他のテスターに通常のテストを行わせます。20 回の Hexawise テストを実行するテスターが、テスター 1 時間あたりにより多くの欠陥を発見する (そして、「重要な」欠陥だけでなく、「重要でない」欠陥も発見する) ことに大金を賭けるでしょう。
これらの種類の方法が、テスト設計方法に関する Lee Copeland の本のような本を読むのに時間を割く比較的洗練されたテスター グループ以外のテスト コミュニティであまりよく知られていないのは残念です。ペアワイズ法とコンビナトリアル法は一貫して機能し、効率と有効性を大幅に改善し、テスト チームがすぐに使い始めるのは非常に簡単です。
ジャスティン(ヘキサワイズの創設者)