テスト進捗管理表テンプレート｜消化率の計算とバグ曲線の読み方

テスト進捗管理表とは、テストの消化数・合格数・バグの検出数と解決数を1日1行で累計し、「予定どおりに終わるか」を毎日同じ数字で判断するための表です。消化率だけを追っていると、不合格で残ったケースや直っていないバグが見えず、終盤になって残り作業の多さに気づくことになります。

この記事では、貼り付けて使える管理表のテンプレートと記入例、各指標の式と数値入りの計算例、バグ曲線の4パターンの読み方、週次の進捗報告の文例までを1ページにまとめました。例は架空の「備品予約システム」の結合テスト（全240ケース、12営業日）です。

確認環境：Ubuntu 24.04、Python 3.11.15（標準ライブラリのみ）。掲載した計算結果と判定結果は、すべて2026-10-05に実行した出力です。

この記事の結論

• 消化率だけでは進捗は分かりません。消化率・合格率・未解決バグ数の3つを日次で並べて初めて、終わりが読めます。
• 「終わり」の予測は、消化ではなく合格の累計で行います。今回の例では、消化で見ると1日の遅れ、合格で見ると2日の遅れでした。
• バグ曲線は、検出の累計と解決の累計を2本重ねて読みます。2本の間隔が未解決バグ数です。
• 報告は「数字 → 読み取り → 打つ手 → 判断してほしいこと」の順に書くと、読み手がすぐ動けます。

テスト進捗管理の早見表

日次のテスト進捗管理表（テンプレートと記入例）

列の定義

「累計」で持つのは、グラフにしたときにそのままバグ曲線になり、入力もれの日があっても翌日の数字で追いつけるためです。日ごとの増分は、前日との差で求められます。

見出し行だけのテンプレート（タブ区切り）

日付  予定消化累計  消化累計    合格累計    検出バグ累計  解決バグ累計

記入例（8日目まで）

9月21日〜23日は休みのため行がありません。同じ内容のタブ区切り版です。表計算ソフトの A1 セルに貼り付けられます。

日付  予定消化累計  消化累計    合格累計    検出バグ累計  解決バグ累計
2026-09-14  20  15  12  4   0
2026-09-15  40  33  27  9   3
2026-09-16  60  52  44  13  6
2026-09-17  80  70  60  17  10
2026-09-18  100 90  78  20  13
2026-09-24  120 112 98  22  17
2026-09-25  140 133 118 24  20
2026-09-28  160 152 136 25  22

消化率・合格率・進捗率・バグ検出密度の計算

8日目（2026-09-28）の行を使って、手で計算します。総ケース数は240です。

消化率63.3%と進捗率56.7%の差（6.6ポイント）が、「実行はしたが、まだ合格していない16ケース」です。この16ケースはバグの修正を待って再テストするため、消化率が100%になった後にも作業が残ります。

Pythonで全日分を検算する

上のタブ区切りを progress.tsv として保存し、次のスクリプトを同じフォルダで実行します。

import csv
import math

TOTAL = 240        # テストケースの総数
PLAN_DAYS = 12     # テスト期間（営業日）
WINDOW = 3         # 直近何日のペースで予測するか

with open("progress.tsv", encoding="utf-8", newline="") as f:
    rows = list(csv.DictReader(f, delimiter="\t"))
for r in rows:
    for k in r:
        if k != "日付":
            r[k] = int(r[k])

print("日付        消化率  予定比  合格率  進捗率  未解決  検出密度")
for r in rows:
    run, ok = r["消化累計"], r["合格累計"]
    print(f'{r["日付"]}  {run / TOTAL:6.1%}  {run - r["予定消化累計"]:+5d}  '
          f'{ok / run:6.1%}  {ok / TOTAL:6.1%}  '
          f'{r["検出バグ累計"] - r["解決バグ累計"]:5d}  '
          f'{r["検出バグ累計"] / run * 100:7.1f}')

last, base = rows[-1], rows[-1 - WINDOW]
day_no = len(rows)
left_days = PLAN_DAYS - day_no

def forecast(label, key):
    pace = (last[key] - base[key]) / WINDOW
    need = math.ceil((TOTAL - last[key]) / pace)
    print(f"{label}: 残り{TOTAL - last[key]}件 / 直近{WINDOW}日の平均 {pace:.1f}件/日 "
          f"= あと{need}日（期間の残り{left_days}日、差 {need - left_days:+d}日）")

print()
print(f"{day_no}日目の時点（全{PLAN_DAYS}日）")
forecast("消化で見た予測", "消化累計")
forecast("合格で見た予測", "合格累計")
need_pace = (TOTAL - last["合格累計"]) / left_days
print(f"期間内に終えるのに必要な合格ペース: {need_pace:.1f}件/日")

実行結果です。

日付        消化率  予定比  合格率  進捗率  未解決  検出密度
2026-09-14    6.2%     -5   80.0%    5.0%      4     26.7
2026-09-15   13.8%     -7   81.8%   11.2%      6     27.3
2026-09-16   21.7%     -8   84.6%   18.3%      7     25.0
2026-09-17   29.2%    -10   85.7%   25.0%      7     24.3
2026-09-18   37.5%    -10   86.7%   32.5%      7     22.2
2026-09-24   46.7%     -8   87.5%   40.8%      5     19.6
2026-09-25   55.4%     -7   88.7%   49.2%      4     18.0
2026-09-28   63.3%     -8   89.5%   56.7%      3     16.4

