堅実なテスト計画が、バグが本番環境に到達するのを防ぎます。Trupeerなら、無料のテスト計画テンプレートから始めて、ブランドガイドラインでカスタマイズし、エンジニアリング、プロダクト、QAを揃える動画ウォークスルーとしてテスト計画を作成することで、テスト計画作成にかかる時間を何時間も節約できます。

無料のテスト計画テンプレートとは？

無料のテスト計画テンプレートとは、特定のリリースまたはプロジェクトで何をテストするのか、どの環境で、誰が、どのスケジュールで、そしてテストが完了したと判断する根拠は何かを示すドキュメントの再利用可能な構造です。

セクションの一覧は標準的で、議論の余地がありません。スコープ、アプローチ、環境、リソース、スケジュール、入口基準、出口基準、リスク、成果物。公開されているすべてのテンプレートにそれがあり、ISOやIEEEの伝統がそれを確立してから数十年、広く安定しています。

テンプレートが原因でテスト計画が失敗するわけではありません。失敗するのは、計画が承認された数か月後の、ある特定の瞬間であり、失敗の形はいつも同じです。

形式は用途に従います。無料のテスト計画テンプレートのWordファイルは、レビューされ合意される文章としての計画そのものに適しています。小規模なリリースなら、1〜2ページのシンプルなテスト計画テンプレートのWordレイアウトで十分です。無料のテスト計画テンプレートのExcel版は、スケジュール、カバレッジマトリクス、リソース配分に適しています。無料のテスト計画テンプレートのPDFは、リリース記録に添付される承認済みの控えであり、公開ソースからのテスト計画ドキュメントのサンプルPDFが、正しく作られたものを見る最良の方法です。

テスト計画は一度読まれ、その後に議論される

テスト計画は、テスト開始の数週間前に書かれます。誰も追い込まれていないときです。落ち着いてレビューされ、合意され、ファイルに保存されます。

その後、ちょうど一度だけ読み直されます。誰かが出荷したいと思った日、そしてテストがまだ終わっていないときです。

その瞬間、部屋にいる全員が当事者になります。日付は共有済みです。顧客はそれを待っています。マーケティングは何かを予定しています。エンジニアリングチームは何週間もこのために取り組んできており、早く終わらせたいと思っています。そして誰かがテスト計画を開き、出口基準を読み、何も決着がつかないことに気づきます。

すべての優先度の高い欠陥は解決済み。回帰スイートは合格。UATのサインオフは取得済み。

それらはどれも確かな響きがありますが、次のセクションで触れる理由により、プレッシャー下ではどれも成り立ちません。だから決定は、最も上位で最も当事者意識が高い人によって、最初からそうなる形で行われ、テスト計画は制約ではなく、指し示せる文書として機能します。

事前にテスト計画を書く価値は、落ち着いて下した決定のほうが、木曜の夜9時に下した決定よりも良いからです。この価値が実現されるのは、実際に決定が下された場合だけで、多くの計画ではそれらは「説明されただけ」になっています。

Trupeerでこのテンプレートをカスタマイズする方法

ステップ1：テンプレートセクションを開く

メインナビゲーションからテンプレートセクションへ移動します。

ステップ2：テンプレートを選択して開く

作業したい任意のテンプレートをクリックして開きます。

ステップ3：テンプレート表示を展開する

必要に応じて、テンプレート表示を展開し、レイアウトと詳細をはっきり確認します。

ステップ4：テンプレートを編集する

編集をクリックして、選択したテンプレートの変更を開始します。

エディター内で、次のことができます：

• 新しいセクションを追加

• 書式ルールを定義または更新

• ロゴを追加し、その位置および関連設定を調整

ステップ5：カスタマイズしたテンプレートを保存する

必要な変更をすべて行ったら、保存をクリックして更新済みのテンプレートを自分のものとして保存します。

ステップ6：プレビューしてテンプレートを微調整する

