課題と判断基準

レビュー対象の一覧に「10MBより大きいファイルをアップロードするとエラーが表示される」とあります。正常系・異常系がそろい、文章も自然です。しかし何を送るか、どのエラーか、実際にファイルが保存されないかは分かりません。このままでは誤動作を見逃して合格する可能性があります。

AI生成ケースでは、検証する要件の根拠、制御する条件、観測する結果、不合格の判定基準を先に確認します。期待結果が曖昧ならケースを増やすより質問に戻します。文章ではなく検証内容をレビューする作業です。

本記事のアップロード機能とテスト一覧はすべて設計例です。実際のモデルやQoretixの生成結果、顧客事例、実行成果ではありません。生成ツールの比較ではなく、個々のケースをそのまま使うか、修正するか、要件から確認するかを判断します。

期待結果は誰が決めたのか

実際の結果が正しいかを判断する根拠をテストオラクル（test oracle）と呼びます。承認済み要件、合意した計算規則、検証済み参照結果などが該当します。期待結果を決められなければ実行成功だけで正しい検証とは言えません。ISTQBのTest Analyst指針も明確な合否基準を設け、画面出力だけでなくデータや実行後状態も考慮するよう説明しています。[1]

レビューでは期待結果の横に「なぜ正解なのか」を短く書きます。要件R-UP-01 v1.0の上限を含む規則など根拠があれば次へ進めます。「現在のコードがそう動くから」「AIが一般的な方針と答えたから」だけなら、事業上正しい結果か未確認です。

コードに基づく生成自体を排除する必要はありません。現状を記録して変更差を見つけるテストは有用です。ただし現在の動作を保存するテストと合意要件を満たすか確認するテストを分けます。既知の欠陥を承認済み期待結果に昇格させません。

合意規則がファイルサイズ ≤ 上限で、実装がファイルサイズ < 上限だとします。実装を読んで「上限と同じファイルは拒否」と期待すれば、既存バグを保存します。期待値計算に対象と同じ関数を呼ぶ方法も独立した検出になりません。承認規則から算出した境界値で期待結果を定めます。

サービスの仕組み

要件から承認までつながる根拠 — 要件、テスト、不具合対応、承認記録をつなぎ、共通の基準で品質を判断します。

曖昧な要件はテストではなく質問として残す

「10MBまでアップロード可能」だけでは正確な境界テストは作れません。10MBが10,000,000バイトか、10MiBの10,485,760バイトかを定める必要があります。上限を含むか、制限対象がファイル本体かHTTP要求全体かも異なります。空ファイル、権限、失敗後データの扱いも別方針です。

生成器が空欄を勝手に埋めないよう、要件レビューを確定規則・承認待ち仮定・未決定質問に分けます。例えば次のとおりです。

要件確認記録：設計例
質問Q-UP-01：サイズ上限の単位と上限を含むかどうかは？
決定担当：製品担当とAPI契約担当。
影響ケース：上限直前・上限・上限直後のアップロード。
暫定仮定：10MiB以下を許可。承認前は受入基準にしない。
次の行動：規則と適用版を確定して期待結果を更新。

質問が出ても関連作業をすべて止める必要はありません。単位に依存しないデータ生成や隔離環境の準備は進められます。ただし未決定規則に依存するケースを合格にしてはいけません。要件の曖昧さと製品の欠陥は別状態です。

要件とテストの版を結ぶ構造が必要なら、要件とテストのトレーサビリティ設計を参照できます。ここでは、その関連から見つけた一ケースの判定内容に集中します。

弱いケースを実際に判定できるケースへ変える

先ほどの質問に回答が出たと仮定し、架空のAPI契約を作ります。規則と応答コードは例のための選択であり、すべてのアップロードサービスが従う標準ではありません。

設計例の合意規則R-UP-01 v1.0

編集権限のある利用者は準備済みフォルダにアップロードできます。本体サイズは1バイト以上10MiB以下です。ASCII文字の.txtと正しいメタデータを使い、形式・容量上限・保存障害など別の拒否理由は除きます。

正常時は保存完了後にHTTP 201、空でないfileId、実サイズのsizeBytes、READYを返します。メタデータと保存オブジェクトは各一件で、ダウンロードしたバイトが原本と一致する必要があります。

上限超過はHTTP 413、FILE_TOO_LARGEを返し、fileIdを発行しません。その要求のメタデータと永続オブジェクトを残しません。応答後に保存する非同期処理のない同期契約とし、テストの保存照会には書込完了状態を確認できる手段を使います。

元の弱いケースは次の記述でした。

修正前：設計例
入力：大きいファイル。
操作：アップロードする。
期待結果：エラーが正常に表示される。

