テストは済んでるって言われたのに、なんでこんなにバグが多いんですか…？
“テスト済”って言葉、実はあまり当てにならないんです。中身を見ないと、何が確認されたか分からないですしね。
確かに『動作確認しました』ってだけで終わってる報告もありますね…
テストって“観点”と“証拠”がセットになって初めて意味があるんです。
はじめに
ベトナムとのオフショア開発において、「テストは終わった」と報告されたのに、納品後に不具合が多発するというケースは少なくありません。その原因の多くは、“テスト済”という言葉の曖昧さにあります。
本記事では、実際の現場で起こった誤解や失敗例を紹介しながら、品質を確保するためのテストに関する具体的な対策を4つご紹介します。
「テスト済＝完了」ではない？よくある誤解
オフショア開発の現場では「テストしました」という報告があるものの、内容を確認すると単なる動作確認レベルに留まっていることが多くあります。
たとえば、「画面が表示された」「ボタンを押したら遷移した」など、機能が“とりあえず動く”ことを確認しただけで完了と見なされているケースがあります。
また、ベトナム側チームが詳細な仕様を完全に理解していないままテストを行っていることもあり、本来確認すべき観点（例外処理、パターン網羅など）が抜けてしまうこともよくあります。
本来であれば１つだけでなく他のテストケースも考慮するべきですが、１つのテストケースだけテストしたらそれで終了としてしまうことも多々見受けられます。
実例：テスト済み報告の裏で起きていた見落とし
「テスト済み」という言葉が報告書に書かれていると、どうしても安心してしまいがちです。しかし、いざリリースしてみるとバグが噴出し、原因をたどってみると「そもそもそのケースは確認していなかった」というパターンが多く見られます。実際の現場ではどのような“テスト漏れ”が起きやすいのか、具体的な実例をいくつか挙げてみます。
例1：ブラウザ依存の不具合
テストはChromeでのみ実施されており、Safariではボタンが機能しないまま納品された。
例2：バリデーション漏れ
「保存ボタンが効くこと」は確認されていたが、未入力時のエラーメッセージ表示などは未確認。
例3：境界値が未テスト
数値入力フィールドに「最大値＋1」の値を入れるテストが実施されておらず、本番でクラッシュが発生。
こうしたケースはいずれも「テスト済」という言葉に安心してしまった結果です。
オフショア開発でのテスト品質を底上げする4つの仕組み化アプローチ
対策1：テスト観点の事前共有と合意
「テストしました」という報告があっても、その中身が“何を確認したのか”まで明らかにされていないケースは少なくありません。特にオフショア開発では、日本側が期待する「当たり前の確認事項」が、相手にとっては指示がなければ実施しない対象になっていることもあります。そのギャップを埋めるには、最初から「どの観点で、どのようにテストしてほしいか」を具体的に共有しておくことが極めて重要です。
以下のような観点を明文化し、関係者で合意しておくことで、見落としのないテストが可能になります。 「何をもってテスト完了とするか」を明文化し、チームで合意することが第一歩です。
- 正常系・異常系を区別し、観点を一覧化
- たとえば「正しく入力した場合に保存できる」だけでなく、「未入力」「異常値」「予期しない操作」といったネガティブケースも含めて洗い出します。
- 境界値、エラーケース、未入力、キャンセル操作などを含める
- 入力欄であれば「0文字」「最大文字数」「1文字オーバー」などを具体的に定義し、テスト観点に加えます。
- 可能であればカバレッジ表や観点チェックシートを作成
- チェックシート形式にすることで、誰が見ても「どの観点がテストされたか」が一目で分かるようになります。Googleスプレッドシートで項目を整理し、ベトナム側と共有するのが現場では効果的です。
特に異常系や例外パターンは、実装者視点では抜けやすいため、あらかじめ観点として指示しておくことが重要です。
対策2：スクリーンショット＋ログ付きのテスト報告の義務化
テスト報告が「確認しました」の一文だけ、というのはよくある話ですが、これでは何も確認したことにはなりません。特に海外チームとのやり取りでは、言葉の認識や判断の基準に微妙な差があるため、「やったかどうか」ではなく「どうやったか」を確認できる仕組みが必要です。
そのためには、スクリーンショットやログなど、視覚的かつ客観的な証拠をセットで報告してもらうことが効果的です。以下のような情報が揃っていれば、テストが正しく実施されたかを容易に検証できます。 「確認しました」だけのテスト報告は信用できません。実際にどの画面をどう操作したのか、何が表示されたのかをエビデンスとして残すことで、検証の透明性が高まります。
- 入力値とその結果画面のスクリーンショット
- どの値を入力してどのような画面が表示されたかを記録します。特にフォームや検索機能など、条件によって動作が変わる場合は重要です。
- エラーメッセージの内容
- 入力ミスやシステムエラー時に表示されるメッセージをキャプチャしておくことで、UIとバリデーションの整合性が確認できます。ユーザーに誤解を与える表現になっていないかのチェックにもなります。
- コンソールログ（可能なら）
- ブラウザの開発者ツールで取得できるJavaScriptのエラーや警告ログを添付することで、画面上では見えない内部の不具合も検知できます。
こうした情報を合わせて報告してもらうことで、テストが形骸化していないか確認できます。
対策3：レビュープロセスにテスト結果確認を組み込む
コードレビューに比べて、テスト結果のレビューは軽視されがちです。しかし、実装が仕様通りに動いているかどうかを確認するテストも、れっきとした品質チェックの一部です。レビュワーがテスト結果も確認することで、観点の抜け漏れを防ぐだけでなく、開発者自身の「見られている」意識が高まり、テストの質自体が向上します。
具体的には、以下のような情報をレビュー時に確認することが有効です。 コードレビューと同様に、テスト結果もレビュー対象に含めるべきです。特に「レビューの観点にテストが含まれていない」場合、開発側とレビュー側の間に品質基準のズレが生じやすくなります。レビュー時にテストの中身や実施状況を確認できる仕組みを取り入れることで、レビューそのものが「品質保証の最終砦」として機能します。
ここで重要なのは、レビュー時にどんな情報をチェックすればテストの信頼性が高まるのかを明確にすることです。以下に、レビュー時に確認しておくべき代表的なポイントを挙げます。
- プルリクエストにテスト実施報告を添付
- 観点チェックリストを満たしているか確認
- 実装者とレビュワーの間で観点のすり合わせを行う
テストの中身に第三者の目が入るだけで、品質意識は大きく変わります。
対策4：E2Eテストなど自動化テスト導入
属人的なテストにはどうしても限界があります。担当者のスキルや集中力、作業状況に左右されるうえに、何度も同じ手順を実行するには時間と労力がかかります。そこで効果を発揮するのが、自動化されたE2Eテストの導入です。
初期導入には手間がかかりますが、一度仕組みを整えてしまえば、品質チェックの再現性と信頼性が格段に向上します。特にベトナムのような高速開発を重視する現場では、「安心してスピードを出せる土台」として、自動テストは欠かせない存在になります。
以下は、筆者が実際に効果を感じた自動化のポイントです。 属人性やテスト漏れを防ぐには、自動化の導入も重要です。
- Playwright や Cypress を使ったE2Eテストの整備
- 主要機能だけでも「自動で壊れていないことを確認できる」体制をつくる
- 開発初期からテストコードを組み込む文化づくり
自動テストは初期工数こそかかりますが、後工程での修正コストを圧倒的に削減できます。
「テスト済」という言葉に安心せず、内容を具体的に把握し、可視化・仕組み化していくことが、ベトナムとのオフショア開発における品質向上の鍵となります。
観点の共有、証拠の明示、レビューによるダブルチェック、そして自動化の導入。
これらの取り組みを通して、“確認したつもり”から“確実に検証できた”という状態へシフトしていくことが重要です。
