アジャイルテストの受け入れ条件

Hannah Son著

アジャイル開発のフレームワーク内で、受け入れ条件はユーザーストーリーとその最終的な形をつなぐ重要な役割を果たします。受け入れ条件はテスターが受け入れ条件はテストを設計するための重要な基準となり、機能が正しく実装されているかを検証するための基盤を提供します。

受け入れ条件は、デリバリーされる製品が顧客の期待に沿ったものになることを保証します。明確に定義された顧客ニーズとともに、受け入れ条件は潜在的な誤解を軽減し、透明性を促進します。顧客の期待に沿うことは、そのまま顧客満足度に貢献します。

受け入れ条件を策定し文書化する方法

受け入れ条件を策定し文書化することは、アジャイルの枠組みにとって重要です。それには共同作業が必要です。この作業は、ユーザーストーリーを完了とみなすには何が必要かの概要を明確に定義することにもつながります。

ユーザーストーリーと受け入れ条件

ユーザーストーリーと受け入れ条件は、アジャイル開発において密接に関連する要素です。ユーザーストーリーは実装するべき要件または機能を説明的に表したものとして機能し、受け入れ条件はストーリーがー完了したとみなされるために満たすべき条件を定義します。

ユーザーストーリー

ユーザーストーリーは、エンドユーザーから見たフィーチャーや機能の簡潔な説明です。通常、「[ユーザータイプ]として、私は[理由]のために[何らかのゴール]を達成したい」という形式に従います。ユーザーストーリーは、詳細に過剰に立ち入ることなく、達成するべきニーズを捉えます。

受け入れ条件

ユーザーストーリーが完了したとみなされるには、受け入れ条件または要件を満たす必要があります。条件はユーザーストーリーで説明された機能の範囲や詳細を示します。受け入れ条件によって特定のストーリーの「完了の定義」が決定されます。

この２つの間には、受け入れ条件はユーザーストーリーから派生し、密接に結び付けられるという関係があります。

ユーザーストーリーから派生: 受け入れ条件はユーザーストーリーから抽出され、直接的にリンクされます。受け入れ条件はユーザーストーリーの目標を達成するために何をデリバリーする必要があるかを詳細に説明します。
ユーザーストーリーの説明と検証: 受け入れ条件は、ユーザーストーリーが適切に定義され、テスト可能であることを保証するのに必要な詳細情報を提供します。受け入れ条件は、実装された機能がユーザーの期待を満たしているかを検証するのに役立ちます。
相互理解: ユーザーストーリーと受け入れ条件が組み合わさることで、開発チーム、ステークホルダー、顧客の間に、何をデリバリーする必要があり、どのように完了を判断するかに関して共通認識が生まれます。
テスト可能な条件: 受け入れ条件は、ユーザーストーリーが正しく実装されたかを検証するテストを作成するための土台の役割を果たします。受け入れ条件は、機能が期待どおり動作することを確認するための個々のテストシナリオの概略を示します。

端的に言うと、ユーザーストーリーは達成するべきことの背景やコンテキストを設定するいっぽう、受け入れ条件はユーザーストーリーで示された目標を満たすために必要な詳細な条件や要件を示します。

ユーザーストーリーと受け入れ条件の例

E-コマースアプリケーションでの現実的なシナリオを考えてみましょう。

ユーザーストーリー: 顧客として、私は自分の注文を追跡して購入のステータスを参照できることを希望する。

受け入れ条件:

ログイン時: ログイン後、ナビゲーションバーに「My Orders」セクションが表示されるべきです。
注文履歴: 「My Orders」セクションで、ユーザーは過去のすべての注文の注文番号、日付、ステータス(処理中、発送済み、配達済み)のリストを参照できる必要がある。
注文の詳細: 注文をクリックすると、購入したアイテム、数量、価格、発送情報を含む詳細情報が表示される必要がある。
注文ステータスの更新: 注文ステータスはリアルタイムで更新する必要がある。たとえば、注文が処理中から発送済みに変わった場合、この変更がただちにステータスに反映される必要がある。
E-mail通知: ユーザーは注文ステータスの変更に関するE-mail通知を受け取る必要がある。E-mailにはステータス変更のサマリーおよびWebサイトで詳細を参照するためのリンクが記載されている必要がある。