サーバーのサイズ制限と保存結果の検証を目的に修正すると次になります。これは実行結果ではなくテスト仕様です。

区分修正後ケースTC-UP-MAX-PLUS-ONE：設計例
検証要件R-UP-01 v1.0：上限超過を指定エラーで拒否し、ファイルデータを残さない
前提編集権限テストアカウント、準備済みフォルダ、ケース専用領域。開始時のメタデータ・保存オブジェクトは各0件。中間プロキシが本体と要求付加情報の合計サイズを許可し、サイズ規則を検証するAPIまで届く経路であることを確認。
入力limit-plus-one.txt：ASCII aで満たした10,485,761バイト。BOM・余分な改行なし。名前や文字列長ではなく生成ファイルのバイト数を確認。
操作所有または許可された環境で実アップロードAPIへ一回送信。対象API応答と保存経路をmockに置換しない。
期待結果413、code = FILE_TOO_LARGE、fileIdなし。同期処理終了後に対象要求のメタデータ・永続オブジェクトが各0件。別理由のエラーは合格としない。
証拠入力バイト数、実行識別子、要求・応答、実行前後のメタデータ・オブジェクト照会結果。照会失敗や権限エラーを0件へ変換しない。個人情報・認証情報を除外。
整理・隔離証拠確認後に専用データを削除。失敗時も残存データ・変更設定を復元。整理失敗は別記し、次回初期状態が清潔とは仮定しない。

違いは文章量ではありません。誤結果が具体的に表れます。サーバーが受け入れれば状態コード、別理由で拒否すればエラーコード、拒否応答だけ返して保存すれば保存結果で不合格になります。

一方「保存オブジェクト0件」だけも信用できません。同じ観測手段で正常アップロードの一件が見えるか先に確認します。照会先や権限が誤っていると偽の不在証拠になります。整理で先に削除しないよう、結果確認と整理の順序も分けます。

境界値追加では入力と判定を一緒に変える

ISTQB CTFLは同じ処理となる入力集合を同値分割し、順序のある分割境界に境界値分析を適用すると説明します。状態依存機能には状態遷移テストを使えます。生成一覧が正常値だけを変えているのか、境界や状態変化を実際に検証するか確認します。[2]

この契約の上限付近だけを展開すると次です。各行は同じ初期状態からの独立実行です。

入力サイズ期待応答併せて確認する結果
10,485,759バイト：上限より1小さい201sizeBytes一致、READY、メタデータ・オブジェクト各1件、ダウンロードバイト一致
10,485,760バイト：上限と同じ201同上。上限を誤って除外する実装を検出
10,485,761バイト：上限より1大きい413、FILE_TOO_LARGEfileIdなし、メタデータ・永続オブジェクト各0件

この表だけで全検証が完了するわけではありません。下限・空ファイル・権限・転送中断・保存失敗は対象外です。上限付近の例を全境界値カバレッジや全機能カバレッジと呼ばないことが重要です。

生成一覧で見つけるべき欠陥

次の表は形式点数を付けるものではなく、問題発見時に何を修正するか決めるレビュー案です。未決定の要件・期待結果を他項目の高得点で相殺しません。

問題確認質問と補完方向次の処理
期待結果の根拠なし要件・契約・参照結果の何が根拠か。出所・適用版を結べなければ質問を作る要件確認
正常経路の繰返し有効・無効入力、上下限、拒否・中断・復旧が必要か。状態機能は初期状態・操作・次状態・禁止遷移を確認修正後使用
assertionが弱い応答や画面の存在だけか。目的に必要な値・状態・副作用を明示。単体テストに全階層を押し込まない修正後使用
現バグを正解として複製承認規則ではなく現実装や同計算関数が期待値の出所か。現状記録と要件判定を分離要件確認または修正
mockが対象を隠すエラー画面か、サーバーの実検知か。置換経路の外まで確認したと書かない目的修正・検証分割
同じ意味の重複要件・初期条件・入力分類・期待結果は同じか。共通目的をパラメータ化・統合し、上限許可と超過拒否など別判定は残す廃棄・統合
権限・失敗経路の欠落ログインだけか。許可・禁止行為と失敗後データ状態の基準を確認要件確認後補完
データが条件不適合サイズ・文字コード・時差・役割・既存データは仕様どおりか。別エラーで先に拒否される例を区別修正後使用
条件で結果が揺れる時刻・乱数・外部応答・共有データ・順番に依存するか。制御し、制御不可部分の観測方法と限界を残す修正後使用または実行保留

権限レビューではボタン非表示だけでサーバー制御を検証済みにしません。OWASP WSTG v4.2のWSTG-ATHZ-02も役割・身元別に機能・資源アクセスを区分します。ここでは個別ケースの目的と判定根拠を扱い、詳細なマルチテナント組合せは別範囲です。セキュリティ実行は許可環境と合成アカウント・データに限定します。[3]

