Open10

受け入れテストってなあに

Test
ちあきちあき

システムや機能が要件を満たしているかを確認するテスト

ちあきちあき
  • 期待通りに動くか確認する
  • リリース前にOKを出す判断材料にする
ちあきちあき

どんなテストやるの？

  • ユーザー目線でのシナリオベース（例：商品をカートに入れて購入できるか）
  • 細かいコードのバグ検出というより、全体の動作確認
  • 「仕様通りに動いてるか？」ではなく「使って困らないか？満足できるか？」が焦点になることもある
ちあきちあき

ジャンル的にはE2Eテストが近いけど、自分で操作してチェックすることもある。さもありなん

ちあきちあき

受け入れテストの例

  1. ユーザーが商品を検索できる
  2. 商品詳細ページに画像・説明・価格が表示されている
  3. カートに入れて、支払いが完了する
  4. 購入後に確認メールが届く
ちあきちあき
  1. 「これができればOK」という条件（＝受け入れ基準）を明確にする
  2. シナリオ形式でテストを書く
    • 自動化はPlaywrightでやるのがよさそう
No シナリオ 操作 期待される結果
1 商品を検索 「靴」で検索 靴が含まれる商品一覧が表示される
2 カートに追加 商品を選択し「カートに追加」 カートに商品が入る
  1. テストを実施する
    • 実際に画面操作（自動でも手動でも） or 成果物の確認
  2. 結果を記録する
  3. 合否を判断・承認する
ちあきちあき

ユニットテストより結合テストとかの方が比重高そうだな〜合ってるかな〜

ちあきちあき

合ってるっぽい。

✅ 受け入れテストは「ユーザー目線」だから…

◾ ユニットテスト（単体テスト）は対象外になりがち

  • ユニットテストは、 部品（1つの関数やコンポーネント）が正しいか？ を確認するもの
  • 受け入れテストでは、 「その部品が正しくても全体が動かなきゃ意味ない」 という判断になる
  • だから、ユニットテストの結果だけでは受け入れ判断できない

◾ 結合テスト・E2Eテストの方が重要

  • ユーザーが体験するのは「画面全体」や「一連の操作フロー」なので、
    • コンポーネント同士のつながり（結合テスト）や
    • アプリ全体の動作（E2Eテスト）
      を見る必要がある
  • 例：
    • ログイン後にマイページに遷移できるか
    • カート追加 → 注文完了メール送信の一連の流れが成立しているか

受け入れ基準の一部をユニットテストでカバーすることもある。

ちあきちあき

「何を作れば完成か」がブレなくなる。ユーザー要求に強くフォーカスできる。

→受け入れ駆動開発（ATTD）「受け入れテストを先に書いて、それを満たすように実装する」