カスタマイズしたテンプレートの見え方を確認したいときは、プレビューを開きます。

プレビュー画面から、必要に応じてそのまま調整を続けることができ、テンプレートが希望どおりに表示されることを確認できます。

このテスト計画テンプレートでできること：

• 作成時間を節約：QA向けに構築された構造で、空白ページをスキップできます。

• テストカバレッジを向上：組み込みのセクションにより、重要な項目を見落としません。

• ブランドに合わせ続ける：Trupeerのブランドキットでロゴ、フォント、カラーを適用します。

• リリース間で標準化：すべてのプロダクトとリリースで同じテスト計画テンプレートを使用します。

• 監査対応の準備を維持：IEEE 829、ISO 29119 などの標準に整合しています。

• グローバルチームに対応：ワンクリックでテスト計画を65言語以上に翻訳できます。

最初に出口基準を書き、免除できる人の名前を付ける

変更は2つ、どちらもコストが低く、そしてこのページの主張はすべてそれに尽きます。

計画の中で最初に出口基準を書く。スコープの前に、アプローチの前に、スケジュールの前に。通常の順序を逆転させ、交渉ではなく議論になるタイミングで、最も難しい質問を最前面に押し出します。計画の他のすべては出口基準を満たすために存在するため、先に決めるほど計画は短くなる傾向もあります。

それぞれを免除できる人の名前を付ける。チームではありません。役割としての個人であり、そして「出荷することが仕事の人」ではありません。

免除の権限者とは、実際にその変更を実行する人のことです。出口基準が正式に上書きされることは、ほとんどありません。上書きする仕組みがないため、代わりに再解釈されます。欠陥が再分類される。基準が寛大に読み替えられる。誰かが、検証していないものにサインする。

再解釈は見えず、記録も残りません。免除は見え、指名された人が自分の名前を付ける必要があり、その後に参照できる何かが残ります。この違いは、他の何かを変える前に行動を変えます。会議で欠陥を再分類するのは簡単ですが、免除にサインするのは簡単ではないからです。

さらに1つフィールドを追加します。基準が免除された場合、どの補償アクションを取っているのかを記録します。まず顧客の10%に出荷する、またはロールバック準備付きで出荷する、あるいはサポートにブリーフィング済みで出荷する。補償のない免除は、リスクを受け入れるという決定にすぎず、正しい場合もあります。その場合は、少なくともそのように明記されるべきです。

出口基準を実効性のあるものにする

3つの特性があり、公開されている多くの基準にはそれがありません。

数値。「回帰スイート合格」ではなく、「回帰スイート：優先度1のケースの100%を実行、95%が合格、優先度1の失敗は0件オープン」。合格と実行は別のことです。実行と合格を区別しない計画では、実行率が60%のスイートに対して「合格90%」と報告してしまいます。

プレッシャー下にいる本人ではない検証者。重大度の分類は、すべてのテストプロセスにおける“弱点”です。欠陥を分類する人は、出荷したい人であることが多いためです。重大度を割り当てるのが誰かを明確にし、それをデリバリーラインの外の人にすることで、基準を回避する最も簡単なルートが取り除かれます。

指名された免除の権限者。上記と同様で、リリースオーナーとは別の人であるべきです。

既存の計画に対する有用な監査。出口基準を読み、それぞれについて「嘘をつかずに回避するには、誰かが何をしなければならないか」を問いかけます。答えが10秒以内に出せるなら、その基準には数値と検証者が必要です。

テスト計画テンプレートに必ず含めるべきもの

出口基準を最初に置く10の構成要素。

環境とテストデータの行は、テンプレートが与えるよりも多くのスペースに値します。本番環境に到達した欠陥の多くは、弱いテストケースによって見落とされたのではありません。テスト環境に本番の400万件ではなく1000件のレコードしかなかったため、あるいはそれらを引き起こすタイミング条件が単一のマシンでは発生し得ないため、そもそも到達できなかったのです。

