はじめに：テストは「台本どおりにボタンを押す」だけではない
業界の外にいる多くの人は、テスターの仕事を「用意されたテストケースを開き、順番にボタンを押していくだけ」と捉えています。それは仕事の表面にすぎません。製品が出荷され、利用者が問題に直面したとき、最初に問われるのはテスターです。「なぜこの不具合は見逃されたのか」と。
この記事は、フィンテック、Eコマース、SaaSのプロジェクトで数年にわたりQAを担当した経験から書きました。以下の12の教訓は教科書の理論ではありません。時間と、開発者との厳しい議論と、顧客への謝罪によって得たものです。
プログラムのテストは不具合の存在を示すことはできるが、不具合が存在しないことを示すことは決してできない。
エドガー・W・ダイクストラ、Notes on Structured Programming、1970年
12の教訓を一覧で
| # | 教訓 | 一行の要点 |
|---|---|---|
| 1 | 推測せず質問する | 仕様の曖昧さはすべて質問に変える。 |
| 2 | まずハッピーパス | 時間の半分は大多数が通るフローに使う。 |
| 3 | 二層の視点 | 利用者として感じ、技術者として点検する。 |
| 4 | 4つのデータ状態 | 空、読み込み、過負荷、エラー。きれいなケースだけでは不十分。 |
| 5 | 改善を提案する | 逸脱の指摘だけでなく具体的な解決策を出す。 |
| 6 | SeverityとPriority | 技術的影響と業務上の緊急度は別の軸。 |
| 7 | 感情ではなく証拠 | バグレポートは鑑定書であり、不満ではない。 |
| 8 | まずF12を開く | リクエストなしはフロント、500やタイムアウトはバックエンド。 |
| 9 | データベースが真実 | 緑の通知はデータが正しい証拠にならない。 |
| 10 | バタフライ効果 | 変更したコードを共有する全フローを再テストする。 |
| 11 | 利用者は整然としない | 二重クリック、戻るボタン、貼り付け、長い名前。 |
| 12 | 開発者は味方 | 問題の同じ側に立つ。 |
第1部：要件に対する思考法
教訓1：仕様書は推測のためではなく、質問するために読む
陥りがちな罠：資料を流し読みし、不明点を自分の感覚で埋める。BAや開発者に聞くのは迷惑だと思い込む。
- ペンを持って読み、曖昧な箇所すべてに線を引く。
- もしもの質問をする：決済中に通信が切れたら？最後のステップでキャンセルしたら？二人が同時に同じ注文を決済したら？
- 答えをすべて明示的なテスト基準に変える。
要点：構文エラーは数分で直る。要件の誤解は数百時間を失う。
教訓2：異常系の前にハッピーパスを守る
陥りがちな罠：中核の登録や決済フローが壊れているのに、新しいビルドで珍しい境界値に飛びつく。
- 時間の約50%を大多数が通るハッピーパスに使う。
- 約30%をよくある入力ミスに使う。
- 最後の20%を極端なケースと境界値に使う。
要点：すべてのケースはテストできない。小さな不具合が金銭や信頼を損なうフローを優先する。
第2部：体験という視点
教訓3：二層の視点
陥りがちな罠：ピクセルのズレばかり追って旅の感情を見失う。あるいは流し見して、別の画面幅でレイアウトが崩れるのに気づかない。
- 最初の5分は急いでいる新規顧客を演じ、マウスだけで操作する。
- その後レスポンシブツールを開き、各幅でボタン、余白、視覚的優先順位を点検する。
要点：利用者として感じ、技術者として点検する。
教訓4：4つのデータ状態を意識する
陥りがちな罠：きれいなサンプルデータだけでテストし、初回、低速回線、大量データ、失敗時の体験を忘れる。
- 空：イラスト、短い説明、作成ボタン。
- 読み込み：ボタンを無効化し、内部にローディングを表示して二重クリックを防ぐ。
- 過負荷：100文字超の名前、非常に長いリスト、任意項目の欠損を試す。
- エラー：何が起きたか、どう回復するかを示す。
要点：4状態はあらゆる画面の最低ライン。
教訓5：バグを見つけるだけで終わらず、改善に貢献する
陥りがちな罠：仕様どおりだという理由で、使いにくい機能を見逃す。
- 逸脱の指摘だけでなく、具体的な解決策を添えた改善提案を記録する。
- 例：フォームが使いにくいと書く代わりに、住所2項目を統合し郵便番号から自動入力する。
要点：解決策のある提案は聞き入れられる。
バグレポートは鑑定書であり、不満ではない。
第3部：客観的な証拠で不具合を捉える
教訓6：SeverityとPriorityを明確に分ける
陥りがちな罠：すべての不具合を緊急にすると、緊張を生み、本当に深刻な不具合が埋もれる。
- Severityは技術的影響：クラッシュ、データ損失、中核機能の破損。
- Priorityは業務上の緊急度：ロゴの誤りはサイトを止めないが、即修正が必要。
要点：二つの独立した軸。すべてが赤なら、何も目立たない。
教訓7：感情ではなく客観的な証拠で語る
陥りがちな罠：「たまに画面が壊れる」「動作が重い」と報告する。
- 番号付きの再現手順。
- 実際の結果と期待する結果の対比。
- 範囲を囲んだスクリーンショットや動画。
- NetworkタブのHTTPステータスとtrace ID。
要点：十分な証拠は半日の調査を5分の修正に変える。
教訓8：報告前にF12を開く
陥りがちな罠：画面がリクエストを送ったか確認せず、バックエンドを疑う。
- クリックしてもリクエストなし：フロントエンド。ハンドラ未設定かバリデーションによるブロック。
- 200なのに描画されない：フロントエンドの表示不具合。
- 500またはタイムアウト：バックエンドの不具合。
要点：この3分岐でチームの往復が減る。
図1. 担当を決める前にNetworkタブで不具合を切り分ける。
教訓9：UIは外殻、データベースが真実
陥りがちな罠：成功メッセージを見て合格にする。
- レコードIDで直接照会する。
- 補助項目、タイムゾーン、変更履歴を確認する。
- 決済、権限、システム設定ではデータベース確認が必須。
要点：緑の通知は証拠ではない。正しい行が証拠だ。
緑の通知は証拠ではない。正しいデータの行が証拠だ。
第4部：システム思考と共感
教訓10：バタフライ効果
陥りがちな罠：開発者が直した欄だけを確認してチケットを閉じる。
- 共通コンポーネント、バリデーション、サービス層を共有する全フローを再テストする。
- リグレッションは修正の一部であり、追加工程ではない。
要点：共通関数一つで3画面が壊れることがある。
教訓11：実際の利用者は台本どおりに操作しない
陥りがちな罠：ゆっくり順序立ててテストし、利用者も同じだと考える。
- 確認ボタンを連続で押し、重複注文を確認する。
- 決済中にブラウザの戻るボタンを押す。
- 複雑な声調記号を入力し、Wordから貼り付け、長いファイル名をアップロードする。
要点：整然としない操作が、整った台本では触れない不具合をあぶり出す。
教訓12：開発者を敵にしない
陥りがちな罠：揚げ足取りの態度が開発者を敵にする。
- 「あなたのコードが壊れています」を「このデータを送ると、システムがこう応答します。見てもらえますか」に変える。
- 問題の同じ側に立つ。
要点：敬意と技術的共感は、どんなツールよりも仕事を速くする。
付録：実践ツール3点セット
ツール1：技術鑑定型バグレポートのひな形
標準的なバグレポートは5つの部分で構成します。タイトルはモジュール、発生頻度（100%かランダムか）、発生条件を含めます。
- テスト環境：端末とOS、ブラウザとバージョン、環境とビルド番号、ロールを含むテストアカウント。
- 最小再現手順：誰でも同じ操作を再現できるよう番号付きで短く記載。
- 実際の結果：起きたこと、待ち時間、表示されたメッセージを原文のまま。
- 期待する結果：業務ルール上の正しい挙動。その場の警告と、最初のクリック後の保存ボタン無効化を含む。
- 技術的証拠：範囲を囲んだ画像や動画、リクエストURL、HTTPステータス、応答時間、送信ペイロード、レスポンスボディ、trace ID。
ツール2：SeverityとPriorityのマトリクス
リスクスコアはSeverityの重みとPriorityの重みの積です。修正順序を客観的に決められます。
図2. Severityは技術的影響、Priorityは業務上の緊急度を測る。
| 区分 | Severity 1: 致命的 | Severity 2: 重大 | Severity 3: 中程度 | Severity 4: 軽微・外観 |
|---|---|---|---|---|
| Priority 1: 緊急、2から4時間以内に修正 | 決済ゲートの停止、カード情報の漏えい、基幹データベースの接続断。 | タイムセールでクーポンが使えない、新規アカウントの認証メールが届かない。 | トップページで主要パートナーのロゴ誤表示、広報でのブランド名誤記。 | 記者発表版の起動画面アイコンのずれ。 |
| Priority 2: 優先度高、現スプリントで修正 | 会計の税務レポートの計算不具合。手動対応で一時的に回避可能。 | サブアカウント群で日付フィルタのタイムゾーンずれ。 | iPad Safariで通知パネルの閉じるボタンがずれる。 | お問い合わせページの見出しフォントがデザインシステムから2pxずれる。 |
| Priority 3: 通常、バックログに追加 | 四半期ごとの旧データバックアップのメモリリーク。 | webp画像でプロフィール画像を変更できない。 | サイドメニューにトランジションがない。 | フッター背景色が規定より暗い。 |
| Priority 4: 低、時間があるときに修正 | 来月置き換え予定のデータ出力ツール内のプロセス競合。 | IT担当2名のみが使う内部レポート印刷の書式不具合。 | 利用規約ページの意味に影響しない一語の誤り。 | 画面幅300px時に404ページの下部余白が広い。 |
ツール3：UIの4データ状態チェックリスト
図3. あらゆる画面が耐えるべき4つの状態。
1. 空状態。
- ☐ 真っ白な画面や説明のない空テーブルを放置しない。
- ☐ 文脈に合ったイラストを表示する。
- ☐ 短い見出しと親しみやすい説明を添える。
- ☐ 最初のデータ作成へ導く主要ボタンを置く。
2. 読み込み状態。
- ☐ スケルトンスクリーンで実際のレイアウトを再現する。
- ☐ 確認ボタンを無効化し、内部にローディングを表示する。
- ☐ Slow 3Gでも5秒超で崩れず、長時間処理には進捗を通知する。
3. 過負荷とデータ欠損。
- ☐ 空白なし500文字を貼り付け、折り返しや省略とツールチップで崩れないことを確認する。
- ☐ 1,000から10,000件のリストで仮想スクロールやページネーションを使う。
- ☐ 任意項目が欠けてもレイアウトの均衡が保たれる。
4. エラー状態。
- ☐ オフライン時にバナーと再接続ボタンを表示する。
- ☐ 5xxでは謝罪文とtrace IDを表示し、スタックトレースやデータベースエラーを露出しない。
- ☐ バリデーションエラーは赤枠と対処法を直下に表示し、最初のエラーへ自動スクロールする。
参考資料
- ISTQB Glossary（SeverityとPriorityの定義）: glossary.istqb.org
- ISTQB Certified Tester Foundation Level: istqb.org
- Ham Vocke, The Practical Test Pyramid, martinfowler.com: martinfowler.com
- Nielsen Norman Group, 空状態のインターフェース設計: nngroup.com
- MDN, ブラウザ開発者ツールの概要: developer.mozilla.org
- W3C, Web Content Accessibility Guidelines 2.2: w3.org
- OWASP, Web Security Testing Guide: owasp.org
おわりに
テストは、より多くの不具合を見つける競争ではありません。チーム全体で利用者の信頼を守る営みです。一つだけ持ち帰るなら、これを：推測する前に質問し、画面の通知を信じる前に実際のデータを確認する。