第2回では、ツールを動かして、要求仕様書の正解値どおりに表示されることを確認しました。でも、目視で見たのは台帳の一部のデータだけです。月末ちょうど、うるう年、入力不備——こうした境目は、たまたまそのデータが無いと気づけません。今回は、その境目を機械的に突く「テスト」で、「動いた」を「正しい」に近づけます。
1. テスト仕様書は「別のClaude」に作らせる
テストも、決まったプロンプトで作ります。ただし第2回までと、ひとつ大きく変えることがあります。設計を作ったチャットではなく、新しいチャットを開いて作ること。設計を組んだ会話の流れをテスト設計に組み込んでしまうと、設計時の思い込みも持ち込んでしまう——自分の答案を自分で採点するようなことになってしまいます。
新しいチャットに、要求仕様書 v1.1 と設計仕様書だけを添付して、このプロンプトを渡します。
あなたは、ソフトウェアのテストを設計する担当者です。
私が添付する「要求仕様書」と「設計仕様書」だけを根拠に、テストを設計してください。
あなたはこの設計には関与していません。仕様書に書かれたことだけを正とし、
実装を推測で補わないでください。
【守ってほしいこと】
- テストの「期待値（正解）」は、要求仕様書の計算例（正解値の表）に紐づける。
コードから逆算した値を正解にしない。
- 確かめるのは、仕様の境目を重点にする。
（月末・うるう年・年またぎ・期限の当日と前日・予約期限の月末ちょうど・各種の入力不備）
- 1つのテストは1つの観点に絞り、失敗したとき何が壊れたか名前で分かるようにする。
- 要求仕様書の「やらないこと」はテストしない。
【出力】
1. テスト設計仕様書（何を・なぜ確かめるか、観点の一覧）
2. テストコード（Python・pytest）いちばん大事なのは、テストの「正解」を、コードからではなく要求仕様書の計算例から取ることです。コードを見て「このコードが出す値」を正解にしてしまうと、コードが間違っていても気づけません。正解は人が決めた要求仕様書の側にある——これがテストの土台です。
MATSUお医者さんが自分自身の健康診断をしてしまうと疑いを持つことができなかったりする。正確な診断をできないのと同じです。
こうしてできた最初のテスト仕様書は、次の観点を確かめる計画になっていました。ラベルだけだと中身が見えないので、「どんな計器が・どうなるはずか」と「もし外したらどんな被害が出るか」をセットで並べます。
| 確かめること | 具体的な場面（例） | バグがあると起きる被害 |
|---|---|---|
| 校正期限の計算 | 2025-08-31に校正した6か月周期の計器→次の期限は2026-02-28（うるう年なら2-29）。年またぎの計算が可能か。 | 年またぎの計算が不正確だと期限切れを検知できない |
| 予約期限の計算 | 校正期限2026-05-31・業者のリードタイム45日→予約期限は59日前の2026-04-02（安全マージン14日込み） | 予約期限を超過することで予約できない |
| 状態の判定 | 校正期限が「今日」なら有効、「昨日」なら期限切れ。この1日の差まで | 当日と前日の境を取り違え、切れた計器をそのまま使ってしまう |
| 月の出し分け | 6月を表示したとき、5月に切れた計器（赤）は消えずに残る／予約期限が来年1月の計器はまだ出さない／予約期限が4月で過ぎても校正期限が8月ならまだ拾う。一覧は危険な順（赤→黄→グレー）に並ぶ | 過去に切れた計器や、予約を逃した計器が、一覧から消え、潜在的な期限切れが放置される（使うリスクが残ってしまう） |
| 台帳の読み込み | 列の順番が違っても、周期が「12.0」でも、業者名に空白が混じっても正しく読む。空のファイルでも止まらない | 読み込みでつまずき、計算そのものが始まらない。システムが動かない |
| エクセル出力 | 先頭に対象月と出力日。状態どおり赤・黄・グレーで色分け。計算できない計器は日付欄が「—」 | 製造部門に渡す紙で、危険な計器の色や日付が抜け落ち、潜在的なリスクがあるものとして残ってしまう |
境目も、たとえば「校正期限が今日なら有効・昨日なら期限切れ」という1日の差まで押さえています。当たり前の挙動だと感じますが、実際にテストしないとわからない挙動です。テストして初めてこのアプリの品質を評価できます。
2. できたテストを「リスクの目」で問い直す
もし、プログラムがわからない、何を聞いておくべきかわからない場合、Web Claudeに直接尋ねてみると答えてくれます。ただし、闇雲に聞くのではなく、被害が大きいものを優先的にテストできているか理解することをおすすめします。具体的には、計算のバグが発生すると、校正期限が切れた計器がリストに上がってこず、検知できません。小さな文字化けよりも、こうした手痛いバグを集中的にテストできているかを聞くとよいです。
テストが失敗したとき、被害が大きい順番に並べてみる
MATSUこのテスト項目を、起きたときの被害が大きい順に並べ替えてください。いちばん上は何ですか。このツールで最悪の事故は「期限切れの計器を使ってしまう」ことです。それを防ぐテストは、十分に入っていますか。
Web Claude被害がいちばん大きいのは「期限切れ判定の向き」です（期限が切れているものを有効、逆に切れていないものを期限切れと判定する）。ここが逆だと、切れている計器を「有効」と誤判定して、そのまま使ってしまう。最終防壁そのものです。核は押さえていますが、十分とは言い切れません。手薄なところが3つあります。
期待損失でみたとき、手薄なのに被害が大きいパターンは何か聞く
MATSU期待損失（起きやすさ × 痛さ）で見て、手薄なのに被害が大きいのはどれですか。
Web Claude最有力は「時間が進んだときの遷移」です。同じ計器が、月をまたいで 有効 → 予約期限を過ぎても見落とさず黄 → 校正期限を過ぎて赤、と正しく変わるか。各点は単体で確認済みですが、つなげて追えていません。ここを外すと、予約期限を過ぎた計器がどの月にも出てこなくなり、誰も気づかないまま校正切れになります。次に「過去の月を表示したときに赤・グレーが出るか」（いまは未来の月でしか確認していない）、そして「読み込み→判定→一覧づくりを通しで流す結合テスト」。部品は固くても、つなぎ目は手薄です。
テスト単位の妥当性 ー 原因がわかる単位になっているか
MATSU各テストは、失敗したとき原因がすぐ分かる単位になっていますか。
Web Claudeおおむね適切です。1つのテストが1つの観点に絞られていて、名前を見れば何が壊れたか分かります。これ以上細かく割ると数が膨らむので、今の粒度が妥当です。
何をテストすべきか、いろんなパターンを増やすのではなく、いちばん痛いところ（期限切れの見逃し）に、テストが当たっているかを問い直した結果、手薄な部分が3つ見つかりました。
| 足した観点 | 具体的な場面 | バグがあると起きる被害 |
|---|---|---|
| 時間が進んだときの遷移 | 同じ1台が、5月は「まだ出さない」→6月は「予約して（黄）」→9月は「使用禁止（赤）」と変わる（予約期限が来てから校正期限までは黄色で出続ける） | 予約期限を過ぎた計器がどの月にも出てこなくなり、気づかないまま校正切れになる |
| 過去月の表示 | 6月の作業で2月分を振り返ったとき、2月に切れた計器がちゃんと赤で出る | 月を戻すと期限切れ・不備が一覧から消え、放置されて期限切れの計器を使ってしまう |
| 結合テスト（通し） | 台帳を読む→計算する→一覧に出す、を通しで1回流す | 部品は正しいのに、つなぎ目のズレで一覧が空や欠落になり、判断を誤る |
これを初版に足して、テスト仕様書を v2.0 にします。
3. テストを実装して、結果をドキュメントで受け取る
テストコードは、さきほどのテスト設計のプロンプトで一緒に出力させてあります。あとは Claude Code に、それを実装・実行してもらうだけです。今回は結果を .docx のレポートにまとめてもらうことにしました。
添付のテスト設計仕様書 v2.0 にもとづくテストを、core.py に対して実行し、
結果を .docx にまとめてください。
1. テストコード（pytest）を配置し、core.py に対して実行する。
期待値は要求仕様書 v1.1 の計算例を基準にする（コードから逆算しない）。
2. 結果の概要を .docx で出力する。盛り込むのは次の3点：
・合格／失敗の合計件数
・観点ごとの件数と合否
・失敗があれば、どの観点で・何が期待値とズレたかClaude Code は、テストを配置して実行し、結果を観点ごとに集計したレポート（.docx）を出力しました。結果は——
リスクの目で補強した3つ（時間遷移・過去月・結合）も含めて、すべて合格でした。期限切れの見逃しに直結する境目も、要求仕様書 v1.1 の正解値どおりです——校正期限の当日は有効・前日は期限切れ、予約期限を過ぎても校正がまだ切れていなければ見落とさず黄で拾う、月をまたいでも有効→黄→赤と正しく変わる。高リスクも含めて評価できています。
観点ごとの件数と合否、そして失敗が出たときの詳細（どの観点で・何が期待値とズレたか）は、下のレポートにまとまっています。
理解していただきたいのは、テストでバグがないことを証明するのは不可能だ、という点です。「ない」ことの証明はそもそもできません。だからこそ、リスクで優先順位をつけてテストすることや、異常が起きたときにプログラムのどこで問題が出ているかを表示するなど、バグがある前提で作っておくことが必要です。
4. まとめ
- テストは「別のチャット」で、仕様書だけを渡して作った（設計者の思い込みを持ち込まない）
- テストの正解は、コードからではなく要求仕様書の計算例から取った
- できたテストを「リスクの目」で問い直し、手薄な3つ（時間遷移・過去月・結合）を足して v2.0 に
- 走らせて全部緑。ただし「テストした範囲で正しい」であり、テストは万能ではない
これで、要求仕様（第1回）・設計と実装（第2回）・テスト（今回）がそろいました。ただ、テストで使ったのは「境目を突くために作った」データです。次回は、実際の運用に近いデータでツールを回してみて、現場で本当に使えるかを確かめます。
使用しているデータ・業者名・計器名はすべて架空のものです。実在の企業・校正機関とは関係ありません。
コメント