無料のテスト計画テンプレート：コピーするための構造

プレースホルダーではなく、実際の例で埋めています。システムはコンビニ向けのPOSソフトウェアです。

ここからコピー。

出口基準。最初に書きます。数値、検証者、免除権限者を含めて。

免除は、リリース前に、補償アクションとともに書面で記録します。後からではありません。

入口基準。ステージングにデプロイされたビルド。スモークテスト合格。テストデータを読み込み、更新済み。前サイクルからのオープン中の優先度1の欠陥はなし。

スコープ。対象：レジ取引、返金、日次締めの照合、オフラインモード、新しいプロモーションエンジン。対象外：バックオフィスのレポーティングスイート（本リリースでは変更なし）。新しい周辺機器のハードウェア認証（別途対応）。第三者のロイヤルティプロバイダーとの連携（それぞれのサプライヤーのテストでカバーされ、その前提で受け入れる。リスクとして以下に記録する）。

アプローチ。既存のレジおよび返金パスに対する自動回帰。新しいプロモーションエンジンに対する手動の探索的テスト。模擬ピークでのパフォーマンステスト。オフラインモードはシミュレーションではなく、物理的に切断してテストする。

環境。ステージング。大規模な店舗群の本番スナップショットからデータベースを復元。2世代のハードウェアにまたがる物理レジ端末4台。なお、ステージングにはアプリケーションサーバーが1台のみで、本番は6台のため、負荷分散の挙動は再現されず、これは明示されたリスクです。

テストデータ。本番スナップショットを匿名化し、週次で更新。少なくとも、過去の取引が5万件を超える店舗を含む。取引量に関連する欠陥は以前に発生しているためです。

スケジュールとウィンドウ。3週間。実行見込みは、2名のテスターで11日分の工数。15日間のウィンドウに対して14営業日。予備日1日（薄く、リスクとして記録する）。

リソース。テスター2名、フルタイム。パフォーマンスエンジニアは3日間。UATの事業オーナーは2日間。いずれかのテスターがサポートに引き離されると、ウィンドウは成立せず、基準2が最初にリスクにさらされます。

リスク。ステージングのアプリケーションサーバーは1台。スケジュール予備日の1日。第三者のロイヤルティ連携は当社では未テスト。事業オーナーは着任したばかり。

成果物。実行済みのテスト結果（証拠付き）、欠陥レポート、テストサマリーレポート、（あれば）署名済みの免除記録。

ここにコピー。

テスト計画の例：優先度の高い欠陥3つが2つになった

Danecroft Retail Systemsはコンビニ向けにPOSソフトウェアを提供しており、約180人を雇用しています。3百40店舗の店舗群に対してメジャーバージョンをリリースしました。

テスト計画は通常のものでした。その出口基準はこう読める内容でした：優先度の高い欠陥はすべて解決済み、回帰スイートは合格、UATのサインオフは取得済み。

リリース判断の日、優先度の高い欠陥が3件オープンでした。回帰スイートは91%実行されており、計画では「実行」と「合格」を区別していませんでした。UATは、着任して5週間のプロダクトオーナーによってサインされていました。

リリースマネージャーがそれをCTOに持ち込みました。CTOは、その3つの欠陥が本当に優先度の高いものなのかを尋ねました。

その会議の間に2つは中程度に再分類されました。3つ目は、回避策が存在するという理由で受け入れられました。

誰も嘘をついていませんし、誰も何かを上書きしていませんでした。計画には「優先度の高い」の定義がなく、重大度を誰が割り当てるのかの記述もなく、回帰の実行に関するしきい値もなく、免除の権限者も指名されていませんでした。上書きするものがなかったので、記録するものもありませんでした。

再分類された2つの欠陥のうち1つは、特定のプロモーション条件下でレジがフリーズする原因でした。店舗群全体で、土曜日のピーク取引時間帯に発生しました。小売業者は、失われた売上を約89万ポンドと見積もり、契約上のペナルティを適用し、Danecroftは数か月分の手数料を相殺しました。

