検索・一覧機能のテスト観点｜事故る8領域の確認項目

2026 9/03

2026年9月3日 2026年9月3日

検索フォームと一覧画面は、ほぼすべての業務システムに存在します。キーワードを入れれば結果が返り、一覧はスクロールできる。開発中にひととおり触れば「問題なく動いている」ように見えるため、テストの優先度は下がりがちです。

しかし本番で事故が起きるのは、まさにこの「動いて見える」機能です。データが1件もないときに画面が崩れる、絞り込んだはずが古い結果が残る、他の顧客のデータが一覧に混ざる、画面の件数とダウンロードしたファイルの件数が合わない。

少人数で複数の受託案件を並行して回し、テストをエンジニアが兼任している体制では、こうした観点はレビューの網からこぼれやすいものです。

この記事では、ドメインに依らず普遍的に使える検索・一覧機能のテスト観点を、8つの領域のチェックリストとして整理します。個別の実装ではなく「どこを見れば抜けを防げるか」という判断軸に絞ってお伝えします。

なぜ「動いて見える」検索・一覧機能ほどテストで抜けるのか

検索と一覧は、どの案件にも必ず登場する定番機能です。定番であるがゆえに「いつもと同じ」と見なされ、正常系がすぐ動くことで安心してしまいます。ここに落とし穴があります。

正常系が動くと「テスト済み」と錯覚する

開発環境では、投入されるデータはせいぜい数件から数十件です。その状態で検索すれば結果は返り、一覧も1ページに収まります。この「動いている画面」を見た瞬間に、頭のなかで機能全体が検証済みに書き換わってしまいます。

実際に検証できているのは、ごく限られた条件の正常系だけです。0件のとき、数万件のとき、権限の異なるユーザーが見たときの挙動は、まだ一度も確認されていません。

正常系が動くことと、機能がテストされていることは、まったくの別物です。

検索・一覧の事故は本番の実データ量・実権限で初めて出る

検索・一覧の不具合は、実データの量と実際の権限構成がそろって初めて表面化します。開発環境で再現しないのは、データが少なく、テスターが管理者権限で全件を見ているからです。

データ量: 開発は少数、本番は数千〜数万件。ページングや性能は本番で初めて試される
権限: 開発は全件見える管理者。本番は担当者ごとに見える範囲が異なる
入力の幅: 開発は想定内の綺麗な値。本番は全角・半角・空白・記号が混在する

これらの差分がある限り、「開発で動いた」は「本番で動く」を保証しません。

PMに必要なのは網羅ではなく「抜けを見抜く軸」

検索・一覧のテストケースを網羅的に書き出そうとすると、条件の組み合わせは膨大になり、兼任体制では現実的に回りません。管理する立場に必要なのは、すべてを列挙することではありません。

必要なのは、レビューの場で「この観点は確認したか」と問える軸を持つことです。網羅ではなく、抜けを見抜く。次章から示す8領域は、そのための共通言語になります。

検索・一覧機能のテスト観点を8領域で捉える（全体像）

ここが記事の背骨です。散らばりがちな確認項目を、8つの領域に整理します。まず全体像を一覧で示します。

#	領域	何を確認するか	事故りやすさ
①	件数の境界	0件・1件・大量件数・ページング境界での表示	中
②	ページング	末尾ページ・端数・遷移時の状態	高
③	ソート	並び順の正しさ・ページングとの組合せ	中
④	絞り込み条件	AND/OR・範囲・部分/完全一致・状態の保持	高
⑤	入力の揺れ	全角半角・空白・特殊文字・不正入力	中
⑥	権限・スコープ	ユーザーごとの表示範囲の混在	高
⑦	性能・大量データ	表示耐性・応答時間・タイムアウト	中
⑧	集計・エクスポート整合	画面表示と件数・合計・出力の一致	高

「件数の状態」という軸で境界を捉え直す