8日目の時点（全12日）
消化で見た予測: 残り88件 / 直近3日の平均 20.7件/日 = あと5日（期間の残り4日、差 +1日）
合格で見た予測: 残り104件 / 直近3日の平均 19.3件/日 = あと6日（期間の残り4日、差 +2日）
期間内に終えるのに必要な合格ペース: 26.0件/日

計算結果の読み方

• 消化率：予定との差は−5件から−10件まで開いたあと、−8件前後で止まっています。遅れは広がっていません。
• 合格率：80.0%から89.5%へ毎日上がっています。修正と再テストが回っている形です。
• 未解決バグ数：7件を頂点に3件まで減りました。
• バグ検出密度：26.7から16.4へ下がっています。テストが進むほど新しいバグが出にくくなっている形です。
• 残り日数：消化で見るとあと5日、合格で見るとあと6日です。期間の残りは4日なので、合格で見ると2日分の差があります。期間内に終えるには、合格ペースを1日19.3件から26.0件へ上げる必要があります。

3つの指標はどれも良い方向に動いているのに、残り日数は足りない、というのがこの例の状態です。消化率の予定との差（−8件）だけを見ていると「半日ほどの遅れ」に見えますが、合格の累計で予測すると2日の差になります。

消化率・合格率・進捗率の違い

進捗率という語は、消化率と同じ意味で使われることもあります。報告書の最初に「進捗率＝合格累計÷総ケース数」のように式を1行書いておくと、読み手との食い違いを防げます。

3つの組み合わせで、次に見る場所が決まります。

バグ曲線の4パターンと次に打つ手

バグ曲線は、横軸を日付、縦軸を件数にして、検出バグ累計と解決バグ累計の2本を描いたグラフです。管理表の2列をそのまま折れ線にすれば描けます。

早見表

横ばいは「収束」と「停滞」のどちらにも見えます。見分けるには、同じ期間の消化累計が伸びているかを確かめます。消化が進んでいて検出が横ばいなら収束、消化も止まっていれば停滞です。

4パターンを数字で見分ける

検出累計・解決累計・消化累計の3つがあれば、型の当たりを付けられます。8日分の数字を前半と後半に分け、次の順に確かめる簡単な判定です（しきい値は例です）。

1. 後半の消化が前半の半分に満たない → 停滞型
2. 検出が0件の日が半分以上あり、1日で5件以上増えた日がある → 階段型
3. 後半の検出が前半以上で、未解決が増えている → 発散型
4. 後半の検出が前半より少なく、未解決が増えていない → 収束型

# 日ごとの「検出バグ累計」「解決バグ累計」「消化累計」から曲線の型を判定する
SAMPLES = {
    "A": dict(found=[4, 9, 13, 17, 20, 22, 24, 25],
              fixed=[0, 3, 6, 10, 13, 17, 20, 22],
              run=[15, 33, 52, 70, 90, 112, 133, 152]),
    "B": dict(found=[3, 7, 12, 18, 25, 33, 42, 52],
              fixed=[0, 2, 5, 8, 12, 15, 19, 22],
              run=[15, 33, 52, 70, 90, 112, 133, 152]),
    "C": dict(found=[4, 9, 13, 16, 17, 17, 17, 17],
              fixed=[0, 3, 6, 9, 10, 10, 10, 10],
              run=[15, 33, 52, 70, 78, 80, 81, 81]),
    "D": dict(found=[0, 0, 8, 8, 8, 17, 17, 17],
              fixed=[0, 0, 2, 5, 7, 8, 12, 15],
              run=[15, 33, 52, 70, 90, 112, 133, 152]),
}

def diffs(xs):
    return [b - a for a, b in zip([0] + xs[:-1], xs)]

def judge(found, fixed, run):
    d_found, d_run = diffs(found), diffs(run)
    half = len(found) // 2
    first, second = sum(d_found[:half]), sum(d_found[half:])
    open_now = found[-1] - fixed[-1]
    open_mid = found[half - 1] - fixed[half - 1]
    zero_days = sum(1 for d in d_found if d == 0)
    run_first, run_second = sum(d_run[:half]), sum(d_run[half:])
    if run_second < run_first * 0.5:
        return "停滞型"
    if zero_days >= len(found) // 2 and max(d_found) >= 5:
        return "階段型"
    if second >= first and open_now > open_mid:
        return "発散型"
    if second < first and open_now <= open_mid:
        return "収束型"
    return "判定保留（人が確認）"

print("例  前半検出  後半検出  未解決(中間→現在)  後半の消化  判定")
for name, s in SAMPLES.items():
    d = diffs(s["found"])
    half = len(d) // 2
    print(f'{name}   {sum(d[:half]):7d}  {sum(d[half:]):8d}  '
          f'{s["found"][half-1]-s["fixed"][half-1]:8d} → {s["found"][-1]-s["fixed"][-1]:<6d}  '
          f'{sum(diffs(s["run"])[half:]):9d}  {judge(**s)}')

