読み取り時間:7分
プロジェクトの成功は、クライアントのニーズを満たす開発チームの能力に依存します。 の通信のクライアントを持つ大手企業の開発チームの果たす役割を解決致する製品や市場のニーズに応えられる., 問題は、顧客がニーズをあまりにも漠然と説明し、チームが明確な要件を理解できず、最終的にはその背後にあるビジネス上の問題を理解できない場合に ユーザーがオンライン書店で商品をカテゴリ別に検索できるようにするようにチームに依頼するとします。 それらをつける部門リンクが付いている明確なインターフェイスがあると期待する(例えば想像、ノンフィクション、歴史的、等。）開発の二週間後、あなたは、ユーザーが代わりに、事前に記載されているカテゴリを閲覧するのではなく、彼らが興味のあるカテゴリを入力する必要があ, この作品も、当初の目標は、露出しで利用可能なすべてのカテゴリユを探索す。
これは、高品質のソフトウェアドキュメントが問題を回避するのに役立つ場合です。 要件を文書化する主な形式としてのユーザーストーリーと受け入れ基準（AC）。 ユーザーストーリーは、フィーチャの自然言語の説明です。 それは通常、合格基準を伴っています。
受け入れ基準（AC）は、ソフトウェア製品がユーザー、顧客、または他のシステムによって受け入れられるために満たさなければならない条件です。, これらはユーザーストーリーごとに一意であり、エンドユーザーの観点から機能の動作を定義します。 よく書かれた受け入れ基準は、開発段階の終わりに予期しない結果を回避し、すべての利害関係者とユーザーが得られたものに満足していることを確
受け入れ基準は、最低レベルの機能要件です
受け入れ基準の主な目的
利害関係者の要件を明確にすることは、高レベル ACの目的をより明確にするために、それらを分解しましょう。,
機能スコープのデタライゼーション。 ACユーザーストーリーの境界を定義します。 提供されてい精度の詳細は機能するのかを理解すること”シリーズ-ドレスローザ編に完成作品として期待される。
否定的なシナリオを記述する。 R&bっぽACする必要があるかもしれなシステムが認識し、安全でないパスワードを入力するためのユーザーから進めます。 無効なパスワード形式は、ユーザーが無効な入力を行ったり、予期せず動作したりするいわゆる負のシナリオの例です。 ACこれらのシナリオを定義し、システムがそれらにどのように反応する必要
通信を設定します。, 合格基準は、クライアントと開発チームのビジョンを同期させます。 開発者は、機能がどのような動作を示す必要があるかを正確に知り、利害関係者とクライアントは機能から期待されるものを理解しています。
受け入れテストの合理化。 ACは、ユーザーストーリー受け入れテストの基礎です。 各受入基準は独立してテスト可能でなければならないため、明確な合否シナリオが必要です。 また、自動テストによるストーリーの検証にも使用できます。
特徴推定。, 受入れ基準を指定すようにする必要が開発した。 チームが正確な要件を持っていれば、ユーザーストーリーを正しく推定できるタスクに分割できます。
受け入れ基準タイプと構造
ACは異なる形式で書くことができます。
- シナリオ指向(Given/When/Then)
- ルール指向(checklist)
- カスタムフォーマット
最初と二番目のフォーマットは非常に特定の構造を持っているので、主にそれらに焦点を当てます。, ただし、他のフォーマットが製品に適していることがわかる場合がありますので、簡単に触れてみましょう。
シナリオ指向の受け入れ基準
ACを書くシナリオ指向のフォーマットは、Given/When/Then（GWT）タイプとして知られています。
- いくつかの前提条件を考えると
- 私はいくつかのアクションを行うとき
- その後、私はいくつかの結果を期待します
このアプローチは、ビヘイビア駆動開発（BDD）から継承され、テスターが特定の機能のテストを開始および終了するタイミングを定義するのに役立つ一貫性のある構造を提供します。, また、システムの動作が事前に記述されているため、テストケースを書くのに費やされる時間も短縮されます。,
この形式で記述された各受け入れ基準には、次のステートメントがあります。
- シナリオ–説明される動作の名前
- 与えられた–シナリオの開始状態
- When–ユーザーが行う特定のアクション
- Then–”When”におけるアクションの結果
これらのステートメントを組み合わせると、ユーザーが行うすべてのアクションがカバーされます。
これらのステートメントを組み合わせると、ユーザーが行うすべてのアクションがカバーされます。タスクを完了し、結果を体験するためにかかります。
いくつかの例を見てみましょう。,
例1
ユーザーストーリー：ユーザーとして、パスワードを忘れた場合に自分のアカウントにアクセスできるように、自分のアカウントにパスワードを回復できるように,ユーザーが電子メールで受信したリンクをナビゲートした場合
その後、システムはユーザーが新しいパスワードを設定できるようにします
例2
ユーザーストーリー：ユーザーとして、atmのアカウントから現金を要求できるようにして、アカウントから迅速かつ異なる場所でお金を受け取ることができます。,受け入れ基準2:
与えられた:口座が当座貸越されていること
そして:カードが有効であること
顧客が現金を要求するとき
その後:口座が引き落とされていること
その後:口座が引き落とされていること
その後:口座が引き落とされていること
その後:口座が引き落とされていること
その後:現金が引き落とされていること
/p>
then:拒否メッセージが表示されるようにする
および:現金が分配されないようにする
ルール指向の受け入れ基準形式
場合によっては、受け入れ基準を与えられた/when/then構造に適合させることが困難な場合があります。, たとえば、GWTは次の場合にはほとんど役に立たないでしょう。
- 他の品質保証の方法を必要とするシステムレベルの機能を記述したユーザーストーリー
- 受け入れ基準のターゲットオーディエンスには、テストシナリオの正確な詳細は必要ありません。
- GWTのシナリオは、機能の設計とユーザーエクスペリエンスの制約を記述するのには適していません。 開発者は、重要な詳細の数を見逃すことがあります。
これらのケースには、ルール指向のACフォーマットで対処できます。,
ルール指向の形式は、システムの動作を記述する一連のルールがあることを伴います。 これらのルールに基づき、特定のシナリオを描画できます。
通常、このフォームを使用して構成される基準は、単純な箇条書きリストのように見えます。 例を見てみましょう。
例
ユーザーストーリー：ユーザーとして、検索フィールドを使用して都市、名前、または通りを入力し、一致するホテルオプションを見つけることができます。,
基本的な検索インターフェイスの受け入れ基準
- 検索フィールドは、トップバーに配置されます
- ユーザーが”検索”をクリックすると検索が開始されます
- フィールドには、グレー色のテキストを持つプレースホルダが含まれています：”どこに行くのですか？”
- ユーザーが入力を開始するとプレースホルダーが消えます
- ユーザーが都市、ホテル名、通り、またはすべてを組み合わせて入力すると検索が実行されます
- 検索は英語、フランス語、ドイツ語、ウクライナ語です
- ユーザーは200個を超える記号を入力できません
- 検索は特殊記号(文字)をサポートしていません。, ユーザーが特殊記号を入力した場合は、”検索入力に特殊記号を含めることはできません。”
その他のフォーマット
ほとんどのユーザーストーリーは、上記の二つのフォーマットでカバーすることができます。 しかし、あなたは彼らが彼らの目的を果たし、平易な英語で明確に書かれており、誤解することはできません与えられたあなた自身の受け入れ基準を 一部のチームも使用します。,
時には、あなたの基準は、システム動作の例として指定することができます：
マークLevisonによる強力なパスワードのためのACの単純なセットagilepainpainrelief.com
このアプローチは、パスワード機能テストの明確なガイドラインを提供し
責任あるロールと受け入れ条件の作成方法
一部の条件は、プロダクトバックログを作成するときに、プロダクト所有者によって定義および書 その他、さらに指定されたチームの中でユーザー物語での議論の後、スプリント。, 基準を書く責任者を選ぶことに対する厳格な推奨はありません。 顧客は彼または彼女が十分な技術的な、製品ドキュメントの知識があればそれらを文書化できる。 この場合、クライアントは相互の誤解を避けるためにチームと基準を交渉します。 その他の基準を作成した製品のオーナー、ビジネスアナリスト、アナリスト、プロジェクトマネージャ。,
このプロセスは、ユーザーストーリーの優先順位付けから始まり、チーム全体との詳細の交渉で終わります
受け入れ基準を書く主な課題とベストプラクティス
受け入れ基準は、非常に書きやすいかのように見えます。 彼らの単純な形式にもかかわらず、執筆は多くのチームにとって挑戦を提起する。 一般的な間違いを避けるためのベストプラクティスをより深く見てみましょう。
開発前のドキュメント基準。 受け入れ基準は、実際の開発を開始する前に文書化する必要があります。, こうすれば、チームは多分顧客の必要性すべてを前もって捕獲する。 最初に、少数のユーザーストーリーの基準を設定して、二つのスプリントのバックログを埋めるだけで十分です（スクラムまたは同様の方法を練習する場合）。 両当事者の合意が必要です。 次に、文書化された受け入れ基準が開発者によって使用され、技術的プロセスを計画します。
ACを狭くしすぎないでください。 受け入れ基準は、開発者のための操縦オプションにはほとんどない生活あまりにも特定の方法 これを避けるために覚えているAC伝えなければならな同意がないます。, さらに、狭いACは、カバーされていない複数のユーザーの行動が失われる可能性があります。
あなたの基準を達成可能にしてください。 この点は前の点と密接に交差しています。 効果的な受け入れ基準は、提供できる機能の合理的な最小チャンクを定義します。 これまでに陥を記述するすべての細部にあり、リスクとチームのため多くの小さな事ができます。
ACを測定可能で広すぎないようにしてください。 幅広く受入れ基準をユーザー物語としない。, 効果的な合格基準は、開発者が適切に努力を計画および見積もることができるように、作業の範囲を概説する必要があります。
技術的な詳細は避けてください。 みてきたように、受け入れ基準のいずれかで記述しなければな平野を英語です。 これにより、利害関係者や管理者は技術的な背景を持たない可能性があります。
コンセンサスに達する。 同じ問題は、その視点に応じて、チームと利害関係者によって異なる方法で解決できる場合があります。 あなたのacを利害関係者に伝え、相互合意に達したことを確認してください。, チームメンバーも同じです。 誰もがACを確認し、彼らが理解し、各行に同意することを確認する必要があります。
テスト可能なACを書き込みます。 本試験機の検証についてすべての要件を満たした. その他、開発者と思われば、ユーザーの話が完了します。
Final word
受け入れ基準を無視しないでください–シンプルで親しみやすい–一度に複数の問題を解決します。, 顧客の期待を文書化し、エンドユーザーの視点を提供し、要件を明確にし、あいまいさを防ぎ、最終的には開発目標が満たされたかどうかを品質保証が検証するのに役立ちます。 アジャイルメソッドを使用するかどうかにかかわらず、最適な形式を選択するか、独自の形式で実験してください。 さまざまなタイプのユーザーストーリーと最終的に機能は異なるものを必要とする可能性があり、あなたのために働く新しいものをテストす