このシナリオでは、ユーザーストーリーは顧客から見たハイレベルでのニーズ、つまり「注文を追跡できること」という概略を示しています。

受け入れ条件は、該当ユーザーストーリーを実現するために必要な具体的な機能や動作を詳細に記述します。完成し動作する機能の構成要素を定義し、開発およびテストのガイダンスとなります。

受け入れ条件は、E-コマースアプリケーションで機能に何が含まれ、どのように動作するべきかに関して明確な構造を提供し、注文追跡機能が顧客の期待に確実に応えられるようにします。

誰が受け入れ条件を定義するのか？

通常、受け入れ条件は、ソフトウェア開発プロジェクト内の複数の役職が協力して定義します。受け入れ条件の定義に関与する重要なステークホルダーは次のとおりです。

プロダクトマネージャー: プロダクトマネージャーはユーザーのエクスペリエンスおよびニーズ、マーケットの要求、全体的な製品ビジョンを理解するのが仕事であるため、多くの場合、受け入れ条件の定義を主導します。プロダクトマネージャーはステークホルダーと密接に協力して要件を収集し、受け入れ条件がユーザーの観点に沿ったものになるようにします。
ビジネスアナリスト: この専門職は、ビジネスニーズを理解し、要件を分析し、対処可能な受け入れ条件という形にするうえで重要な役割を果たします。ビジネスアナリストはビジネス上のステークホルダーと開発チームの橋渡しをします。
開発チーム(開発者およびテスター): 開発者およびテスターは技術的側面や特定の条件の実現性に対する洞察を提供します。テスターは、特に条件がテストおよび検証可能であることを保証するのに貢献します。
ステークホルダー: エンドユーザーまたは顧客の代表など、その他のステークホルダーは、ユーザーの期待およびニーズに対する洞察を提供することで、受け入れ条件の定義に貢献できます。

アジャイル環境では、これらの役割のコラボレーションが鍵です。プロダクトオーナーが受け入れ条件の優先順位付けおよび最終的なまとめを主導するのが通常ですが、条件が網羅的かつ明確でプロジェクト全体の目標と整合性が取れたものにするのはチーム作業です。

受け入れ条件作成のベストプラクティス

効果的な受け入れ条件を作成することは、ソフトウェア開発を成功させるのに重要です。目標は、テスト可能で対応するユーザーストーリーに直接関連する条件のセットを作成することです。以下は検討するべきベストプラクティスの例です。

コラボレーションする: すべてのステークホルダーを巻き込みます。コラボレーションによって、さまざまな観点を確実に考慮でき、要件の包括的な理解につながります。受け入れ条件に関して当事者意識の共有を促進し、誤解を最小限にします。
明確かつ簡潔で計測可能な記述: 明確な記述は混乱や誤解を防ぐのに役立ちます。計測可能な記述は、客観的に検証可能な具体的な期待値を設定し、何が成功であるかの共通認識を確保します。
具体的かつテスト可能な条件: 具体的な条件は、あいまいさをなくし、何をデリバリーする必要があるかについて明確なガイドになります。テスト可能な条件は、検証を可能にし、要件を客観的に検証できるようにします。
条件とユーザーストーリーまたは機能の整合性/リンク: 受け入れ条件とユーザーストーリーまたは機能を関連付けることで、コンテキストや関連情報を提供し、各条件が特定の機能またはユーザーニーズに直接的に関連するようになります。
優先順位を付ける: 受け入れ条件に優先順位を付けると、時間とリソースを効率的に管理するのに役立ちます。それによって、必須の機能や要件が最初に対応されるよう保証できます。
はっきりと説明し、例を使用する: 受け入れ条件ではあいまいさを避けるのが重要です。例やシナリオを使用すると期待が明確になり、誤解の余地が少なくなります。
必要に応じて継続的に条件を更新する: プロジェクトの進行や新しい情報が手に入ったことに伴って、受け入れ条件も変化する場合があります。定期的な見直しと調整によって、プロジェクトの目標やステークホルダーのニーズと条件の整合性を保つことができます。
条件に関してステークホルダーの同意を確保する: 受け入れ条件に関してステークホルダー内の意見が一致することは非常に重要です。それによって、皆が共通認識を持って条件の実現に尽力し、プロジェクトが進行した後に摩擦や誤解が起きる可能性を減らすことができます。