実行結果です。例Aは、先ほどの管理表と同じ数字です。

例  前半検出  後半検出  未解決(中間→現在)  後半の消化  判定
A        17         8         7 → 3              82  収束型
B        18        34        10 → 30             82  発散型
C        16         1         7 → 7              11  停滞型
D         8         9         3 → 2              82  階段型

例Cは未解決が7件のまま動かず、後半の消化が11ケースしかありません。検出累計のグラフだけを見ると収束型とよく似ていますが、消化累計を並べると停滞型と分かります。例Dは前半と後半の検出がほぼ同じ（8件と9件）で、検出0件の日が8日のうち6日あります。

バグ曲線とバーンダウンのどちらを使うか

週次の進捗報告の文例

報告は、数字 → 読み取り → 打つ手 → 判断してほしいことの順に書きます。先ほどの8日目の数字を使った文例です。

件名：【備品予約システム】結合テスト進捗報告（9/28時点）

1. 結論
　合格ベースで2日分の遅れがあります。対策を2点行い、
　10/2（金）の完了予定を維持する見込みです。

2. 数字（9/28終了時点、全240ケース・12営業日のうち8日目）
　・消化率　　63.3%（152/240）　予定160に対し −8件
　・合格率　　89.5%（136/152）　前週末 86.7% から上昇
　・進捗率　　56.7%（136/240）　※進捗率＝合格累計÷総ケース数
　・バグ　　　検出25件／解決22件／未解決3件（前週末は7件）

3. 読み取り
　・消化の遅れは −8件前後で広がっていません。
　・合格率は毎日上がり、未解決バグも減っており、バグ曲線は収束型です。
　・ただし直近3日の合格ペース（19.3件/日）のままでは、
　　残り104件にあと6日かかり、残り4日に対して2日不足します。

4. 打つ手
　・9/29から再テスト担当を1名追加し、合格していない16件の再テストを先に進めます。
　・未解決3件のうち、予約取消のテスト12ケースを止めている1件を最優先で修正します。

5. 判断をお願いしたいこと
　・10/1（木）時点で合格累計が214件に届かない場合、
　　完了日を10/6（火）に変更する案をご相談します。

「214件」は、必要な合格ペース26.0件/日を3日続けた値（136 ＋ 26 × 3）です。判断の基準を数字と日付で先に書いておくと、次の報告で「届いた／届かなかった」をそのまま伝えられます。

状況別の言い回し

確かめて分かったこと

• 同じ表でも、消化で予測するとあと5日、合格で予測するとあと6日になりました。残り日数は合格の累計で出すほうが、実際に残っている作業に近い値になります。
• 消化率×合格率は進捗率に一致します（63.3% × 89.5% ＝ 56.7%）。3つのうち2つを報告すれば、残りの1つは読み手が自分で確かめられます。
• 検出累計が横ばいの2つの例（AとC）は、消化累計を足して初めて区別できました。バグ曲線だけを報告に貼るときは、消化率を必ず添えます。
• バグ検出密度は、未解決バグ数より早く変化を示しました。例では未解決が減り始める6日目より前の、3日目から密度が下がり始めています。
• 階段型は、前半と後半の検出数を比べるだけでは発散型と区別できませんでした（例Dは8件と9件）。検出0件の日数を数える条件を足して区別しています。

つまずきやすい点と直し方

よくある質問

Q. テスト消化率とは何ですか？ A. 予定したテストケースのうち、結果を記録し終えたケースの割合です。消化累計÷総ケース数で求めます。合格か不合格かは問わないため、合格率と組にして見ます。

Q. 消化率と進捗率の違いは何ですか？ A. 消化率は「実行した量」、進捗率は「終わったと言える量」の割合です。この記事では進捗率を合格累計÷総ケース数としています。組織によって定義が異なるため、報告書に式を書いておくと確実です。

Q. バグ曲線が収束しないときはどうすればよいですか？ A. まずバグを機能別・原因別に集計し、集中している場所を特定します。特定の機能に偏っていれば、その機能の設計書やコードの見直しを先に行い、テストはほかの機能から進めます。

Q. 合格率は何%あればよいですか？ A. 途中の時点では決まった値はなく、日ごとに上がっているかを見ます。テスト終了時は、合格していないケースの全件に理由と扱い（修正予定、対象外の合意など）が付いていることを条件にするのが分かりやすい決め方です。

まとめ

• 進捗は、消化率・合格率・未解決バグ数の3つを日次で並べて読む。
• 管理表は6列・すべて累計で持つ。予定の列は書き換えない。
• 残り日数は合格の累計で予測する。消化だけで見ると短めに出る。
• バグ曲線は検出と解決の2本を重ね、収束型・発散型・停滞型・階段型のどれかを見分ける。
• 横ばいは、消化が進んでいれば収束、止まっていれば停滞。
• 報告は数字 → 読み取り → 打つ手 → 判断してほしいことの順に書き、判断の基準を数字と日付で先に示す。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。