レビューでは、3つの具体的な弱点が特定されました。すべて出口基準にあり、テストにはありませんでした。

重大度は、出荷したいというプレッシャー下にいる人によって割り当てられていました。「合格」と「実行」が同義として使われていたため、91%は合格率のように聞こえました。そしてサインオフでは、個人が誰なのかが示されず、何を確認したのかについても何も指定されていませんでした。

書き直しでは、すべての基準に数値を付け、デリバリーラインの外の検証者を指名し、リリースマネージャーではない免除の権限者を指名し、補償アクション付きの免除を書面で要求しました。

その後の6つのリリースにわたって、免除は2件発行されました。どちらも記録され、どちらも補償アクションが伴い、リリース判断の会議中に欠陥が再分類されることはありませんでした。

テストは十分に行われていました。計画には、テストが意味を持つための仕組みがありませんでした。

6つのステップでテスト計画を書く方法

1. 最初に出口基準を、数値付きで、ドキュメントの他の何よりも先に書きます。

2. それぞれの検証者を指名し、その人の目的にリリース日が含まれていないことを確認します。

3. それぞれの免除権限者を指名します。まったく免除できない基準も含めます。少なくとも1つ免除できないものを用意することが、他の基準を意味あるものにします。

4. スコープを書きます（対象外も含めて）。各除外が許容できる理由も述べます。

5. 環境を正直に説明します。特に、欠陥を隠してしまう可能性がある点で、本番と異なるところを明確にします。

6. スケジュールの計算を行い、予備（コンティンジェンシー）を記録します。ウィンドウが圧縮されたときに、テストがほぼ終わっているかどうかではなく、どの基準がリスクにさらされているかの議論になるようにします。

ステップ3が結果を変えるものです。出荷する人がすべて免除できる計画は、意図の説明にすぎません。

スコープと、あなたがテストしないもの

対象外セクションは、テスト計画において2番目に価値の高い部分であり、多くの場合、1行で済みます。

そこには3つのカテゴリが入り、それぞれ異なります。

意図的に除外（変更されていないため）。妥当であり、その理由とともに明記する価値があります。変更されていないという前提は、時に誤りであることが判明するからです。

誰か別の人がテストするため除外。第三者コンポーネント、サプライヤー連携、ハードウェア認証。誰がテストするのか、そしてどの証拠を受け入れるのかを明記します。ここでリスクが静かに移転します。

ここではテストできないため除外。負荷分散の挙動、実際の決済ネットワーク、本番データのボリューム、真の同時実行。これらは正直なものなので、スコープセクションだけでなくリスクセクションにも登場させるべきです。なぜなら、これらはあなたのプロセスでは捕捉できない欠陥を名指ししているからです。

3つ目のカテゴリは、本番でのインシデントを予測するものです。自分たちのテストが届かない範囲を列挙できるチームは、何かが起きたときにどこを見るべきかを知っているチームです。

テスト計画、テスト戦略、テストケース？

3つのレベルがあり、それらの混同はよくあるため、はっきり書いておく価値があります。

テスト戦略は組織的なものです。この会社がどうテストするのか、どの種類のテストを使うのか、どの標準が適用されるのか。1度書けば、プロジェクト全体に適用されます。

テスト計画はリリースまたはプロジェクトに固有のものです。このページ。

テストケースは1つの確認で、手順と期待結果があります。テストドキュメントのテンプレートのページではそれらを扱っており、期待結果がどこで多くのテストスイートが間違うのか、その理由も含まれています。

そして何よりも上にあるのがQAプランです。これは欠陥を見つけるためではなく、欠陥を防ぐために行うすべてをカバーします：要件レビュー、完了の定義、コードレビューの標準。QAプランテンプレートがその違いを扱っています。QAプランにテストのことしか書いていないなら、より広いタイトルのテスト計画を書いているだけです。

