テスト計画テンプレート（サンプル文書例）

テスト計画テンプレートとは何ですか?

テスト計画テンプレート は、テスト戦略、目的、スケジュール、見積もりと成果物、およびテストに必要なリソースを説明する詳細な文書です。テスト計画は、テスト対象のアプリケーションの品質を検証するために必要な労力を決定するのに役立ちます。テスト計画は、ソフトウェアテスト活動を定義されたプロセスとして実行するための青写真として機能し、テストマネージャーによって綿密に監視および制御されます。

aを作成するテスト計画ソフトウェアテストプロジェクトを確実に成功させるためには必須です。テスト計画を初めて使用する場合は、このチュートリアルを参照してください。テスト計画の作成方法

サンプルテスト計画テンプレートをダウンロード

テスト計画テンプレート

以下に、テスト計画の重要な要素を示します。

1はじめに
1.1 範囲
1.1.1 範囲内
1.1.2 範囲外
1.2 品質目標
1.3 役割と責任
2 テスト方法
2.1 概要
2.2 テストレベル
2.3 バグのトリアージ
2.4 一時停止の基準と再開の要件
2.5 テストの完全性
3 テストの成果物
4 資源と環境のニーズ
4.1 テストツール
4.2 テスト環境

1）はじめに

プロジェクトで使用されるテスト戦略、プロセス、ワークフロー、方法論の簡単な紹介

1.1）範囲

1.1.1) 範囲内

スコープは、ソフトウェアの機能要件、機能要件または非機能要件を定義します。 なります テスト

1.1.2) 範囲外

範囲外とは、ソフトウェアの機能要件、機能要件または非機能要件を定義します。 ならないだろう テスト

1.2) 品質目標

ここで、手動テストと自動テストで達成する予定の全体的な目標について言及します。

テストプロジェクトの目的としては、次のようなものが考えられます。

テスト対象アプリケーションが機能要件および非機能要件に準拠していることを確認する
AUT がクライアントが定義した品質仕様を満たしていることを確認する
バグ/問題は公開前に特定され、修正されます

1.3) 役割と責任

さまざまなチームメンバーの役割と責任の詳細な説明。

QAアナリスト
テストマネージャー
構成マネージャー
開発者向け
設置チーム

とりわけ

2) 試験方法

2.1。概要

プロジェクトに特定のテスト方法を採用した理由について言及します。プロジェクトに選択されたテスト方法は次のとおりです。

滝
繰り返し
アジャイル
エクストリームプログラミング

選択される方法論は複数の要因によって決まります。テスト方法について読むことができますこちら

2.2) テストレベル

テストレベルは、テスト対象アプリケーション (AUT) で実行されるテストのタイプを定義します。テストレベルは主にプロジェクトの範囲、時間、予算の制約によって異なります。

2.3) バグのトリアージ

トリアージの目的は、

各バグの解決の種類を定義するには
バグに優先順位を付け、すべての「修正予定のバグ」のスケジュールを決定します。

2.4) 一時停止基準と再開要件

一時停止基準はテスト手順のすべてまたは一部を一時停止するために使用する基準を定義し、再開基準は一時停止後にテストをいつ再開できるかを決定します。

2.5) テストの完全性

ここで、テストが完了したとみなす基準を定義します。

たとえば、テストの完全性をチェックするためのいくつかの基準は次のとおりです。

100% のテストカバレッジ
すべての手動および自動テストケースが実行されました
すべての未解決のバグは修正されているか、次のリリースで修正される予定です

3) テストの成果物

ここでは、テストライフサイクルのさまざまなフェーズで提供されるすべてのテストアーティファクトについて言及します。

簡単な納品物はこちら

テスト計画テストケース要件のトレーサビリティマトリックスバグ報告テスト戦略テストメトリクス顧客のサインオフ

4) 資源と環境のニーズ

4.1) テストツール

次のようなツールのリストを作成します

プロジェクトをテストするために必要です

4.2) テスト環境