よい受け入れ条件の例

以下は、ベストプラクティスに従った受け入れ条件の例です。

ユーザーストーリー: 登録済みユーザーとして、私はパスワードを忘れた場合にパスワードを変更して自分のアカウントに再びアクセスできるようにしたい。

受け入れ条件:

「Forgot Password」リンクにアクセスした場合:
1. ログインページにいる場合、「Forgot Password」リンクをクリックすると、パスワードのリセットページにリダイレクトされる必要がある。
パスワードリセット用のE-mailの入力:
1. パスワードリセットページにいる場合、登録済みのE-mailアドレスを入力してサブミットすると、パスワードをリセットするためのE-mailが送信されたことを示す確認メッセージが表示される必要がある。
パスワードリセットE-mailの受信:
1. パスワードのリセットをリクエストした場合、E-mailをチェックすると、パスワードのリセットリンクが記載されたE-mailが受信される必要がある。
パスワードリセットリンクのクリック:
1. パスワードのリセットE-mailを受信した場合、E-mailのリセットリンクをクリックすると、新しいパスワードを入力できるページにリダイレクトされる必要がある。
新しいパスワードの設定:
1. パスワードのリセットページにいる場合、新しいパスワードを入力して確認すると、処理完了メッセージによってパスワードが更新されたことが確認される必要がある。
新しいパスワードを使用したログイン:
1. パスワードをリセットした後、新しいパスワードを使用してログインを試行すると、アカウントに正常にアクセスできる必要がある。

これらの受け入れ条件は、具体的、テスト可能、計測可能、ユーザーニーズに沿う、包括的というベストプラクティスを体現しています。これらの条件は、リセットのリクエストからアカウントへの新しいパスワードを使用したアクセスまで、パスワードのリセット機能がユーザーの期待を確実に満たすことを保証するのに役立ちます。

ベストプラクティスに従うと、包括的かつ明確で、ステークホルダーの期待に沿った受け入れ条件を作成できるため、プロジェクトの成功とチーム内のコミュニケーションの改善につながります。

Gherkin構文

Gherkinは主にビヘイビア駆動型開発(BDD)で利用される可読性の高い言語です。Gherkin構文は技術系のステークホルダーにも非技術系のステークホルダーにも理解しやすいフォーマットでソフトウェアの動作を定義し、文書化する構造化された方法を提供します。

GherkinはGiven、When、Then、And、Butなどのキーワードを使用した構文で、CucumberやSpecFlowなどのツールを使用して自動テストに変換可能な方法でシステムの動作を記述します。

明確でBDDの原則に合ったGherkinは広く利用されていますが、アジャイルチームは他のフォーマットやツールを使用して受け入れ条件を定義することもできます。チームによって、シンプルなユーザーストーリー、詳細なチェックリスト、プレーンテキストでの説明、プロジェクトのニーズに合わせた固有のテンプレートなどが使用されることがあります。

結局のところ、受け入れ条件をどのように定義し、文書化するかは、チームの好みやプロジェクトの性質、利用できるツール、チームの技術的知見のレベルなどに依存します。

Gherkinでの受け入れ条件の作成

次の例は、ユーザー認証などの簡単な機能の受け入れ条件をGherkinフォーマットで作成する方法を示しています。

例は以下のように作成されています。

Featureは対処の全般的な機能を定義します。
Scenariosはユーザーのログインに関連する特定のインスタンスまたは動作を説明します。
Given、When、Then、Andはシナリオのステップの概要を記述するためのキーワードです。これらは対象機能の初期コンテキスト、アクション、期待される結果を表現します。

シナリオは機能が何をするべきかのドキュメントとして、また自動テストの基盤としての役割を果たします。Gherkin構文を解釈できる自動テストツールは、これらのシナリオを実行可能なテストに変換し、アプリケーションが指定どおり動作しているかを検証できます。