リリースがそもそも出荷できるかどうかは、テストが終わったかどうかよりも広い問いです。ドキュメント、サポートの準備、請求設定もゲートになるためです。リリース要件テンプレートがそれを扱っています。

テスト計画のバリエーション

構造は維持され、重点が移ります。

アジャイルまたはスプリントごとのテスト計画。通常はずっと短く、1ページであることも多く、完了の定義に組み込まれることもよくあります。出口基準の主張はそのまま適用され、毎スプリントで決定が繰り返されるため、より重要になります。

ユーザー受け入れテスト計画。出口基準は「人が何かにサインすること」なので、本人が個人的に行ったことを何を確認しているのかを明記します。誰も読んでいないドキュメントへの署名は、一般的に使われる中で最も弱い統制です。

パフォーマンスおよび負荷テスト計画。しきい値は自然に数値になるため、実効性のある基準として書きやすいのがこれらです。難しさは、環境が代表的な負荷を生成できるかどうかに移ります。

規制対象および検証済みの環境。製薬、医療機器、類似の文脈では、テストドキュメント、トレーサビリティ、承認に関する定義済みの要件があり、計画は後年に検査され得るエビデンスパッケージの一部になります。このページの内容はそれに代わるものではないため、適用される標準に、資格のある入力で作成してください。

ハードウェアおよび統合システム。テスト計画は物理的な構成と環境条件をカバーする必要があり、環境セクションは通常、ドキュメントの中で最も長い部分になります。

無料のテスト計画テンプレートでは直せないこと

動かせない日付。リリースが予定どおりに出るなら、計画はそれを防ぐのではなく、スキップされた内容を記録するだけになります。これは正当なビジネス判断である場合もあり、合格基準として隠すのではなく、明記すべきです。

欠陥を明らかにできない環境。無料のテスト計画テンプレートの無料ダウンロードでは、本番のデータボリュームや実際の同時実行は提供できません。

利害関係者による重大度の割り当て。出口基準が回避される最も一般的な方法であり、ドキュメントの問題ではなくガバナンスの選択です。

そもそも現実的ではないウィンドウ。計画内で計算をしておけば、何かを変える時間があるうちに不足が見えるようになります。

テストが行われたことを示す

出口基準は証拠に依存し、多くの組織では証拠はステータス列です。

回帰スイートは実行されました。誰かがケースにチェックを入れました。各ケースが書かれたとおりに実行されたか、実際に何が観測されたかはどこにも記録されません。つまり、「100%実行済み」という基準の読みは、記録ではなく主張（アサーション）に依存しています。インシデント後にその主張が検証されるのですが、どちらにせよ通常は裏付けができません。

Trupeer AIは、その記録を副産物として生成します。テスト実行を記録すると、スクリーンショットがすでにキャプチャされ配置された、書面のウォークスルーが動画と並んであなたのブランドで作られます。各ステップで観測された内容は、主張ではなく存在として残ります。検証者が基準に正直にサインするために必要なのはまさにそれです。

記録する。ブランド化する。翻訳する。Trupeerする。

次の2点があります。テストが外部委託チームやオフショアチームによって行われる場合、実際に何をしたかの証拠はステータスレポートより価値があります。そして記録はそれを最も安価に残す方法です。さらに、経験豊富なテスターが複雑なシナリオを進める様子の記録は、新しいテスターが「適切な確認」がどのようなものかを学ぶ方法です。書面のケースでは伝わらない習慣です。

素材はあなたのナレッジベースに置かれ、トレーニングとしても活用できます。ドキュメント間の一貫性は、ブランドキットを一度設定するだけで実現でき、セットアップはドキュメントテンプレートのセットアップガイドで説明されています。

よくある質問

無料のテスト計画テンプレートのWord版はありますか？

