受け入れテスト観点の備忘録

バックエンドエンジニアのための受け入れテスト観点集

はじめに

私も含め普段の業務でUI設計や実装に携わる機会の少ないバックエンドエンジニアにとって、受け入れテストで何を確認すべきかは悩ましい問題です。そこでテストの重要な観点を体系的に整理しました。

受け入れテストの位置付け

受け入れテストの目的

• システムがユーザーの要求を満たしているかの最終確認
• 本番環境での実際の使用場面を想定したテスト
• 開発チーム内のテストでは見落としがちな観点の検証

単項目テスト

余白と配置のバランス

UIの品質を左右する重要な要素として、まず余白と配置の統一性を確認します。

余白関連のチェックポイント

• 同じ階層の要素間で余白が統一されているか（例：一覧のカード間隔、セクション間の余白）
• ページの上下左右の余白が適切で、コンテンツが中央に配置されているか
• 同じ属性のインプット要素の配置が統一されているか（例：金額の右揃え）

視覚的階層の明確性

• 重要度に応じて要素の大きさや配置が適切か
• 見出しとコンテンツの関係性が視覚的に理解しやすいか
• ユーザーに提供する情報の優先順位が配置によって表現されているか

デザインの意図を理解する

単に見た目を確認するだけでなく、デザインがユーザーにどのような体験を提供しようとしているかを考えることが重要です。

ユーザビリティの観点

• ユーザーが迷わずに目的の操作ができるか
• 重要なボタンやリンクが見つけやすい位置にあるか
• エラー状態や読み込み中の表示が適切に設計されているか

ユーザー体験の流れ

• 画面遷移が自然であるか
• ユーザーが次に何をすべきかが明確に示されているか
• 操作の結果が適切にフィードバックされているか

アクセシビリティ

• 色だけでなく形や配置、アイコンからも情報が伝わるか
• ホバー、フォーカス等が適切に実装され、表示が適切か

UIの品質チェック

文字や要素の見切れ

• 項目ごとの最大文字数を入力しても見切れないか
• 「g」「j」「p」等の英語小文字のディセンダ部分が見切れないか
• 文字数によって表示エリアが不適切に変化しないか、アイコンが見切れないか

表示ルールの統一性

• 並び順のルールが決まっているか
• 初期値が適切に設定されているか
• 値のリセット機能は適切に動作するか
• 登録、更新、削除時の表示変化が適切か

ユーザー操作への応答

• マウスオーバー時の表示変化が適切か
• スクロール時の動作が適切か
• 押下可能なボタンを全て押した際の動作が正しいか

結合テスト

データ連携の確認

影響範囲の把握

• 登録・更新・削除時に、その影響を受ける箇所が適切に変化するか
• 対象機能が他の機能でどのように使用されているかを確認する

データバリエーションの網羅

• その画面にはどのようなデータが表示される可能性があるかを把握
• 多様なパターンのテストデータを用意することが重要
• 過去の類似機能で発生したバグが再発しないか確認

イレギュラー操作への対応

想定外操作のテスト

• ダブルサブミットへの対処
• ブラウザバック操作への対応
• 排他制御の動作確認

エラーハンドリング

エラーパターンの洗い出し

エラー種類の把握

• その画面で発生し得るエラーの種類を全て洗い出す
• 他の画面の事例や過去のバグ事例を参考にする
• エラーメッセージの表示内容と表示方法が適切か確認
• ユーザーに技術的な詳細が露出していないか

数値・日付データの取り扱い

日付処理の確認

月末処理のテスト

• 「西向く侍」（30日までの月）や2月、閏年の月末処理が適切か
• 日付の加算・減算処理が正しく動作するか

数値処理の確認

数値入力の境界

• マイナス、カンマ、小数点の扱いが正しいか
• 最大桁数を超えた入力への対応が適切か
• 乗算処理で桁あふれが発生しないか
• 桁数の増減に伴う表示の変化が適切か
• ゼロ値の扱いが正しいか

境界値テスト

境界値の特定

数値の許容範囲が1〜10の場合を例に説明します。

0     ← 境界（NG）
-----
1     ← 境界（OK）
...
10    ← 境界（OK）
-----
11    ← 境界（NG）

このように、許容範囲の境界となる値（0, 1, 10, 11）を重点的にテストします。

デシジョンテーブルの活用

作成手順

複雑な条件分岐のテストでは、デシジョンテーブルを作成して組み合わせを網羅します。

1. 条件の洗い出し - テスト対象の条件を全て特定
2. 期待値の洗い出し - 各条件での期待される結果を明確化
3. 組み合わせの作成 - 条件の全組み合わせを作成
4. 全網羅テーブルの作成 - 実際のテストケースに落とし込み
5. 不要ケースの削除 - 発生し得ない組み合わせを除外

注意事項

• 因子と水準の抽出が不適切だとテスト効果が大幅に低下
• 確認したい事柄を明確にしてから作成に取り掛かる

ペアワイズテスト

効率的なテスト手法

全網羅テストは現実的でない場合が多いため、ペアワイズテストを活用します。

メリット

• 全網羅と比較してバグ検出率をほぼ維持しながらケース数を大幅削減
• 専用ツールを使用することで効率的に作成可能

注意点

• 確認したい特定のケースが含まれない可能性
• 実際には発生し得ないケースが含まれる可能性

実施方法

1. テスト対象の条件を特定
2. 各条件の取り得る値を定義
3. ペアワイズテストツールを使用してテストケースを作成
4. 生成されたテストケースから実行不可能なケースを除外

品質向上のための考察

バグの発生工程分析

バグには発生工程があり、それぞれに応じた対策が必要です。

1. 要件定義漏れ - 要件の明確化と関係者間の認識合わせ
2. 影響範囲考慮漏れ - 機能間の依存関係の可視化
3. 動作確認漏れ - テスト観点の体系化
4. 実装ミス - コードレビューの強化
5. テストケース漏れ - 本番で最も多く発生する原因

発生工程の傾向を分析することで、より効果的な品質対策を立案できます。単純にテスト量を増やすだけでは品質は改善されません。

テストデータの重要性

多様なデータパターンの準備

豊富なテストデータを用意することで、想定外のバグを発見できる可能性が高まります。正常系のテストだけでも、データのバリエーションによって潜在的なバグを発見できることがあります。

結果として、充実したテストデータの準備は工数削減にもつながります。

まとめ

バックエンドエンジニアとしては技術的な観点だけでなくユーザー体験の観点を含めて、総合的にテストを実施することを意識することに注力したい。