公開前診断では何が届く？報告書とテストケースの見方

「問題がある」だけでは、修正も公開判断も進まない

「入力エラーがあります」「スマホで使いにくいです」。こうした指摘だけでは、発注者はどこまで困るのか分からず、開発担当者も同じ状態を再現できません。報告書には、不具合の名前に加えて、どの条件で起きたか、仕様とどこが違ったか、利用者にどんな影響があるかが必要です。

最初に目を通したいのは、確認対象と実施範囲です。どのページ・機能を対象にし、どの環境で、どんな方法で確かめたのか。ログイン後や外部サービスとの連携、実際の送金・決済など、対象外になった範囲も読めるようにします。結果を見る前に範囲を読むと、報告書に書かれていない部分まで確認済みだと思い込むことを防げます。

次に全体の要約を読み、対応が必要な指摘と、判断が必要な事項を拾います。細かな文言の違いと、予約を完了できない不具合では、公開への影響が異なります。一方で、件数が少ないから公開できるとは限りません。個人情報や決済などに関わる指摘は、数とは別に内容を確認する必要があります。

この記事の記録例は、報告書を読むための説明用です。実在する顧客サイトの診断結果や、特定の検証を実施した実績を示すものではありません。実際の依頼では、対象、確認方法、届く成果物、追加で人が判断する範囲を、申し込み前に確かめてください。

Custosの案内では、まず画面・機能と問題を整理する段階、その後に詳細な内容や直し方、AIへ修正を依頼するための文章を確認する段階、さらに初めて使う人がつまずく点を確かめる段階があります。すべての内容が最初の段階で届くという意味ではありません。依頼前に選択する段階と成果物を照らし合わせることが必要です。

指摘は、期待する結果と実際の結果を並べて読む

個別の指摘では、「再現条件」「期待する結果」「実際の結果」を続けて読みます。再現条件は、その状態に至るための前提と操作です。期待する結果は、仕様として本来どうなるべきか。実際の結果は、確認した場面で何が起きたかです。この違いが明確なら、開発担当者が修正対象を絞りやすくなります。

説明用の例として、予約フォームで必須項目を空欄にした場合を考えます。期待する結果は「入力が必要な欄を案内し、予約は作成しない」。実際の結果が「完了画面へ進むが予約は保存されない」なら、利用者が予約済みと誤解する点まで伝える必要があります。単に「エラー表示がない」と書くより、業務上の影響が明らかになります。

重大度は、その問題がサービスや利用者へ及ぼす影響の目安です。公開前に止めて直すべきか、代替手段があるか、影響する人は誰かを考える助けになります。ただし、重大度と修正する順番は必ず同じではありません。公開する機能の範囲や運用上の回避策も含めて、発注者と開発担当者が優先順位を決めます。

スクリーンショットが添えられている場合は、文章と同じ箇所を示しているか、日時や環境がそろっているかも確認します。画像は状況の理解を助けますが、写っていない処理まで証明するものではありません。保存されたデータや通知の結果が論点なら、その確認結果も別に必要です。

• どこで、どんな前提・操作で起きたか。
• 仕様ではどうなるはずで、実際はどうなったか。
• 利用者や業務へ、どんな影響があるか。
• 修正後に、何を確かめれば解消と判断できるか。

テストケースを見ると、確認の筋道が分かる

テストケースは、確認する条件・操作・期待する結果を組にしたものです。不具合の一覧とは役割が違います。不具合一覧には見つかった問題を、テストケースには問題の有無を判断するために確かめる内容を残します。両方を読むことで、何が見つかったかだけでなく、どんな観点から確認したかが分かります。

Custosでは、国際的なテスト技術者の資格団体 ISTQB® が定めるテスト設計技法（境界値分析・状態遷移など）に沿って、テストケースを作っています。