最低限のことを記載しています ハードウェア アプリケーションのテストに使用される要件。

フォロー ソフトウェアの クライアント固有のソフトウェアに加えて必要になります。

Windows 8以上
Office 2013以降
MSエクスチェンジなど

5) 用語/頭字語

プロジェクトで使用されている用語や頭字語について言及します。

用語/頭字語	定義
API	アプリケーションプログラムインターフェイス
AUT	テスト中のアプリケーション

上記のテスト計画テンプレートフォーマットをダウンロードします。

テスト計画のサンプルドキュメントバンキング Web アプリケーションの例

1はじめに

テストプランは、Guru99 Bank プロジェクトのすべてのテストアクティビティの範囲、アプローチ、リソース、およびスケジュールを規定するように設計されています。

計画では、テスト対象の項目、テスト対象の機能、実行するテストの種類、テストを担当する人員、テストを完了するために必要なリソースとスケジュール、および計画に関連するリスクを特定します。

1.1 範囲

1.1.1 範囲内

ソフトウェア要件で定義されたwebsiteGuru99 Bankのすべての機能スペックテストする必要があります

モジュール名	該当する役割	詳細説明
バランスのお問い合わせ	マネージャー顧客	Customer顧客は複数の銀行口座を持つことができます。自分の口座の残高のみを表示するマネージャー: マネージャーは、すべての顧客の残高を確認できます。彼の監督下に入る
口座振替え	マネージャー顧客	お客様：顧客は自分の「自分」から資金を送金することができるアカウントを任意の宛先アカウントに送信します。マネージャー: マネージャーはどの送金元銀行からでも資金を送金できるアカウントから宛先アカウントへ
ミニステートメント	マネージャー顧客	ミニ明細書には、アカウントの最後の 5 つの取引が表示されますお客様：顧客は自分のミニ明細書のみを見ることができるアカウントの視聴者データを取得するマネージャー：マネージャーは任意のアカウントのミニステートメントを確認できます
カスタマイズされたステートメント	マネージャー顧客	カスタマイズされたステートメントでは、フィルタリングして表示することができます日付、取引額に基づくアカウント内の取引お客様：顧客はカスタマイズされた明細書のみを見ることができます彼自身のアカウントマネージャー: マネージャーは、任意のカスタマイズされたステートメントを見ることができますアカウント
パスワードの変更	マネージャー顧客	お客様：お客様は自分のアカウントのパスワードのみを変更できます。マネージャー: 管理者は自分のアカウントのパスワードのみを変更できます。彼は顧客のパスワードを変更できない
新規のお客様	マネージャー	マネージャー: マネージャーは新しい顧客を追加できます。
	マネージャー	マネージャー：管理者は住所、メールアドレスなどの詳細を編集できます。顧客の電話。
新しいアカウント	マネージャー	現在、システムは 2 種類のアカウントを提供しています • 節約 • 現在顧客は複数の貯蓄口座を持つことができます（1つは自分の名前で、その他共同名義等）彼は複数の異なる会社の当座預金口座を持つことができる彼が所有しています。あるいは、複数の当座預金口座と普通預金口座を持つこともできます。マネージャー：マネージャーは既存のアカウントに新しいアカウントを追加できます顧客。
アカウントの編集	マネージャー	マネージャー：マネージャーは既存のアカウントのアカウント詳細を追加したり編集したりできます
アカウントを削除する	マネージャー	マネージャー：マネージャーは顧客のアカウントを追加、削除できます。
顧客の削除	マネージャー	顧客は、アクティブな当座口座または普通預金口座を持っていない場合にのみ削除できます。マネージャー：マネージャーは顧客を削除できます。
入金	マネージャー	マネージャー：マネージャーはどの口座にも入金できます。通常、現金が銀行支店に預け入れられるときに行われます。
撤退	マネージャー	マネージャー：マネージャーはどの口座からでもお金を引き出すことができます。通常、銀行支店で現金を引き出すときに行われます。

1.1.2 範囲外

