問題38：ユーザーストーリーと受け入れ基準のレビュー
問題 #38
Section titled “問題 #38”Easytravelは、バスや地下鉄の乗車料金の支払いに使用されるカードです。ユーザーはEasytravel入金機（Loading Machines）でカードにクレジットをチャージし、バスや地下鉄の駅でカードリーダーにカードをかざすと、システムが自動的に乗車料金を差し引きます。
あなたはEasytravelプロジェクトチームのメンバーであり、以下のユーザーストーリーをレビューのために渡されました。
USER STORY: Easytravelカードへのクレジットの追加 Priority (優先度): 1
As a bus passenger, I want to add credit to my Easytravel card so that I can pay for bus rides using the card
<役割>として: バス乗客として、<機能・要望>したい: Easytravelカードにクレジットを追加したい、<目的・理由>のために: カードを使ってバスの運賃を支払えるようにするため
【FEATURE（機能）】
| Action（アクション） | Acceptance Criteria（受け入れ基準） |
|---|---|
| ユーザーがEasytravel入金機のカードリーダーにEasytravelカードを入れる。 | 入金機は、カード残高に資金をチャージ（トップアップ）するオプションを表示する。 |
| 入金機がカードの認証情報をチェックする。 | 無効な場合はカードが拒否される。 |
| ユーザーが「カードにチャージする」を選択する。 | 入金機が準備完了状態になる（Loading machine is ready）。 |
| ユーザーが1枚以上の紙幣を入れる。 | 入金機は、投入された紙幣に応じてカード残高の増加を表示する。 |
| 入金機がバックエンドシステムに連絡し、更新を行う。 | バックエンドシステムが更新される。 |
| ユーザーが「終了」を選択する。 | ユーザーにEasytravelカードを取り出すよう促すメッセージが表示される。 |
優れたユーザーストーリーのための以下のチェックリストを検討してください。このユーザーストーリーに関して、 達成されていない（NOT achieved） 基準はどれですか？（※2つ選択してください）
- a) ストーリーは完全にそれを要求する人（ユーザー）の視点から書かれているか？
- b) 機能は明確に定義され、区別されているか？
- c) 受け入れ基準は定義されており、テスト可能か？
- d) ストーリーは優先順位付けされているか？
- e) ストーリーは一般的に使用されるフォーマットに従っているか？
a) ストーリーは完全にそれを要求する人（ユーザー）の視点から書かれているか？
c) 受け入れ基準は定義されており、テスト可能か？
この問題は、アジャイル開発におけるユーザーストーリーと受け入れ基準の品質を評価する能力を問うています。
- a) 正解（達成されていない）。 ストーリー（特にActionの列）が完全にユーザーの視点から書かれていません。「入金機がカードの認証情報をチェックする」「入金機がバックエンドシステムに連絡する」といった、ユーザーには直接見えないシステム（機械）側の内部処理が含まれてしまっています。
- b) 不正解（達成されている）。 クレジットを追加するという機能（Feature）自体は明確に定義され、他の機能から独立しています。
- c) 正解（達成されていない）。 「入金機が準備完了状態になる（Loading machine is ready）」という受け入れ基準はテスト不可能です。「何をチェックすれば準備完了と言えるのか」が明記されていないためです。（例えば、紙幣の挿入口が点滅するのか？画面に現在の残高が表示されて「紙幣を入れてください」と出るのか？など、具体的に検証可能な状態を記述する必要があります）
- d) 不正解（達成されている）。 ストーリーの冒頭に「Priority: 1」と明記されています。
- e) 不正解（達成されている）。 「As a… I want to… so that…（〜として、〜したい、〜のために）」という、ユーザーストーリーの標準的で一般的なフォーマットに正しく従っています。
JSTQB AL TA試験のアジャイル領域において、ユーザーストーリーの品質基準は非常によく出題されます。「INVEST」の原則を念頭に置きつつ、特に以下の2点に注意してレビューしましょう。
- ユーザー視点の徹底:
ユーザーストーリーの主語は常に「ユーザー（システムを利用する人）」でなければなりません。バックエンドのDB更新処理や、APIの通信状況などをストーリーのアクションに混ぜ込んでしまうのは、現場でもよくあるアンチパターンです。 - テスト可能な受け入れ基準:
前回の問題（問題37）の「不慣れな人でも」と同じように、「準備完了になる」「処理が完了する」といった曖昧な記述はテスト不可能です。テスト担当者は、「テスターが画面上で何を確認できればPASS（合格）にできるか」という視点で受け入れ基準をレビューし、具体化させる責任があります。
INVEST原則 良いユーザーストーリーの要件を表す頭文字です。
- Independent（独立している）
- Negotiable（交渉可能である）
- Valuable（価値がある）
- Estimable（見積もり可能である）
- Small（小さい）
- Testable（テスト可能である） ← 今回の選択肢(c)はここが欠落していました。