8領域の多くは「今、何件が、どの条件で表示されているか」という状態に集約できます。0件なのか、全件なのか、絞り込み後の一部なのか。この「件数の状態」を軸に置くと、境界の抜けが見えやすくなります。

検索・一覧のバグの多くは、件数と状態の境界に潜んでいます。

特に事故りやすい4領域

8つのうち、本番トラブルに直結しやすいのは次の4領域です。この記事では、この4つを重点的に掘り下げます。

②ページング: 末尾や端数のページで表示が崩れる
④絞り込み条件: 条件を変えたのに前の状態が残る
⑥権限・スコープ: 見えてはいけないデータが混ざる
⑧集計・エクスポート整合: 画面とファイルで件数が合わない

件数の境界を確認する（0件・1件・大量・ページング境界）

0件・1件・複数件・大量件数・ページング境界という件数の状態で検索・一覧の境界を捉えるマップ

まず取り組むべきは、件数の境界です。ここは技法として体系化されており、確認項目に落としやすい領域です。

0件・1件は必ず別ケースとして確認する

「該当なし」は正常系の一部です。それでも、0件は独立したテストケースとして必ず確認します。0件のときに起きやすい不具合は次のとおりです。

「該当するデータがありません」の表示が出ず、空の表がそのまま残る
ヘッダーや集計行だけが表示され、レイアウトが崩れる
件数表示が「0件」ではなく空欄やエラーになる

1件だけのケースも別に確認します。合計行や「N件中1〜1件」といった表示、単数・複数の表記が破綻しないかを見ます。

0件・1件・多数は、それぞれ独立したケースとして必ず分けて確認します。

ページング境界（末尾・端数・±1件）の落とし穴

ページングは、境界値分析がそのまま効く領域です。1ページの表示件数を基準に、その前後で挙動が変わります。表の右列は「期待する正しい振る舞い」を確認内容として書き出したものです。

確認する境界	具体例（1ページ20件の場合）	確認内容（期待結果）
割り切れる件数	ちょうど40件（2ページ）	割り切れる件数のとき余分な空ページが生成されないか
端数のある件数	41件（3ページ目に1件）	末尾ページが正しく1件だけ表示されるか
境界±1件	19件・20件・21件	1ページ目/2ページ目の切替が正しく行われるか
末尾ページ	最終ページ	末尾ページで「次へ」が無効化されるか

こうした件数境界の技法をより深く体系立てて理解したい場合は、境界値分析のやり方と実務での使いどころもあわせて参考にしてください。境界の考え方は、JSTQB のシラバスでも基本技法として位置づけられています（JSTQB シラバス）。

大量件数での表示耐性を確認する

大量件数では、まず表示そのものが破綻しないか（表示耐性）を見ます。数万件がすべて描画されて画面が固まらないか、件数表示が「999+」のように省略される仕様なら、その省略が意図どおりかを確認します。

自社案件に当てはめるときは、件数の桁感でざっくり見当をつけると判断が速くなります。おおまかには、数百件までは表示崩れが中心の論点で、数千〜数万件からページングと応答速度が主な論点になります。

想定最大件数を1つ決め、その値を基準に境界を引いてから確認すると、大量データの観点が現実的な範囲に収まります。

大量件数の応答性能は「表示耐性」と切り分ける

大量データの観点は、表示耐性と応答性能の2つに切り分けて考えます。表示が崩れなくても、結果が返るまで数十秒かかれば実務では使えません。応答性能では、次の判断軸を持っておきます。

応答時間の目安: 検索結果が返るまでの許容時間を事前に決めているか
タイムアウト: 時間超過時にエラーで止まるのか、無応答で固まるのか
集計・並べ替えの負荷: 大量件数での件数集計（COUNT）やソートが極端に重くならないか
深いページの劣化: 後方の深いページ（大きなオフセット）ほど応答が遅くならないか