これらの機能はソフトウェア要件仕様に含まれていないため、テストされていません。

ユーザ·インタフェース
ハードウェアインターフェース
ソフトウェアインターフェース
データベース論理
通信インターフェース
Web サイトのセキュリティとパフォーマンス

1.2 品質目標

テストの目的は次のとおりです。 確認する ウェブサイト Guru99 Bank の機能をテストすることにプロジェクトは重点を置く必要があります。 銀行業務 アカウント管理、出金、残高など。に保証これらの操作はすべて機能します 通常は 実際のビジネス環境では。

1.3の役割と責任

プロジェクトで使用する必要があるのは、 アウトソーシング メンバーをテスターとしてプロジェクトのコストを節約します。

いいえ。	Member	タスク
1.	テストマネージャー	プロジェクト全体を管理するプロジェクトの方向性を定義する適切なリソースを取得する
2.	ホイール試乗	適切なテスト手法/ツール/自動化アーキテクチャの特定と説明、テストアプローチの検証と評価テストを実行し、結果を記録し、欠陥を報告します。アウトソーシングメンバー
3.	テスト中の開発者	テストケース、テストプログラム、テストスイートなどを実装します。
4.	試験管理者	テスト環境と資産を構築し、管理および維持することを保証するテスト実行にテスト環境を使用するためのテスターのサポート
5.	SQAメンバー	品質保証を担当するテストプロセスが指定された要件を満たしているかどうかを確認するためにチェックします

2 テスト方法

2.1概要

2.2 テストレベル

Guru99 Bank プロジェクトでは、3 種類のテストを実施する必要があります。

統合テスト（個々のソフトウェアモジュールを組み合わせてグループとしてテスト）
システム テスト: コンプリート, 統合された システムが指定された要件に準拠しているかを評価するシステム
APIテスト: テスト対象のソフトウェア用に作成されたすべての API をテストします

2.3 バグのトリアージ

2.4 一時停止の基準と再開の要件

チームメンバーが次のような報告をした場合 40% テストケースの 失敗した、開発チームがすべての失敗したケースを修正するまでテストを一時停止します。

2.5 テストの完全性

を示す基準を指定します。 成功した テスト段階の完了
ランレートは必須です 100% 明確な理由が示されない限り。
合格レートは 80％、 合格率を達成するのは、 義務的な

2.6 プロジェクトのタスクと見積もりとスケジュール

仕事	加盟国	労力を見積もる
テスト仕様書を作成する	テストデザイナー	170人時
テスト実行の実行	テスター、テスト管理者	80人時
試験報告書	テスター	10人時
テストの実施		20人時
トータル		280人時

これらのタスクを完了するようにスケジュールを設定する

3 テストの成果物

テスト成果物は以下のように提供されます

テスト段階前

テスト計画の文書。
テストケースドキュメント
テスト設計の仕様。

テスト中

– テストツールシミュレーター。

– テストデータ

– テスト追跡可能性マトリックス – エラーログと実行ログ。

テストサイクルが終了したら

試験結果・報告書
欠陥レポート
設置/テスト手順のガイドライン
リリースノート

4 資源と環境のニーズ

4.1 テストツール

いいえ。	その他情報	Descriptイオン
1.	サーバー	インストールするデータベースサーバーが必要です MySQL Apache ServerをインストールするWebサーバー
2.	テストツール	事前定義されたフォームにテスト結果を自動生成し、テストを自動実行できるテストツールを開発します。
3.	ネットワーク	LAN ギガビットと少なくとも 1 Mb/s の速度のインターネット回線を 5 本セットアップします。
4.	パソコン	少なくとも 4 台のコンピュータで実行 Windows 7、RAM 2GB、CPU 3.4GHZ

4.2 テスト環境

アプリケーションのテストに使用される最小限のハードウェアおよびソフトウェア要件について説明します。

クライアント固有のソフトウェアに加えて、次のソフトウェアが必要です。

Windows 11以上
Office 2021以降
MSエクスチェンジなど