私は大学のプロジェクトに着手しようとしています。プロジェクトの範囲を考えると、XP /アジャイル方法論を使用することにしました。ユースケース図の作成から始めました。最初の2つの機能のユーザーストーリーを収集する。
私は顧客が受け入れテストを開発するのを支援している最中です。私の質問は次のとおりです各機能のユーザーストーリーをユーザー受け入れテストとして使用できますか?
すべきではない。
受け入れテストは、ブラックボックスシステムテストです。各受け入れテストは、特定の入力後にシステムから期待される結果を表します。
たとえば、電卓の有効なユーザーストーリーは次のとおりです。
"ユーザーとして、2つの数値を合計したい"
その受け入れテスト:
ユーザーストーリー自体は、価値を理解する上で「なぜ」の質問に実際に回答するため、できません。
ただし、ユーザーストーリーごとにシナリオを作成し、これらのシナリオを自動化して受け入れテストにすることができます。 Behavior-Driven Development ((BDD) を見てください。
いいえ、2つの概念を分ける方が良いです。
受け入れテスト顧客がそれを「完了」と見なす前にシステムが何をしなければならないかを正確に定義します。機能要件だけではありません。また、パフォーマンス、セキュリティ、使いやすさなどの非機能的なものもテストします。受け入れテストで機能的にカバーされていない場合、お客様は必要ありません。ストーリーまたは機能は、それを定義する一連の受け入れテストに合格するまでは実行できないと言えます。
ユーザーストーリーは、新しい機能を望む人、通常はシステムのユーザーまたは顧客の観点から見た、機能の短い簡単な説明です。通常、これらは単純なテンプレートに従います。
As a <type of user>, I want <some goal> so that <some reason>.
さらに読むためのいくつかのリンクの下:
http://www.mountaingoatsoftware.com/topics/user-stories
http://www.exforsys.com/tutorials/testing/what-is-user-acceptance-testing.html
これは、ユーザーストーリーの範囲が正確に何であるかに依存します。たとえば、「ユーザーがサイトにサインインし、電子メールを確認してダウンロードを受信する」など、範囲が広い場合は、「いいえ」です。ただし、ユーザーストーリーのスコープが狭い場合、たとえば、「1)aと2)bのキューを持つユーザーは、次の映画を取得するリクエストを送信します。「a」は利用できません。次に「b」を送信し、次に「yes '。
ユーザーストーリーのサンプルを1つまたは2つ提供してから、この回答を更新させていただきます。