what is user story acceptance criteria
実際のシナリオでのユーザーストーリーの受け入れ基準の完璧なガイド：
ソフトウェア開発業界では、「要件」という言葉は、私たちの目標が何であるか、顧客が正確に何を必要としているか、そして何が私たちの会社をビジネスを拡大させるかを定義します。
ソフトウェア製品を製造する製品会社であれ、さまざまなソフトウェア分野でサービスを提供するサービス会社であれ、それらすべての主要な基盤は要件であり、成功は要件がどれだけ満たされているかによって決まります。
「要件」という用語は、プロジェクトの方法論によって名前が異なります。
に 滝 、それは ‘と呼ばれます 要件/仕様書 ’、で アジャイルまたはスクラム それは「エピック」、「ユーザーストーリー」と呼ばれます。
ウォーターフォールモデルでは、製品全体が1つのフェーズで実装されるため、要件ドキュメントは200ページ以上の巨大なドキュメントになります。しかし、これはアジャイル/スクラムには当てはまりません。これらの方法論では、製品が段階的に準備されるため、小さな機能や機能に対する要件が与えられているためです。
この記事では、ユーザーストーリーとそれに関連する承認基準の使用に関する、4年間の経験すべてを、理解を深めるための簡単でシンプルな実際のシナリオとともに共有するように最善を尽くしました。
まず、基本をもう一度見てみましょう。
学習内容：
ユーザーストーリーとは何ですか？
ユーザーストーリーは、1行または2行で、最大5行まで書き留められる機能または機能の要件です。ユーザーストーリーは通常、可能な限り最も単純な要件であり、1つだけの機能（または1つの機能）に関するものです。
ユーザーストーリーの作成に最も一般的に使用される標準形式を以下に示します。
として
例：
WhatsAppユーザーとして、チャット書き込みボックスのカメラアイコンで写真をキャプチャして送信し、写真をクリックしてすべての友達と同時に共有できるようにします。
合格基準とは何ですか？
受け入れ基準は、製品の所有者/利害関係者によって受け入れられるために、機能または機能が満たす必要がある一連の受け入れられた条件またはビジネスルールです。
これはユーザーストーリーの完成の非常に重要な部分であり、単一の基準を見逃すと多くの費用がかかる可能性があるため、プロダクトオーナーとビジネスアナリストが非常に注意深く検討する必要があります。これは単純な番号付きまたは箇条書きのリストです。
その形式は次のとおりです。
「」 私が何らかの行動をとるときにいくつかの前提条件が与えられると、私は結果を期待します 」。
swfファイルがChromeで開かない
例（上記のユーザーストーリーへのw.r.t）：
- 友達とチャットしていて、写真を撮れるはずだと考えてみましょう。
- 写真をクリックすると、送信する前に画像にキャプションを追加できるはずです。
- 携帯電話のカメラの起動に問題がある場合は、「カメラを起動できませんでした」などのエラーメッセージが表示されます。など、それに応じて表示する必要があります。
したがって、ユーザーストーリーは機能または機能の要件を定義し、承認基準はユーザーストーリーまたは要件の「完了の定義」を定義します。
QAとして、ユーザーストーリーとその受け入れ基準を深く理解することは非常に重要であり、「テストの開始」に疑問が1つも残っていません。今後は、ユーザーストーリーと受け入れ基準を「深く」掘り下げることが非常に重要である理由を理解しましょう。
ユーザーストーリーを深く掘り下げる
まず、基本的かつ基本的なことの「詳細な」研究の重要性を理解しましょう。 ユーザーストーリー。
以下の事例は私自身の実際の経験です。
ケース＃1：
3年前、私はモバイルアプリケーションプロジェクトに取り組んでいました。この製品は、配達員向けに設計されたアプリケーションでした。
あなたは配達人が配達のためにあなたの場所に来るのを見たでしょう。そして、彼らはあなたに配達後にあなたの署名を与えるように頼む携帯電話を持っています。この署名は、DTDC、FedExなどの宅配便プロバイダーのポータルに反映されます。
モバイルアプリがリリースされたばかりで、ポータルがすでに存在していて稼働していると想像してみましょう。
問題： スプリントの場合、プロダクトオーナーはこのモバイルアプリのユーザーストーリーを持っています。 「ポータル管理者として、配達時に配達員が取った署名を表示できるはずです」 。ここで、ポータル（Webアプリ）は、署名を反映するように変更および更新されます。
QAとして、モバイルアプリでキャプチャされた署名がポータルで期待どおりに反映されているかどうかを確認する必要があります。
このユーザーストーリーを見ると、単純に見えますが、ここには「過去の配信には署名の反映機能がなかったので、ポータルの担当者が過去の配信を表示した場合はどうなるでしょうか」という隠された要件があります。履歴データを消去する必要がありますか？そのようなデータのクラッシュやエラーを許可する必要がありますか？
もちろん、まったくそうではありませんが、これは慎重に処理する必要があります。
解決： それぞれのDBテーブルが更新されて、署名の場所に新しい列が追加されると、古いデータの値がNULLまたは0になり、チェックする必要があり、「署名が存在しません」というメッセージが表示されます。
これは、プロダクトオーナーまたはビジネスアナリストからのミスと呼ぶことができますが、これを行う必要があります。 1つの機能を正常に実装しますが、それと一緒に何かを壊すことは、顧客にとって望ましくありません。これは、同じユーザーストーリーと同じスプリントで行う必要があります。
ケース＃2
6年前、私は退職計画財務アプリケーション（BAなし）に取り組んでいました。これは、CA、財務アドバイザーなどの財務担当者がさまざまな通貨で使用して、投資計画や貯蓄などを予測できるグローバルアプリケーションです。彼らの顧客に長い期間。
問題： プロダクトオーナーはあなたに次のようなユーザーストーリーを提供します 「アドバイザーとして、提供された財務詳細に基づいて顧客のレポートを表示したいと思います」。
ここには2つの隠れた要件があり、次の理由で不完全なストーリーと呼んでいます。
に) レポートでは、最後に表示したレポートのように過去の為替レートではなく、毎日の為替レートを考慮する必要があります。
b) 顧客の財務詳細を提供した後に通貨が変更された場合、レポートは変更された通貨で表示されます。
解決： 私はこの懸念をプロダクトオーナーに直接提起し、これらの両方をできるだけ早く実行する必要があることを彼に認識させました。彼は私に同意し、次のスプリントのために2つの異なるストーリーを優先的に作成しました。
取り除く： これらは、製品、デザイン、構造などをよく知っていたために捉えられました。このような知識は、製品を完全に理解し、モジュールの相互運用性を理解し、たとえそれがあったとしてもユーザーストーリーを徹底的に研究することによってのみ達成できます。 2ライナー。
物事を簡単にするためにメモを取り、BAや開発者と彼らの考えについて話し合ってください。
受け入れ基準の詳細な調査
ユーザーストーリーを過小評価するよりも、受け入れ基準やその他すべての条件とルールを徹底的に理解することがさらに重要です。要件が不完全またはあいまいな場合、次のスプリントで取り上げることはできますが、受け入れ基準を満たしていない場合、ユーザーストーリー自体をリリースすることはできません。
私たちは皆、ある時点でネットバンキングを使用していたと思います。私たちのほとんどは毎日それを使用しており、私は過去のステートメントをたくさんダウンロードしています。注意深く観察すると、それらをダウンロードするために利用できる特定のオプションがあります。
ステートメントをダウンロードするためのファイルのタイプを選択するオプションがあります。クレジット/デビット/両方のみをダウンロードするかどうかを選択するオプションがあります。
ここで、プロダクトオーナーがこのユーザーストーリーを提供するとします。「顧客として、特定の期間に行われたすべてのトランザクションを表示できるように、アカウントステートメントをダウンロードしたい」。
次の合格基準で：
- (履歴ステートメントのダウンロード)ページを表示していることを考慮して、ステートメントをダウンロードする期間を選択する必要があります。
- (履歴ステートメントのダウンロード)ページを表示していることを考慮して、ステートメントをダウンロードするアカウントを選択する必要があります。
- 履歴ステートメントのダウンロードページを表示していることを考えると、将来の「終了」日にステートメントをダウンロードすることは許可されません。
- 私が「履歴ステートメントのダウンロード」ページを表示していることを考えると、10年後の「開始」日付を選択することは許可されるべきではありません。
- ステートメントをダウンロードすることを考えると、ダウンロードしたファイルを表示できるはずです。
- 履歴ステートメントのダウンロードページを表示していることを考えると、ステートメントをdoc、excel、およびpdf形式でダウンロードできるはずです。
この承認を通過した場合、ここに欠けているものが3つあります。
- ダウンロードするファイル名の名前と形式。
- ファイルに表示される情報（列名）。
- オプションリストを使用して、顧客が希望するトランザクションの種類を選択します。つまり、借方のみ、貸方のみ、またはその両方です。
このようなケースはたまに発生する可能性がありますが、それでも各受け入れ基準について十分に検討し、ユーザーストーリーを参照して視覚化してみてください。条件とビジネスルールについて深く研究すればするほど、その機能についての知識が増えます。
初期段階で見つかったバグは、「テスト」段階での費用と比較して費用がかかりません。
ユーザーストーリー/受け入れ基準の不一致を見つけることの重要性
開発やテストを開始する前であっても、早い段階でユーザーストーリーと受け入れ基準を深く掘り下げることが常に重要です。
それが含まれるため：
＃1）時間の浪費：
開発中またはテスト中のときに、ユーザーストーリー/承認基準の不一致や誤りが見つかった場合は、残りのスプリント時間に多くのやり直しが必要になる可能性があります。
プロダクトオーナーがいくつかのことを見逃したとしても、ユーザーストーリーを次のスプリントに移すことはありません。 95％の可能性は、チームに必要な実装を行い、同じスプリントでリリースするように依頼することです。
したがって、チームは余分な時間を費やしたり、週末に来たり、深夜に仕事をしたりする必要があるため、チームにとっては悪夢になります。これは、可能な限り早い段階でユーザーストーリー/受け入れ基準を調査および議論することで回避できます。
＃2）努力の無駄：
開発者とQAは、実装されたコードとテストケースを再度確認する必要があります。要件ごとに更新、追加、削除するのは簡単な作業ではありません。時間通りに配達するというプレッシャーがすでにあるので、それはあまりにも苦痛になります。
このような状況では、開発またはテスト段階でミスが発生する可能性があります。このような状況に遭遇した場合は、「DevQAペアリング」を選択してください。ケーキのアイシングとして、余分な作業の補償が得られない場合があります。
結論
ユーザーストーリーと受け入れ基準の深い理解は、それを研究することに膨大な時間を費やすことによってのみ達成することができます。
これは製品に関する論理的思考、経験、知識に関するものであるため、これを行うための特定のツールやコースは市場にありません。
事前計画会議に積極的に参加し、BAと話し、自分で勉強することは、これを達成するのに役立つだけです。努力すればするほど、学び成長します。
QAであろうと開発者であろうと、ユーザーストーリーとその受け入れ基準について全員が同じページにいる必要があります。そうしないと、顧客の期待をうまく達成できません。
ユーザーストーリーでの作業経験について、私たちと共有する新しい何かがありますか？以下にご意見をお聞かせください!!