Wordは計画そのものに適しています。多くの部分がレビューされ合意される文章であり、さらに通常は承認が必要だからです。テスト計画テンプレートのWordファイルは、適切な作業形式です。

出口基準の表を1ページ目に置いてください。すべてのテンプレートでそれらは末尾付近に配置されます。ドラフト作成中に最後に読まれ、最も注意が向けられにくい場所であり、そしてプレッシャー下で実際に使われるのはドキュメントの中でその部分だけだからです。

無料のシンプルなテスト計画テンプレートのWord版はありますか？

はい。小規模なリリース、または1つのスプリントであれば、1〜2ページのシンプルなテスト計画テンプレートのWordファイルで十分に適しています。

出口基準を切り取る前に、アプローチとリソースのセクションを切り取ってください。数値の基準、指名された検証者、免除権限者がある1ページの計画は、それらがない15ページの計画より価値があります。

無料のテスト計画テンプレートのExcel版はありますか？

Excelは、テスト計画の表形式の部分に適しています。スケジュール、カバレッジマトリクス、リソース配分、そして出口基準の表そのものです。テスト計画テンプレートのExcelファイルは、それらをうまく扱えます。

スコープ、アプローチ、リスクのセクションは文章であり、ドキュメントに属します。計画を2つのファイルに分けても問題ありません。ただし、どちらかが参照し合い、承認済みの版は1つだけであることが条件です。

無料のテスト計画テンプレートのPDFはありますか？

PDFは、リリース記録に添付される承認済みの控えです。合意したら、バージョンと日付付きで無料のテスト計画テンプレートPDFを1回エクスポートし、結果や免除記録と一緒に保管してください。

そのセットは、後で何か問題が起きたときに確認されるものです。そして免除記録は、人々が「欲しかった」と思う部分です。免除された内容の記録がない計画では、誰もが会議を記憶から再構成することになります。

テスト計画ドキュメントのサンプルPDFはどこで見つけられますか？

大学、公的機関の調達、規制産業では実際のものが公開されており、そうしたソースからのテスト計画ドキュメントのサンプルPDFは、市販のテンプレートよりも役立ちます。実際の制約のもとで書かれていることが多く、権限のある誰かによってレビューされていることも多いからです。

出口基準と対象外セクションを読みます。この2つが、計画が統制なのか形式的なものなのかを示します。そして、信頼性高く出荷できる組織とそうでない組織で最も違いが出るのも、このセクションです。

使う価値のある無料のテスト計画テンプレートの無料ダウンロードはありますか？

セクションの一覧は何十年も安定しているため、無料のテスト計画テンプレートの無料ダウンロードでは得られるものは多くありません。また、どのバージョンもおおむね同じ構造です。

どれか1つについて、次の1つの質問で判断してください。出口基準に、しきい値、検証者、免除権限者のためのスペースはありますか？ありません。これら3つの列を追加するのに2分しかかからず、「何かを決める計画」と「意図を説明する計画」の違いになります。

出口基準は実際に何と書くべきですか？

数値、検証者、免除権限者です。「回帰スイート合格」ではなく、「優先度1のケースの100%を実行して合格、QAリードによって検証済み、免除不可」です。

確認すべきは、誰かが仕事をせずに、かつ嘘をつかずにその基準を満たせるかどうかです。欠陥が再分類できるなら、割合は合格率として読めてしまいます。また、何も検証していない人がサインできるなら、その基準には回避ルートがあり、別の条項が必要です。

テスト計画は誰が書くべきですか？

テストをリードする人で、出口基準はリリース日を所有していない誰かによって合意されるべきです。この分離が要点であり、デリバリーチームの中だけで書かれた計画は、基準が“甘く”なりがちなのはそのためです。

事業オーナーに、出口基準を特に読ませてください。通常、そのうちの1つは事業オーナーの署名に依存しており、事業オーナーが自分自身で個人的に行ったことを何を確認するのかを、事前に理解しておくべきだからです。