---
title: テスト計画とテストレポートの作り方　エンジニア向け：新人から中級へ、AI駆動開発でも迷わない型
tags:  #テスト  
author: [Yukiko](https://www.docswell.com/user/yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/K74ZRGPPE1.jpg?width=480
description: テスト計画とテストレポートの作り方　エンジニア向け：新人から中級へ、AI駆動開発でも迷わない型 by Yukiko
published: October 30, 26
canonical: https://www.docswell.com/s/yukiko_it/ZN7PVV-2026-10-30-063431
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/K74ZRGPPE1.jpg)

テスト計画とテストレポートの作り方
エンジニア向け：新人から中級へ、AI駆動開発でも迷わない型
新人向け
うさうさ研修工房
中級向け
AI駆動開発
査読済み論文


# Page. 2

![Page Image](https://bcdn.docswell.com/page/LJ1RQD9XJG.jpg)

テスト計画で決める 4つのこと
1
2
3
4
範囲
リスクと優先度
終了基準
体制と日程
何をテストし、何をテストしな
いか。「しないこと」も書く
壊れると困る所から順に。時
間が足りないときの切り捨て
順も決める
どうなったら終わりか。件数・
重大度・未解決の許容を数
値や文で決める
誰が、いつ、どの環境とデー
タで行うか
根拠： Felderer & Schieferdecker (2014)。リスクの評価を使ってテスト工程の全体を導くと、限られた資源と時間でも、重要な欠陥に力を向けやすい。
Garousi & Mäntylä (2016)：自動化は、時期・状況・やり方を誤ると失敗しうる。


# Page. 3

![Page Image](https://bcdn.docswell.com/page/GJW1MYQKE2.jpg)

新人向け／中級向け：計画とレポート
新人向け
中級向け
目標：「テンプレを埋めて、 1ページの計画とレポートを書
く」
目標：「リスクで優先度を付け、判断できる報告にする」
・計画：まず「範囲」と「終了基準」の2つを決める
・計画：リスクで優先度を付け、省くテストと理由を書く
・レポート：結果の表と、失敗の再現手順を書く
・レポート：残リスクと、リリース可否の判断材料を書く
・つまずき：何をテストしないかを決められない→ 先輩と、壊れ
ると困る所を3つ挙げる（筆者の提案）
・つまずき：件数やカバレッジだけの報告→ 数字の意味と限界
を添える（筆者の提案）
根拠：Kalyuga ら (2003)。初心者に効く丁寧な説明は、経験者には効果が薄れることがある。そこで、書き方の目標を分ける。


# Page. 4

![Page Image](https://bcdn.docswell.com/page/4EZPQXWNJ3.jpg)

テストレポートに書くこと
1
2
研究から
結果：件数と内訳（成功・失敗・未実施）と、全体の判定
Zimmermann ら (2010)：Apache・Eclipse・Mozillaの開発者と利
用者の調査（466件の回答）で、再現手順・スタックトレース・テ
ストケースが、開発者に最も役立つ一方、書き手には最も難し
いと報告されました。
失敗の詳細：再現手順・環境・ログ・期待結果
3
残リスクと、未実施の理由
4
次のアクション：誰が、いつまでに、何をするか
Inozemtseva & Holmes (2014)：大きなJavaプログラムで、テスト
数の影響を除くと、カバレッジと欠陥検出力の相関は低〜中程
度でした。カバレッジは手薄な所を探すのに有用ですが、品質
目標にはしないよう提案しています。


# Page. 5

![Page Image](https://bcdn.docswell.com/page/Y76M64G9EV.jpg)

AI駆動開発での計画とレポート
研究から分かっていること
Wang ら (2024)：LLMをソフトウェアテストに使った102の研究を整理。
テストケースの作成が代表的な用途です。
Schäfer ら (2024)：LLMでJavaScriptの単体テストを生成する実験（25
パッケージ）で、文の網羅率の中央値は70.2%、分岐は52.8%でし
た。
Perry ら (2023)：AI利用者は、安全性の低いコードを書き、安全だと
思い込みやすい傾向がありました。
Luo ら (2014)：不安定なテストは、結果への信頼を損ないます。
気を付けること（筆者の提案）
1
計画の下書きは AIに任せてよい。リスクと終了基準は、
人が決める
2
AIが作ったテストの件数や網羅率を、成果にしない。カバ
レッジは品質を保証しない
3
4
レポートの数字は、実行ログと突き合わせる
不安定なテストと、本物の失敗を分けて書く


# Page. 6

![Page Image](https://bcdn.docswell.com/page/G75Z6QVDJ4.jpg)

1ページのひな形（筆者の提案）
テスト計画（ 1ページ）
テストレポート（ 1ページ）
1
目的と対象
1
概要と全体の判定
2
範囲：含む／含まない
2
結果の表（成功・失敗・未実施）
3
リスクと優先度
3
不具合一覧（再現手順・環境）
4
終了基準
4
未実施・残リスク
5
体制・日程
5
次のアクション
6
環境・テストデータ


# Page. 7

![Page Image](https://bcdn.docswell.com/page/9J2RMPXM7R.jpg)

根拠と限界 ― どこまで言えるか
研究
分かったこと
注意点
Felderer & Schieferdecker (2014)
リスクの評価でテスト工程全体を導く
分類の整理。効果の測定ではない
Garousi & Mäntylä (2016)
自動化は時期・状況・やり方で失敗しうる
文献レビュー（実務の資料を含む）
Zimmermann ら (2010)
再現手順などが、開発者に最も役立つ
OSS3件の調査。テストレポート全般ではない
Inozemtseva & Holmes (2014)
カバレッジは品質目標に向かない
大きなJavaプログラム。欠陥検出力は変異テストで測定
Schäfer ら (2024)
LLM生成テストの網羅率の実測
JavaScript・gpt-3.5-turbo。現在のモデルとは異なる
Wang ら (2024)
LLMのテスト利用102研究を整理
サーベイ。効果の大きさは示さない
Perry ら (2023)
AI利用者は安全だと思い込みやすい
2022年ごろのモデル。セキュリティ課題
Luo ら (2014) / Kalyuga ら (2003)
不安定テストの影響／専門性逆転効果
OSSのJava／学習研究
ひな形や運用は、研究から導いた筆者の提案です。自社で小さく試して調整してください。