ここではあくまで「何を確認するか」という判断軸に留めます。SQLの書き方といった実装の是正には踏み込まず、遅い・止まるという症状を拾える観点を持つことが目的です。

件数表示のフォーマット崩れも見落とさない

件数そのものは正しくても、その「見せ方」で事故ることがあります。数字の表示フォーマットは、件数が大きくなって初めて破綻するため、少数データの開発環境では気づけません。

桁区切り: 「1234件」なのか「1,234件」なのか、カンマ区切りが仕様どおり入るか
概数表示: 「1000件以上」「999+」のように丸める仕様なら、その閾値の前後で表示が正しく切り替わるか
単数・ゼロ: 「0件」「1件」「1件中0〜0件」など、単数やゼロのときに文言が崩れないか

これらは軽微に見えますが、顧客に見せる画面では「数字がおかしい」という印象に直結します。件数の境界を確認するときは、値の正しさと表示フォーマットの両方を同時に見ておきます。

絞り込み・ソート・ページングの「状態の絡み合い」を確認する

操作ごとにページ番号・ソート順・絞り込み条件をリセットするか保持するかを整理したマトリクス

ここが、他の観点と差がつく核心です。絞り込み・ソート・ページングは単独では動いても、組み合わさった瞬間に状態が絡み合って崩れます。この相互作用こそ、最も見落とされやすい領域です。

絞り込み条件変更時にページはリセットすべきか

3ページ目を見ている状態で絞り込み条件を変えたとき、ページ番号はどうなるべきでしょうか。1ページ目に戻すのが自然ですが、これが実装されていないと「3ページ目のまま、しかし新しい条件では2ページしかない」という状態になり、空のページや古い結果が表示されます。

条件変更でページ番号は1に戻るか
条件変更で件数表示は更新されるか
変更前の結果が一瞬でも残らないか

絞り込み条件を変えたときに「前の状態が残る」不具合は、本番で最も多いパターンの一つです。

ソート×ページング×絞り込みの組合せで崩れる

3つの機能の組み合わせは、条件の掛け算で挙動が変わります。どの組み合わせで何を確認すべきかは、判定表（デシジョンテーブル）で整理すると抜けが見えます。

操作	ページ番号	ソート順	絞り込み条件
ソート変更	1に戻す	変更後	保持
絞り込み変更	1に戻す	保持	変更後
ページ移動	変更後	保持	保持

この「保持するか・リセットするか」の組み合わせを表で洗い出す手法は、判定表を使ったテストの進め方で詳しく扱っています。条件の掛け合わせが多い画面ほど、判定表による整理が効きます。

ソート順そのものの正しさ（NULL・同値・型の混在）

ソートは「昇順・降順が切り替わるか」だけを見て終わりにしがちですが、崩れやすいのは順序の中身です。次の3点は、開発環境の綺麗なデータでは表面化しません。

NULL・空値の位置: 値が未設定のレコードが、先頭に来るのか末尾に来るのか、仕様で決まっているか
同値のタイブレーク: 並べ替えキーが同じ値のとき、順序が毎回変わらないか（安定ソートになっているか）
型の取り違え: 数値項目が文字列として並び、「10」より「2」が後ろに来るような比較になっていないか

とくに同値のタイブレークが未定義だと、同じ条件で開いても並び順が毎回変わり、ページングと組み合わさったときに同じレコードが2ページに現れる・抜けるという不具合につながります。ソートは「向き」だけでなく「順序の一意性」まで確認します。

選択状態・スクロール位置は保持すべきか

一覧でチェックボックスを選んでからページを移動したとき、選択は保持されるべきか。ソートし直したとき、選んだ行の選択はどうなるか。この仕様が曖昧なまま実装されると、一括操作で「選んだつもりのない行」が処理される事故につながります。次の点を仕様として確定しておきます。