境界値分析は、条件の境目に注目する考え方です。説明用に文字数制限のある入力欄を考えると、上限の手前・上限・上限を超えた状態などを確認対象にします。状態遷移は、操作によって状態がどう変わるかに注目します。予約なら、受付前、受付済み、取り消し後などの状態と、その間の操作を整理します。

すべての入力値や操作の組み合わせを無制限に試すわけではありません。仕様、利用頻度、影響を踏まえて確認を設計します。依頼する側は、重要な業務と困る失敗を伝えると、確認すべき条件が明らかになります。仕様が決まっていない部分は、不具合と断定せず、確認事項として扱うことも必要です。

ケースごとの結果は、成功・失敗だけでなく、未実施や確認不能も区別して読みます。試験用アカウントがないため進めなかった項目は、合格ではありません。修正後には元のケースを再確認し、関連する操作にも影響がないかを見直します。確認条件が残っていれば、担当者が変わっても同じ前提で話を進められます。

品質の観点と、確認できた範囲を一緒に読む

Custosでは、ソフトウェア品質の国際規格 ISO/IEC 25010 が定める品質の観点（機能の正しさ・性能・端末の違い・使いやすさ・アクセシビリティなど）に沿って確かめ、結果を報告書に残します。

例えば予約の保存は機能の正しさ、操作に対する待ち時間は性能、スマートフォンでの操作は端末の違いに関わります。案内を読んで次の操作が分かるかは使いやすさ、入力欄と説明が対応しているかやキーボードで操作できるかは、基本的なアクセシビリティを考える入口になります。同じ画面でも、確認する問いを変えると別の問題が見えてきます。

ここで大切なのは、品質の観点を並べることと、そのすべてを十分に測定することは別だという点です。性能であれば確認時の操作と条件、端末の違いであれば対象の端末・ブラウザー、アクセシビリティであれば実施した基本項目を示す必要があります。大人数の同時利用を想定した負荷試験や、専門的なアクセシビリティ評価まで実施したと、見出しだけで判断してはいけません。

ISOの公式説明では、ISO/IEC 25010は製品品質を指定・測定・評価する際の参照となる品質モデルとして位置づけられています。報告書では、観点の名称を飾りにせず、対応するテストケースや結果へたどれることが大切です。国際規格に触れていること自体が、個々のサイトの安全性や完成度を保証するわけではありません。

書式や記載項目を検討するときは、公開前診断の報告書見本を案内先としてご確認ください。見本に記載された件数や例示は、ご自身のサイトで同じ結果が出るという意味ではありません。

現在の案内では、対象はWebアプリです。コードレビュー、修正代行、負荷試験、長期的な安定性の検証、WCAGへの適合判定は対象に含まれません。安全面についても入口の確認であり、詳細な脆弱性診断とは範囲が異なります。基本項目の結果を、そのまま包括的な安全証明や適合の証明として扱わないでください。

まとめ：報告書を、修正と継続確認の共通資料にする

報告書は受け取って終わりにせず、修正対象と判断事項を開発担当者へ渡すために使います。まず範囲を確認し、指摘の影響、再現条件、期待と実際の差を読みます。そのうえで、テストケースと品質の観点をたどり、未確認の項目や追加で判断する範囲を明らかにしましょう。

修正を依頼する際は、対象の指摘、対応担当、修正予定、再確認結果をひもづけると、伝達漏れを減らせます。公開を決める人には、修正した項目だけでなく、残っている事項とその理由も共有します。「指摘が消えた」だけでなく、「何を根拠に公開するか」を説明できることが、報告書を残す価値です。

公開前は動作と使い勝手を確認し、公開後はWebサイトの脆弱性診断などで安全面を継続して見直す流れを作りましょう。機能の追加や利用環境の変化によって、確認すべき内容も変わります。診断は弱点を見つける手段であり、すべての不具合や攻撃を防ぐ保証ではありません。

ISTQB® は International Software Testing Qualifications Board の登録商標です。Custos は ISTQB® の認定を受けた事業者ではなく、ISTQB® で定められたテスト設計技法に沿って点検を行っています。