mockは数より何を代替したかが重要

Playwright公式mock例はネットワーク要求に既定応答を返し、実APIを呼ばないと明記します。その応答を受けた画面の検証には使えますが、サーバーがサイズ確認・保存中止した証拠にはなりません。[4]

外部タイムアウトの再現や画面状態の安定化にはmockが適する場合があります。一方、例のサイズ制限・保存結果には実経路を動かす別検証が必要です。代替依存先と実行経路をケースに記録すれば、mockを一律廃棄したり全統合検証に誇張したりせずに済みます。

サービスの仕組み

正常系の先にある例外も検証 — 実装された動作から要件を復元し、入力、権限、外部呼出しの例外経路を実行して確認します。

人の判断とツール確認を分ける

人が全ケースを書き直す必要はありません。反復する形式・参照・コード誤りをツールで先に除き、期待結果の正しさと確認手段の十分さに時間を使います。

静的検査では必須欄欠落、存在しない参照、型・構文誤り、不要な実行除外、非同期待機漏れを検出できます。ただしassertionの存在と正しい要件の検査は別です。意味の近いケースの自動分類も統合候補探しに使い、同じ検証か判断して整理します。

実行検査では発見・開始、準備・整理、意図した経路と判定への到達を確認します。反復・順序変更で依存を見つけられますが、数回の合格は非決定性不在の証明ではありません。

ツールの安全策の範囲も分けます。環境・資源を準備するfixtureにも適用範囲があります。Playwright Testの既定page・contextはテスト単位ですが、worker単位もあります。ブラウザーコンテキストの分離だけで外部DB・保存領域は初期化されません。共有アカウント・データの隔離は別設計です。[5][6]

画面変化は固定時間待機だけでなく条件を待ちます。Playwright Testのawait expect(locator).toHaveText(...)などWeb用assertionは条件を再確認します。すべてのexpectが再試行するわけではなく、自動待機も誤期待を正しくしません。[7]

合格だけでなく、誤動作で不合格になるか確認する

重要なケースには小さな反証検査を加えます。隔離したローカル複製でサイズ確認を一時除去したら超過ケースが不合格になるべきです。上限比較を誤変更したら上限と同サイズの正常ケースが不合格になるべきです。試験後に戻し、本番コードには反映しません。

これは意図した誤りを検知する補助手段です。注入した誤りを捕まえても他の欠陥すべてを検出する証明ではありません。対象や判定経路を実際に変えられなかった実験は反証検査としない方が適切です。

NIST SSDF v1.1のPW.8.2もセキュリティテストの範囲、設計・実行・記録、発見事項の分類・処理を結びます。本記事はこれを参考に生成ケースのレビュー、実行結果、後続措置を別記録とすることを提案します。AI生成品質認証やSSDF全体準拠を意味しません。[8]

実行後の失敗・不安定性管理には自動化失敗分析・隔離・復帰の運用書式を利用できます。設計レビューと実行後原因分析は別判断です。

レビュー結果を四つの次の行動で終える

以下はケース設計のレビュー結果です。実行PASS・FAILやリリース承認と混ぜません。

結果判断条件次の行動
そのまま使用要件根拠・入力・判定・証拠・隔離が目的に合い修正不要レビュー版を確定し合意環境で実行確認。未実行なら結果は未実行のまま
修正後使用要件確定済みだがデータ・判定・mock・隔離などに修正必要担当が修正し変更箇所を再レビューして実行
要件確認正解根拠がない、または文書・コード・方針が矛盾質問・決定担当・影響ケースを記録。回答依存の判定を保留
廃棄・統合重複、検証目的なし、または別ケースで十分代替可能残すケースと理由を記録し統合。難しい・欠陥を示すだけの理由では捨てない

新しい期待結果や危険なデータ変更を含むケースは人が先に確認し、確認済み規則の反復入力は共通仕様・自動検査で省力化できます。時間短縮のため未決定要件や未確認権限を一括承認しません。

既存リポジトリと課題管理だけでも始められます。要件決定担当、データ制御、結果観測があれば新生成ツールは前提ではありません。チームごとに期待が異なる、失敗後の保存状態が見えない場合は、生成量を増やす前に契約と観測手段を整えます。

次のレビューでは一件選び、「どんな誤動作を入れたら、このケースのどの確認が失敗するか」を問います。答えが明確なら検証対象が定まります。その後データ・環境・実行条件を整えます。曖昧なら文章量より正確な根拠が必要です。

複数チームで基準と役割を合意する必要があれば、IXCのQAプロセス構築支援範囲を確認できます。