ページ移動後も選択は保持されるか、ページごとにリセットされるか
絞り込みで一覧から消えた行の選択は、内部的に残り続けていないか
「全選択」は現在のページ分か、絞り込み後の全件か
選択したまま条件を変えて一括操作したとき、対象は利用者の意図どおりか

とくに「全選択」の対象範囲は誤解を生みやすく、数千件を一括削除するような操作では、意図の取り違えが重大な事故に直結します。

入力の揺れと権限による表示範囲を確認する

検索キーの受け取り方と、誰に何を見せるかは、性質の異なる2つの観点です。混同せず切り分けて確認します。

検索キーの揺れは同値クラスで整理する

利用者は、開発者が想定した綺麗な文字列を入れてくれません。同じ意味の検索でも、入力の表記は揺れます。全角半角・前後の空白などは、それぞれ同値クラス（同値分割）として整理し、各クラスの代表値でテストすると、少ないケースで揺れを押さえられます。

全角/半角: 「ABC」と「ＡＢＣ」、「123」と「１２３」で同じ結果になるか
前後の空白: コピー&ペーストで混入する空白を除去（トリム）するか
特殊文字: 記号や絵文字を入れてもエラーにならないか
一致方式: 部分一致か完全一致か、仕様どおりか

件数の境界が境界値分析の対象であるのに対し、入力の揺れは同値分割の対象です。件数は境界値で、入力は同値クラスの代表値で、と対応づけて考えると設計がぶれません。

検索キーの表記ゆれは「バグではなく仕様の曖昧さ」であることが多く、事前の確認が欠かせません。

複数キーワード・空検索・上限の扱いを決める

単一のキーワードだけでなく、複数語や空の検索も現場では日常的に発生します。ここは仕様が曖昧なまま実装されやすく、利用者ごとに期待がずれる箇所です。

複数キーワード: スペース区切りの語をAND条件で扱うのか、OR条件で扱うのか
空検索: 何も入力せず検索したとき、全件を返すのか、エラーにするのか、何もしないのか
入力の上限: 極端に長い文字列を入れたとき、上限で切るのか、エラーにするのか

これらは「どれが正解」という話ではなく、仕様として明示されているかが論点です。決めていないと、利用者は空検索で全件が出ることを期待し、開発者はエラーを返す、といった食い違いが本番で表面化します。

機能テストとセキュリティテストの切り分け

特殊文字の入力には、2つの目的が混在します。ここを切り分けないと、テストの狙いがぼやけます。

観点	目的	確認すること
機能テスト	正しく動くか	記号を含む語で正しく検索できるか、エラーにならないか
セキュリティテスト	悪用されないか	不正な入力で情報漏洩や誤動作が起きないか

セキュリティ面は専門的な検証が別途必要な領域です。この記事では攻撃手法には踏み込みませんが、「機能として壊れないか」と「悪用に耐えるか」は別のテストとして計画すべき、という切り分けだけ押さえておきます。

権限・スコープによる表示範囲の混在の確認

最も顧客信頼に直結するのが、権限による表示範囲です。事故は2方向で起きます。

見えてはいけないデータが見える: 他の担当者・他組織のデータが一覧や検索結果に混ざる
見えるべきデータが見えない: 自分の担当データが絞り込みで除外されてしまう

権限の異なるユーザーごとに「何件見えるべきか」を事前に決め、実際の表示件数と突き合わせます。ただし、件数の一致は一次スクリーニングに過ぎません。件数が合っていても、中身が別テナントのデータということはあり得ます。

判定の基準（オラクル）は、返却された全レコードの帰属（テナント・所有者）が、そのユーザーの権限とすべて一致しているかどうかに置きます。

この観点は、機能を横断して確認する必要があるため、ECサイトのテスト観点のような機能横断の視点もあわせて持っておくと抜けを減らせます。

一覧と集計・エクスポートの整合を確認する

同じデータ源から画面・エクスポート・集計へ分岐する際に絞り込みや権限フィルタの抜けで件数がズレる構造図