これはGherkinフォーマットで受け入れ条件を作成する方法の一例です。機能の複雑さやプロジェクト固有のニーズに応じて、この構造を調整したり拡張したりできます。

受け入れ条件を文書化するためのツール

受け入れ条件の文書化と管理に有効なツールもあります。

Jira: Jiraは広く利用されているプロジェクト管理ツールであり、カスタマイズ可能なワークフロー、課題トラッキング、リアルタイムのコラボレーションによって作業の管理を支援します。Jiraのコラボレーションに関する強みは一元化されたプロジェクト情報にあり、チームメンバー間のコミュニケーションを促進するとともに、プラットフォーム内でユーザーストーリーおよび受け入れ条件を作成することも可能であり、複数チームメンバーにわたる作業アイテムの進捗状況を明確に可視化します。
Confluence: Jiraとともに利用されることも多いConfluenceは、プロジェクト文書の作成、分類、議論に利用されるコラボレーションが容易なワークスペースツールです。Confluenceは受け入れ条件、ユーザーストーリー、その他のプロジェクト関連情報を文書化し共有する一元化されたプラットフォームとして機能します。
TestRail: TestRailはソフトウェアテスト作業の整理、管理、追跡を支援するテスト管理ツールです。TestRailは受け入れ条件の作成と直接的には関連しませんが、課題トラッキングツールで作成された受け入れ条件と直接的にリンクされたテストケースを作成し、管理することができるため、テストカバレッジの追跡と確保が容易になります。
Trello: もう１つの一般的に利用されるプロジェクト管理ツールがTrelloです。Trelloでは、コラボレーションが容易なかんばんスタイルのボードで、ユーザーストーリーを記載したカードおよび関連する受け入れ条件を作成できます。

どのツールを利用する場合でも、すべてのチームメンバーが受け入れ条件文書にアクセスし、新しい洞察が得られたり、プロセスが発展したときに更新することが可能であるべきです。

受け入れ条件とテストフェーズ

受け入れ条件はあらゆるステージでソフトウェアテストをガイドします。次の表は、受け入れ条件とソフトウェア開発のさまざまなテストフェーズの関係をまとめたものです。

テストフェーズ	受け入れ条件の役割
テスト計画	– テスト計画および戦略の作成の基礎になります。 – 何をテストするべきかを識別するのに役立ちます。
テスト設計	– テストケースおよびシナリオの設計の参考資料になります。 – 各条件がテスト条件になります。
テスト実行	– 実装された機能を検証するための基礎になります。 – テスターはテスト実行時に条件が満たされているかを確認します。
欠陥レポート	– 条件からの逸脱を欠陥または問題として文書化します。 – 期待される動作と実際の結果の不一致を捕捉するのに役立ちます。
検証	– ソフトウェアを期待値と比較して検証するためのベンチマークとして機能します。 – ソフトウェアが顧客の要件を満たしているかを判断します。
レグレッションテスト	– レグレッションテストの指針となり、新しい変更が達成済みの要件に影響を与えていないかを確認します。 – 再検証が必要な領域を識別するのに役立ちます。

テストケースの作成と受け入れ条件

テストケースの作成は、受け入れ条件に多くを依存しています。受け入れ条件は、テスターがテストケースの設計、実行、検証に使用する必須のガイダンス、構造、詳細を提供し、ソフトウェアが期待される水準や要件を満たしていることを確認するのに役立ちます。

サンプルを検討してみましょう。

受け入れ条件:

E-コマースプラットフォームの購入機能の受け入れ条件には以下のようなものがあるでしょう。

ユーザーはカートにアイテムを追加できる必要がある。
ユーザーはカートから購入に進むことができる必要がある。
購入処理中、ユーザーは配送先および請求情報を入力する必要がある。
ユーザーは支払い方法を選択できる必要がある。
支払いが成功した後、ユーザーは注文の確認を受け取る必要がある。

テストケースの作成:

受け入れ条件を利用すると、購入処理の機能を検証するテストケースを設計できます。

