15-03 テストとデバッグの支援 受講者用本文・演習・解答・講師メモ/作成日 2026年10月6日 対象:エンジニア・技術担当 前提:プログラミング・Git・HTTPの基礎と02分野相当 標準時間:180分(休憩別。解説、演習、レビューを含む) 成果物:再現テストと修正差分 学習項目:再現条件/境界値/期待値/回帰 1. 解説本文 デバッグは再現条件と期待結果を固定するところから始めます。修正前に失敗を確認できるテストを用意すると、直った理由を示せます。例外を握りつぶして結果だけ合わせる修正は避けます。 境界値は不具合を見つけやすい題材です。正常ケースだけでなく、空、最大、最大超過を確認します。修正によって既存の正常動作が壊れていないかも見ます。 2. 失敗しやすい点 テストの期待値を誤った実装に合わせて書き換えないこと。 3. 配布資料(架空のケース) 添付dev_lab.pyには、50文字ちょうどを誤って拒否するbroken関数と、正しいsolution関数があります。仕様は1〜50文字、前後空白除去です。 追加素材:dev_lab.py 4. 演習課題 brokenに失敗する境界テストを書き、条件を修正してください。 実施手順: 1. 最初は模範解答を閉じ、配布資料だけを読んで「確定していること」「分からないこと」を書き分けます。 2. 演習課題に対する自分の案を作ります。計算課題は小さな値を手計算し、設計課題は正常時と例外時の流れを描きます。 3. 承認されたAI環境がある場合は、下の入力例をそのまま使い、結果を保存します。ない場合も配布資料と例題で判断を練習できます。 4. 次の点を重点確認します。「テストの期待値を誤った実装に合わせて書き換えないこと。」元資料と照合し、誤り・未確認・改善点を区別します。 5. 相互レビュー後に修正し、模範解答と比較します。模範解答と表現が違っても、根拠と条件が一致していれば採用できます。 6. 発展演習では、資料の数値・期限・権限・例外のうち一つを意図的に変更し、どの部分の答えが変わるかを予測して再実行します。変更条件は元資料とは別に記録します。 5. そのまま使える入力例 目的:テストとデバッグの支援の演習を行います。 使用資料: 添付dev_lab.pyには、50文字ちょうどを誤って拒否するbroken関数と、正しいsolution関数があります。仕様は1〜50文字、前後空白除去です。 依頼:brokenに失敗する境界テストを書き、条件を修正してください。 条件:資料の事実と仮説を区別してください。資料にない数値・規則・実績を事実として追加しないでください。不明な点は未確認とし、確認先または確認方法を示してください。 出力:成果物案、その根拠、未確認事項、採用前の点検項目に分けてください。 評価の重点:修正前に失敗し修正後に通る検証を示す。 6. 記入用ワークシート 講座ID:15-03 受講者:       実施日: 1. 今回の目的を一文で: 2. 資料で確定している事実(3点以上): 3. 資料では分からないこと: 4. 自分が最初に考えた回答・設計: 5. 入力した指示と出力、または机上検討の結果: 6. 点検した結果・計算式・根拠箇所: 7. 修正した内容とその理由: 8. 最終成果物:再現テストと修正差分 9. 残った疑問と確認担当: 10. 作業  分/確認  分/修正  分: 11. 自分の業務で試す範囲と確認日: 7. 模範解答・考え方(演習後に確認) 長さ50は有効、51は無効です。誤りは上限判定の>=50で、正しくは>50。空白除去の後に判定します。添付コードの--self-testは誤った関数が境界で失敗することと修正版の期待値を確認します。 解答を見る際の注意:テストの期待値を誤った実装に合わせて書き換えないこと。 文章の一致ではなく、根拠・条件・判断が一致しているかを確認します。 8. 理解確認問題 問1:50文字の失敗だけ直したら空文字テストは不要ですか。 答え:必要です。修正後も他の仕様が保たれているか確認します。 問2:この演習の回答を採用する前に、一番注意して確認する点は何ですか。 答え:テストの期待値を誤った実装に合わせて書き換えないこと。 問3:本講座の成果物で満たすべき条件を自分の言葉で説明してください。 判定基準:修正前に失敗し修正後に通る検証を示す。条件だけを暗記せず、自分の成果物の該当箇所を示せれば到達です。 9. 講師用の進行 目的・前提を確認:15分 解説本文と例題:35分 講師実演:25分 演習・例外の追加:75分 相互レビュー:20分 確認問題と振り返り:10分 指導の重点:受講者版は別名コピーし、模範解答を見ずに一度修正させる。 開始時の問い:「50文字の失敗だけ直したら空文字テストは不要ですか。」への仮回答を先に書かせ、最後に理由が変わったか確認します。 実演:配布資料を示す→初稿を作る→「テストの期待値を誤った実装に合わせて書き換えないこと。」を点検する→修正する、の順で見せます。 相互レビュー:原資料に戻って説明できるか、未確認を埋めていないか、合格条件を満たすかを確かめます。 固有の到達基準:修正前に失敗し修正後に通る検証を示す。 採点:目的適合・根拠確認・安全性・再現性・業務への適用を各0〜4点。合計14点以上、根拠確認と安全性は各3点以上を修了の目安とします。 0=欠落または重大な誤り、1=大幅な支援が必要、2=一部修正が必要、3=自立して満たす、4=例外も検証し説明できる。 未達時:誤った箇所を本人に特定してもらい、資料の一条件を変更した別例で再提出してもらいます。 時間が余る場合:例外条件を追加し、別の受講者が手順を再現する試験を行います。 時間が不足する場合:発展演習を宿題へ回し、原資料との照合と確認問題は省略しません。 操作環境なしで受講した場合:知識・設計の到達と実操作の到達を区別して記録します。 持ち帰り:1週間以内に承認された一業務へ試用。作業・確認・修正時間と誤りを記録し、翌週に振り返ります。 10. 参考・出典 本講座のケース、数値、設問、解答例は研修用に作成した架空の例です。実在の制度・企業条件を示すものではありません。 参考資料の確認日:2026年10月6日。資料は概念の確認用です。演習の数値・ケースは出典資料の実績ではありません。