画面に表示された一覧と、その件数表示・合計値・ダウンロードしたファイルは、同じ範囲・同じ権限を反映していなければなりません。ここがズレると、数字を扱う業務では致命的です。

件数表示・合計値は「今の絞り込み」を反映しているか

「該当123件」「合計¥45,000」といった表示が、絞り込み前の全件を指しているのか、絞り込み後を指しているのかを確認します。よくある不具合は次のとおりです。

一覧は絞り込み後だが、件数表示は絞り込み前のまま
合計金額が、現在の絞り込み条件を反映していない
ページングされた一覧で、合計が「今のページ分」なのか「全件」なのか曖昧

件数と合計は「今、何が絞り込まれているか」を必ず反映しているかを確認します。

エクスポートは画面と同じ範囲・同じ権限か

エクスポート（CSV・Excel出力）は、画面とは別の処理で作られることが多く、そこにズレが生まれます。

確認項目	事故の例
件数の一致	画面は絞り込み後20件、CSVは絞り込みを無視して全件
権限の一致	画面には出ない他組織のデータが、CSVには含まれる
ページングの扱い	画面は1ページ分、出力は全ページ分（これは仕様確認が必要）

とくに権限外データの混入は、画面で気づけないため発覚が遅れ、情報漏洩につながります。エクスポートは画面と同じフィルタ・同じ権限を通っているかを、必ず独立に確認します。

集計・帳票との突き合わせで発覚するズレ

一覧の件数と、月次集計や帳票の数字が合わない。この不一致は、どちらかがバグである明確なサインです。品質を数字で語るうえでも、こうした整合性の確認は重要です。ソフトウェアの品質を定量的に捉える観点は、IPA のソフトウェア開発分析データ集のような公的データも参考になります。

表示のスナップショット性（更新との時間差）

一覧を表示した瞬間と、次のページへ移動した瞬間の間に、他の利用者がデータを追加・削除することがあります。この時間差を考慮していないと、件数と中身がずれます。

ページ移動の間にデータが増減し、同じレコードが次ページにも現れる、あるいは飛ばされる
「全123件」と表示したまま、エクスポート時には124件が出力される
集計値を先に計算し、明細を後から取得したことで、合計と明細の合計が合わない

厳密な一貫性を常に求める必要はありませんが、「件数と明細がどの時点のスナップショットか」を仕様として意識しておくと、こうしたズレを想定内に収められます。

検索・一覧機能のテスト観点の抜けを防ぐレビューの進め方

観点をそろえても、案件ごとに使える形にしなければ意味がありません。8領域を「観点表」として運用に組み込む手順を示します。

全画面に全領域を機械的に適用しない

まず前提として、8領域すべてを全画面に一律で適用する必要はありません。少人数の兼任体制でそれをやろうとすると、現実には回りきりません。各領域を「起きたときの実害の大きさ × 手戻りの重さ」で相対的に格付けし、重い領域から優先度を付けます。

全画面で必須: 他顧客データの混在（⑥権限）、件数境界（①）。実害が重く、漏洩や表示破綻に直結する
主要な検索画面に絞る: ソート×ページングの組合せ（②③）。影響は限定的で、対象画面を絞れる
仕様確認で足りる: 大量件数の応答性能（⑦）。想定件数が小さい画面では軽く済ませてよい

どの画面でどの領域を省略してよいかは、実害の重さで判断します。軽い領域を主要画面以外で省くことは、手抜きではなく合理的な配分です。

まず観点表テンプレートとして最小着手する

毎回ゼロから考えず、8領域を固定のテンプレートとして持ちます。最小の着手は、既存のテスト仕様書に「件数・状態・範囲・整合」の4軸の列を足すだけです。新しい管理表を起こす必要はありません。

