前回との接続と、この講義の役割
前回のP-01では、品質は動くかどうかの一軸ではなく、6つの観点で捉えるものだと確かめました。では、その品質は具体的にどうやって確かめ、崩れていたらどう直すのでしょうか。ここから始まる確認の作業には、性質の異なる2つの活動が含まれています。この講義では、まずその2つ、つまり不具合を見つける活動と、原因を特定して直す活動を、はっきり分けます。
このスライドのポイント
- P-01で確かめたこと: 品質は「動くかどうか」の一軸ではなく、6観点の束で捉える
- 残る問い: では、その品質は「どうやって確かめ」「崩れていたらどう直す」のか
- この確認作業には、性質の異なる2つの活動が含まれている
- この講義の役割: その2つ——見つける活動と、直す活動——をはっきり分ける
テストとデバッグの定義
テストとは、不具合を見つける活動です。M-09で決めた受入条件のような期待と、実際の動きを比べて、そのずれを探します。テストで分かるのは、あくまで期待と実際が食い違っているという事実、つまりずれの存在までです。一方デバッグとは、見つかったずれの原因を特定し、修正する活動です。ずれがなぜ起きたのかを突き止めてから直すところまでを含みます。順序は必ずテストが先、デバッグが後です。見つけていないものは直せないからです。
このスライドのポイント
- テスト = 不具合を見つける活動。M-09の受入条件のような「期待」と「実際」を比べ、その「ずれ」を探す。分かるのは「ずれがある」という事実まで
- デバッグ = 見つかったずれの「原因を特定し、修正する」活動（P-08〜P-10で深掘り）
- 順序は必ず テスト → デバッグ（見つけていないものは直せない）
なぜ区別が必要か
この2つを混同すると、作業が空回りします。たとえば、テストしたのに直っていないという不満は、テストが見つける作業でしかないことを忘れた結果です。逆に、原因も分からないまま直したという対症療法は、デバッグの手前を飛ばしています。AIへの依頼も同じように混ざります。見つけてほしいのか、直してほしいのかが曖昧なまま頼むと、返ってくる答えもぼやけます。
このスライドのポイント
- 混同すると作業が空回りする
- 「テストしたのに直っていない」= テストは見つける作業でしかないことを忘れた結果
- 「原因も分からず直した」= デバッグの手前（原因特定）を飛ばした対症療法
- AIへの依頼も混ざる: 見つけてほしいのか、直してほしいのかが曖昧なままだと答えもぼやける
2つの活動の分業と円環
2つの活動の分業を図にします。テストは、期待と実際を比べて、ずれを発見するところまで。デバッグは、そのずれを再現し、原因を特定し、修正し、再びテストするところまでです。注目してほしいのは、この流れが一直線ではなく円環になっている点です。直したら、また確かめる。この再確認は、後のP-07で回帰テストとして本格的に扱います。いまは、直して終わりではないという形だけ押さえてください。
このスライドのポイント
- テスト: 期待と実際を比べる → ずれの発見（ここまで）
- デバッグ: 再現 → 原因特定 → 修正 → 再テスト
- この流れは一直線ではなく「円環」: 直したら、また確かめる
- 「直して終わり」ではない（再確認はP-07の回帰テストで本格化）
Webアプリでの具体例
合計金額がおかしい、という不具合で考えます。テストにあたるのは、どの入力を与えたときに、いくらずれるのかを特定する活動です。ここでは原因には踏み込みません。デバッグにあたるのは、そのずれの原因を突き止めて直す活動です。E-03で学んだ机上での実行や、J-08で残したログをたどって、計算のどこで狂ったのかを探ります。ご覧のとおり、AIへの依頼文も、見つけるための依頼と、直すための依頼の2種類に自然と分かれます。
このスライドのポイント
- 題材: 「合計金額がおかしい」という不具合
- テストにあたる活動: どの入力でいくらずれるかを特定する（原因には踏み込まない）
- デバッグにあたる活動: そのずれの原因を突き止めて直す（E-03の机上実行やJ-08のログで追う）
- AIへの依頼文も、見つける依頼と直す依頼の2種類に分かれる
技術サンプルカード: 2種類の依頼テンプレ
07は技術サンプルです。種別はプロンプト、目的はテスト依頼とデバッグ依頼を別々の言葉で出すことです。テストを頼むときは、この機能の期待と実際のずれを見つける観点を列挙して確認してください、と伝えます。デバッグを頼むときは、このずれの原因を特定してください、修正は原因の説明の後で、と伝えます。読み方の要点は、デバッグ依頼の原因の説明の後で修正という一言です。これがあると、AIは原因の説明を飛ばして当てずっぽうに直すことができなくなります。
混同しやすい概念
混同しやすいのは、テストとデバッグそのものです。テストは見つける活動、デバッグは直す活動、と役割で覚えてください。もう一つ添えておきたいのは、動かして確認しましたという言葉です。これはテストの一部にすぎません。一度動かして正常に見えただけでは、期待と実際を体系的に比べたことにはならないからです。
バイブコーディングでの確認点
AIに修正させるときは、原因は何でしたかを先に言わせてください。原因のない修正は、たとえその場で症状が消えても再発します。これはA-06で学んだ、AIの間違いは原因に合わせて対処すると直る、という構造とまったく同じです。バイブコーディングでは、テストがAIの出力の検収装置になります。見つける依頼と直す依頼を分け、直す前に原因を語らせる。この2つを習慣にしてください。
このスライドのポイント
- AIに修正させるときは「原因は何でしたか」を先に言わせる
- 原因のない修正は、その場で症状が消えても再発する（A-06の「原因に合わせて対処すると直る」と同じ構造）
- バイブコーディングでは、テストがAIの出力の検収装置になる
- 習慣化: ①見つける依頼と直す依頼を分ける ②直す前に原因を語らせる
一問一答とまとめ
最後に一問です。不具合を見つけるのは、テストとデバッグのどちらでしょうか。（間）答えはテストです。デバッグは、その先の原因特定と修正を担います。30秒でまとめます。テストは見つける、デバッグは直す。順序はテストが先。そしてAIには、見つける依頼と直す依頼を分けて渡し、直すときは原因の説明を先に求める。次回のP-03では、では何を試すのか、正常系・異常系・境界値という3つの分類に進みます。関連資料は、テスト観点プロンプト50と、エラー解決プロンプト50です。
このスライドのポイント
- 一問一答: 不具合を「見つける」のはテストとデバッグのどちら？ → 答: テスト（デバッグは原因特定と修正）
- 30秒まとめ: テストは見つける／デバッグは直す／順序はテストが先／AIには見つける依頼と直す依頼を分けて渡し、直すときは原因の説明を先に求める
- 次回: P-03「正常系・異常系・境界値」——では何を試すのか、の3分類へ
- 関連資料: 「テスト観点プロンプト50」「エラー解決プロンプト50」