テストケース 1: カートへのアイテムの追加
1. 手順: 製品ページに移動 > アイテムをカートに追加
2. 期待される結果: アイテムがカートに追加されること
テストケース 2: カートから購入に進む
1. 手順: カートから「Proceed to Checkout」をクリックする
2. 期待される結果: ユーザーが購入ページに移動すること
テストケース 3: 配送先および請求情報の入力
1. 手順: 配送先および請求情報の詳細を入力する
2. 期待される結果: 情報が入力され、保存されること
テストケース 4: 支払い方法の選択
1. 手順: 支払い方法を選択する（クレジットカード、PayPalなど）
2. 期待される結果: 正常に支払い方法が選択されること
テストケース 5: 注文の確認
1. 手順: 支払いを完了する
2. 期待される結果: ユーザーが確認メッセージまたはE-mailを受信すること

このシナリオでは、受け入れ条件は購入処理に期待される概要レベルでの要件および機能を定義し、それらの条件からテストケースが導かれ、条件の各側面を検証するための具体的な手順および期待される結果を説明します。

各テストケースは特定の条件に対応し、システムが条件で指定されたとおり動作していることを保証します。これらのテストケースを実行し、実装された購入機能が受け入れ条件で説明されたユーザーの期待を満たしていることを検証します。テスト時に見つかった不一致は欠陥として記録され、欠陥に対処し、ソフトウェアと定義済みの条件を一致させるためのフィードバックループを開始させます。

受け入れ条件を検証する方法

受け入れ条件は開発プロセスがユーザー要件を満たしていることを確認しますが、条件の定義が不適切だった場合はどうなるでしょうか？

受け入れ条件のあいまいさに対処する

受け入れ条件が明確でないと、開発された機能がユーザーのニーズを満たさず、開発期間が延びたり、デリバリーが遅れたり、ソフトウェア製品が顧客を満足させないといった事態につながる可能性があります。

たとえば、不適切なオンライン支払システムの受け入れ条件の定義は次のようなものです。「顧客はオンラインで支払いできること」

この文には、手順、結果、デリバリー時間に関するより詳細な情報を含める必要があります。

反対に、適切に定義された受け入れ条件はつぎのようなものです。「顧客が購入するアイテムを選択し、有効な支払い情報を入力した場合、顧客は購入を確定したらすぐに確認メッセージおよびE-mailを受け取る必要がある」

明確さと完全性の確保

INVEST条件は、アジャイルソフトウェア開発でユーザーストーリーを評価し、適切なユーザーストーリーを作成するためのガイドラインです。これらの条件は主にユーザーストーリーに使用されますが、受け入れ条件の有効性を確保するための検証に応用することも可能です。INVESTメソッドの適用方法は次のとおりです。

Independent（独立）: 条件は独立していなければなりません。
Negotiable（交渉可能）: 条件は自由な議論と調整が可能であるべきです。
Valuable（有意義）: 条件は意味のある価値を生み出す必要があります。
Estimable（見積可能）: 条件を満たすために必要な見積作業量が明確で現実的であるべきです。
Small（小規模）: 条件は具体的で管理が容易であるべきです。
Testable（テスト可能）: 条件はテストによって検証可能であるべきです。

たとえば、E-コマースWebサイトの機能を開発しているとします。機能にはショッピングカート内のアイテムの総額を計算および表示が含まれます。

Independent（独立）: 合計金額機能の受け入れ条件は他のモジュールに依存するべきではありません。たとえば、この機能が出荷モジュールに依存するべきではありません。
Negotiable（交渉可能）: 条件は自由な議論と調整が可能であるべきです。価格ルールが変更された場合、条件を調整できなければなりません。
Valuable（有意義）: 正確な合計金額はエンドユーザーにとって非常に有用であるため、この例は「Valuable」の条件を満たします。
Estimable（見積可能）: チームは合計金額の計算にかかる作業を正確かつ現実的に見積もることができなければなりません。
Small（小規模）: 条件はできるだけ具体的で、税金と値引きを考慮した合計金額の計算などの特定の動作にフォーカスするべきです。
Testable（テスト可能）: 条件はテスト可能で、合計金額が常に正確に計算されることを保証できるべきです。

INVESTメソッドを適用すると、明確で管理が容易な、顧客に価値を届けるというアジャイル原則に適った条件を作成するのに役立ちます。