件数の境界: この案件のページ表示件数は何件か
権限・スコープ: どの権限が、どこまで見えるべきか
整合: 一覧・件数・エクスポートで同じ範囲か

この最小着手なら初手のコストが低く、上長にも「既存の仕様書に列を足すだけ」と費用対効果を説明しやすくなります。観点の洗い出しを体系的に進める手順そのものは、テスト観点の洗い出し手順で扱っています。

仕様が曖昧な項目を事前に確定する

検索・一覧の事故の多くは、バグではなく「仕様が決まっていなかった」ことに起因します。実装前に、次の3点を必ず決めておきます。

決めるべき項目	曖昧なまま進むと起きること
保持/リセットの仕様	条件変更で状態が残る/消える不具合
権限マトリクス	表示範囲の混在・漏洩
実データ量の想定	本番でのページング・性能崩れ

検索・一覧の不具合は、テストで見つける前に「仕様の曖昧さを潰す」ことで多くを防げます。

抜けやすい観点はスポットで第三者に頼る

兼任で開発とテストを同じ人が担うと、自分の想定の外側は見えにくくなります。とはいえ、社内にレビューを頼める別メンバーがいない現場も多いはずです。

その場合は、全体を任せる必要はありません。抜けやすい2〜3領域（たとえば権限・スコープと、集計・エクスポート整合）に絞って、そこだけをスポットで第三者に見てもらう小さな始め方があります。まず一番怖い領域だけ客観的に点検してもらう、という使い方です。

検索・一覧機能のテスト観点に関するよくある質問

最後に、現場で質問の多いポイントを整理します。

Q. 0件時の表示はどうテストすればよいですか？

A. 0件は正常系の一部ですが、独立したケースとして必ず確認します。「該当なし」のメッセージが出るか、空の表やヘッダーだけが残ってレイアウトが崩れないか、件数表示が「0件」と正しく出るかを見ます。検索条件を意図的に厳しくして0件を作るのが基本の手順です。

Q. ページング境界はどこを見ればよいですか？

A. 1ページの表示件数を基準に、その前後を重点的に見ます。割り切れる件数で余分な空ページが出ないか、端数のある件数で末尾ページが正しく表示されるか、最終ページで「次へ」が無効になるかが要点です。境界値分析の考え方がそのまま使えます。

Q. 一覧とエクスポートの件数がずれるのはなぜですか？

A. エクスポートは画面表示とは別の処理で作られることが多く、絞り込み条件や権限フィルタが反映されずに全件出力されるためです。画面と同じ範囲・同じ権限を通っているかを、独立したケースとして必ず確認します。

Q. ソートのテストで見落としやすい点はどこですか？

A. 昇順・降順の切り替えだけを確認して終わることです。値が未設定（NULL）のレコードがどこに並ぶか、同じ値のときに順序が毎回変わらないか（安定性）、数値が文字列として並んでいないかまで見ます。とくに順序が毎回変わると、ページングと組み合わさったときにレコードの重複や抜けが起きます。

Q. 少人数の兼任体制でも全領域をテストすべきですか？

A. 全画面に全領域を機械的に適用する必要はありません。他顧客データの混在や件数境界のように実害の重い領域は全画面で必須とし、組合せの多い領域は主要な検索画面に絞るなど、リスクの重さで優先度を付けて省略の可否を判断します。

まとめ：検索・一覧は「件数・状態・範囲・整合」の4軸で見る

8領域は多く見えますが、突き詰めると4つの軸に圧縮できます。この4軸を観点表の見出しにすれば、今日から使えます。

軸	対応する領域	ひとことで言うと
件数の境界	①件数 ⑦性能（表示耐性）	0件・端数・大量で崩れないか
状態の絡み合い	②ページング ③ソート ④絞り込み	条件変更で前の状態が残らないか
表示範囲	⑤入力 ⑥権限	誰に何が見えるべきか
整合	⑧集計・エクスポート	画面と数字・出力が一致するか