ソフトウェアテストにおけるテスト計画(例)
⚡ スマートサマリー
テスト計画とは、ソフトウェアテストの範囲、目的、リソース、スケジュールを概説した包括的な文書であり、アプリケーション品質の体系的かつ管理された検証を確実にします。テスト計画は、すべてのテスト活動を明確かつ正確に導く基礎的な青写真として機能します。

テスト計画
A テスト計画 テスト計画とは、ソフトウェア製品のテストに必要なテスト戦略、目的、スケジュール、見積もり、成果物、リソースを詳細に記述した文書です。テスト計画は、テスト対象アプリケーションの品質検証に必要な労力を決定するのに役立ちます。テスト計画は、ソフトウェアテスト活動を明確なプロセスとして実施するための青写真として機能し、テストマネージャーによって綿密に監視・管理されます。
ISTQB の定義によると、「テスト計画とは、意図したテスト活動の範囲、アプローチ、リソース、およびスケジュールを記述した文書です。」
次のテスト プランの例/シナリオから始めましょう。会議で、チーム メンバーとテスト プランについて話し合いたいのですが、メンバーは興味を示しません。
そんな時、あなたならどうしますか?次の図のように答えを選択してください。
A) 私はマネージャーであり、言ったとおりにすべて行います
B) では、テストプランが必要な理由を説明しましょう。
誤答
テストマネージャーとして、あなたはチームに自分のやりたいことを強制するのではなく、テスト計画の重要性を説明する必要があります。
正解
テストマネージャーとして、あなたはチームに自分のやりたいことを強制するのではなく、テスト計画の重要性を説明する必要があります。
👉 無料のライブソフトウェアテストプロジェクトに登録する
テスト計画の重要性は何ですか?
テスト計画ドキュメントを作成すると、さまざまな利点があります。
- 開発者、ビジネスマネージャー、顧客など、テストチーム以外の人々を支援する わかる テストの詳細。
- テスト計画 ガイド 私たちの考え。 それは従う必要があるルールブックのようなものです。
- テストの見積もり、テスト範囲、 テスト戦略 文書化された テスト計画に組み込むことで、管理チームがレビューし、他のプロジェクトで再利用できるようになります。
テスト計画の種類
のXNUMXつの主なタイプがあります テスト計画 ソフトウェアテストにおいて。
- マスターテスト計画: すべてのテストレベルにおける全体的なテスト戦略、範囲、リソース、スケジュールを概説した高レベルのドキュメント。プロジェクトのマスターロードマップとして機能します。
- レベル別テストプラン: ユニットテスト、統合テスト、システムテスト、受け入れテストなど、特定のテストレベルに焦点を当てます。各計画では、そのレベルにおけるアプローチ、環境、成果物を詳細に規定します。
- タイプ固有のテスト計画: Targetパフォーマンス、セキュリティ、ユーザビリティ、自動化テストといった特殊なテストの種類に対応しています。テストの種類に固有のツール、手法、基準を定義します。
これらのテスト計画を組み合わせることで、包括的なカバレッジが保証され、テストの目的がプロジェクトの目標と整合し、チーム間の調整が改善されてソフトウェアの品質が向上します。
テストプランの書き方
すでにご存知のとおり、 テスト計画 の最も重要な任務である テスト管理プロセスIEEE 829に準拠したテストプランを作成するには、以下の7つの手順に従ってください。
- 製品を分析する
- テスト戦略を設計する
- テストの目的を定義する
- テスト基準を定義する
- 資源計画
- テスト環境を計画する
- スケジュールと見積り
- テストの成果物の決定
ステップ 1) 製品を分析する
製品をテストするにはどうすればよいですか 無し それについて何か情報はありますか? 答えは 不可能製品を学ばなければなりません 徹底的に テストする前に。
テスト対象製品はGuru99のバンキングウェブサイトです。クライアントとエンドユーザーを調査することで、アプリケーションに対するニーズと期待を把握する必要があります。
- 誰がウェブサイトを使用するのでしょうか?
- それは何のために使われますか?
- それはどのように動作しますか?
- 製品ではどのようなソフトウェア/ハードウェアが使用されていますか?
サイトを分析するには、次の方法を使用できます。
次に、上記の知識を実際の製品に適用してみましょう。 解析 銀行のウェブサイト https://demo.guru99.com/V4.
あなたは取る必要があります 見回す このウェブサイトとまた レビュー 製品ドキュメント. Rev製品ドキュメントの概要は、ウェブサイトのすべての機能と使用方法を理解するのに役立ちます。不明な点がある場合は、 インタビュー 顧客、開発者、デザイナーが詳細情報を入手できます。
ステップ 2) テスト戦略を策定する
テスト戦略は、 重要なステップ ソフトウェアテストにおけるテスト計画の作成において。テスト戦略文書は、通常テストマネージャーによって作成される高水準の文書です。この文書では、以下の項目を定義します。
- プロジェクトの テストの目的 そしてそれらを達成するための手段
- テストを決定する 努力 および コスト
プロジェクトに戻りましょう。銀行ウェブサイトをテストするためのテスト戦略を策定する必要があります。以下の手順に従ってください。
ステップ 2.1) テストの範囲を定義する
あらゆるテスト活動を開始する前に、テストの範囲を明確にしておく必要があります。しっかりと検討する必要があります。
- テスト対象となるシステムのコンポーネント(ハードウェア、ソフトウェア、ミドルウェアなど)は次のように定義されます。 「範囲内」
- テストされないシステムのコンポーネントも明確に定義する必要がある。 「範囲外です。」
テストプロジェクトのスコープを定義することは、すべての関係者にとって非常に重要です。正確なスコープ設定は、プロジェクトの成功に役立ちます。
- みんなに与えて 信頼性と正確な情報 行っているテストについて。
- プロジェクトメンバー全員が持つのは、 クリア 何がテストされ、何がテストされないかを理解します。
プロジェクトの範囲をどのように決定しますか?
範囲を決定するには、次のことを行う必要があります –
- 顧客の正確な要求
- プロジェクト予算
- 製品仕様書
- テストチームのスキルと才能
ここで、テストの「範囲内」と「範囲外」を明確に定義する必要があります。
- ソフトウェア要件としては スペック、プロジェクト Guru99 Bank は、すべてのテストにのみ焦点を当てています。 機能 およびウェブサイトの外部インターフェース Guru99 銀行 (範囲内 テスト)
- 非機能テストなど ストレス、パフォーマンス or 論理データベース テストされません。(の 範囲)
問題のシナリオ
顧客からAPIのテストを依頼されていますが、プロジェクトの予算が足りません。このような場合、どうしますか?
まあ、そのような場合には、顧客に納得してもらう必要があります APIテスト 余分な作業であり、かなりのリソースを消費します。事実を裏付けるデータを提示してください。APIテストがスコープに含まれる場合、予算がXYZ額増加することを伝えてください。
顧客は同意し、それに応じて新しい範囲、範囲外の項目は
- 対象範囲内の項目: 機能テスト、API テスト
- 範囲外の項目: データベースのテスト、ハードウェアおよびその他の外部インターフェイス
ステップ 2.2) テストの種類を特定する
A テストタイプ は、期待されるテスト結果が得られる標準的なテスト手順です。
各テストタイプは、特定の種類の製品バグを特定するために策定されています。しかし、すべてのテストタイプは共通の目標「の早期発見 製品を顧客にリリースする前にすべての欠陥を確認してください。」
私達の よく使われる テストの種類は図に次のように説明されている。
全 大量のテストタイプ ソフトウェア製品のテスト用。あなたのチームは 置くことができない あらゆる種類のテストをこなすには十分な労力が必要です。テストマネージャーとして、 優先順位 テストタイプの
- どのテスト タイプにする必要があるか 焦点を当て Web アプリケーションのテストに使用しますか?
- どのテスト タイプにする必要があるか 無視され コストを節約するためですか?
ステップ 2.3) リスクと問題点を文書化する
リスクは未来 不確実な出来事 の確率で 発生 フォルダーとその下に 潜在的な 損失に対する責任を負います。リスクが実際に発生した場合、それは '問題'.
記事では リスク分析と解決策, あなたはすでに「リスク」分析について詳しく学び、プロジェクトの潜在的なリスクを特定しました。
QA テスト計画では、これらのリスクを文書化します。
| リスク | 緩和 |
|---|---|
| チームメンバーには、Web サイトのテストに必要なスキルが不足しています。 | 計画する 研修コース メンバーのスキルアップのために |
| プロジェクトのスケジュールが厳しすぎます。 このプロジェクトを期限内に完了するのは難しい | 作成セッションプロセスで テストの優先順位 各テストアクティビティについて。 |
| テストマネージャーの管理能力が低い | 計画 リーダーシップ研修 マネージャーのために |
| 協力の欠如は従業員の生産性に悪影響を及ぼします | 奨励する 各チームメンバーがそれぞれのタスクに取り組む そしてインスピレーションを与える 彼らはさらなる努力を続けます。 |
| 誤った予算見積もりとコスト超過 | を確立する スコープ 作業を開始する前に、プロジェクト計画に十分な注意を払い、進捗状況を常に追跡および測定します。 |
ステップ 2.4) テスト ロジスティックスの作成
テスト ロジスティクスでは、テスト マネージャーは次の質問に答える必要があります。
- ヘイオーストラリア テストしますか?
- 日時 テストは行われますか?
誰がテストするの?
テストするテスターの正確な名前は分からないかもしれませんが、 テスターの種類 定義することができます。
特定のタスクに適切なメンバーを選定するには、そのスキルがタスクに適しているかどうかを考慮し、プロジェクトの予算を見積もる必要があります。タスクに不適切なメンバーを選定すると、プロジェクトが頓挫する可能性があります。 失敗する or 遅れる.
ソフトウェアテストを実行するには、次のスキルを持つ人が理想的です。
- 能力 わかる 顧客の視点
- 強い 慾望 品質のために
- 注意 詳細へ
- グッド 協力
プロジェクトにおいてテスト実行を担当するメンバーは テスタープロジェクト予算に応じて、社内または外部のメンバーをテスターとして選定できます。
テストはいつ行われますか?
テストアクティビティは、関連する開発アクティビティと一致している必要があります。
準備ができたらテストを開始します 必要なすべてのアイテム 次の図に示します。
ステップ 3) テストの目的を定義する
テスト目標は、テスト実行の全体的な目標と達成目標です。テストの目的は、可能な限り多くのソフトウェアの欠陥を発見し、テスト対象のソフトウェアが バグフリー リリース前
テストの目的を定義するには、次の2つの手順を実行する必要があります。
- テストする必要がある可能性のあるすべてのソフトウェア機能 (機能、パフォーマンス、GUI など) をリストします。
- 定義 ターゲット または 目標 上記の特徴に基づくテストの
これらの手順を適用して、Guru99 Bank テスト プロジェクトのテスト目標を見つけてみましょう
あなたは選ぶことができます 'トップダウン' テストが必要な可能性のあるウェブサイトの機能を見つけるための方法です。この方法では、テスト対象のアプリケーションを以下のように分類します。 コンポーネント および サブコンポーネント.
前のトピックでは、要件仕様を分析し、ウェブサイトを実際に確認したので、 心理図 ウェブサイトの機能は次のように見つかります。
この図は、Guru99 Web サイトが持つ可能性のあるすべての機能を示しています。
上記の機能に基づいて、プロジェクト Guru99 のテスト目標を次のように定義できます。
- Guru99のウェブサイトを確認してください 機能性(口座、入金など)は実際のビジネス環境でエラーやバグなく期待通りに機能している
- ウェブサイトの外部インターフェース、例えば UI期待通りに機能し、顧客のニーズを満たしています
- その 使いやすさ ウェブサイトの。それらの機能はユーザーにとって便利ですか?
ステップ 4) テスト基準を定義する
試験基準とは、試験手順または試験判定の根拠となる標準または規則です。試験基準には以下の2種類があります。
停止基準
テストの重要な一時停止基準を指定します。 テスト中に一時停止基準が満たされた場合、アクティブなテスト サイクルが継続されます。 サスペンド 基準が決まるまでは 解決.
テスト計画の例: チームメンバーが次のような報告をした場合 40% のテスト ケースが失敗した場合、次のことを行う必要があります サスペンド 開発チームが失敗したケースをすべて修正するまでテストを続けます。
終了基準
を示す基準を指定します。 成功した テスト段階の完了。 終了基準はテストの目標結果であり、開発の次の段階に進む前に必要です。 例: 95% すべての重要なテスト ケースに合格する必要があります。
終了基準を定義するいくつかの方法は、ターゲットを指定することです。 実行速度 および 合格率.
- ランレートとは、 実行されたテストケースの数と合計テストケース テスト仕様書の。例えば、テスト仕様書には合計120個のTCが含まれているが、テスターが実際に実行したのは100個のTCだけだった場合、実行率は100/120 = 0.83 (83%)となる。
- 合格率は、 合格したテストケースの数 / 実行されたテストケースの数例えば、上記の100回のTCのうち、合格したTCは80回なので、合格率は80/100 = 0.8(80%)となります。
このデータは、テスト メトリック ドキュメントで取得できます。
- ラン レートは必須です 100% 明確な理由が示されない限り。
- 合格 料金はプロジェクトの範囲によって異なりますが、 高い合格率を達成する が目標です。
テスト計画の例:あなたのチームはすでにテストを実行しています。 彼らはあなたにテスト結果を報告し、あなたに確認してもらいたいと考えています。 終了基準。
上記の場合、実行率は必須であり、 100%しかし、テストチームはテストケースの90%しか完了していません。これは実行率が満たされていないことを意味するため、終了基準を確認しないでください。
ステップ 5) リソース計画
リソースプランとは 詳細な要約 プロジェクトタスクを完了するために必要なあらゆる種類のリソース。リソースには、プロジェクトを完了するために必要な人材、設備、資材などが含まれます。
リソース計画はテスト計画の重要な要素であり、 決定 数 プロジェクトで使用するリソース(従業員、設備など)を把握できます。これにより、テストマネージャーはプロジェクトの正確なスケジュールと見積りを作成できます。
このセクションでは、プロジェクトに推奨されるリソースを示します。
人材
次の表はプロジェクトチームのさまざまなメンバーを表しています
| いいえ。 | Member | タスク |
|---|---|---|
| 1. | テストマネージャー | 管理 プロジェクト全体 プロジェクトの定義 方向 適切なリソースを取得する |
| 2. | テスター | 適切なテスト手法/ツール/自動化アーキテクチャの特定と説明 テストアプローチの検証と評価 実行する テスト、 ログ 結果、そして レポート 欠陥。 テスターは、プロジェクト予算に基づいて、社内または外部のメンバーになることができます。 必要なタスクには 低いです スキルを選択することをお勧めします 外注 メンバーに 保存 プロジェクトのコスト。 |
| 3. | テスト中の開発者 | 実施する テストケース、テストプログラム、テストスイートなど。 |
| 4. | 試験管理者 | 積み上げて確保する テスト環境 そして資産は マネージド および 維持 サポートテスター テスト実行にテスト環境を使用する |
| 5. | SQAメンバー | 品質保証を担当します。 テストプロセスが指定された要件を満たしているかどうかを確認する |
システムリソース
Web アプリケーションをテストするには、次のようにリソースを計画する必要があります。
| いいえ。 | その他情報 | Descriptイオン |
|---|---|---|
| 1. | サーバー | テスト対象の Web アプリケーションをインストールします。 これには、個別のWebサーバー、データベースサーバー、および該当する場合はアプリケーションサーバーが含まれます。 |
| 2. | テストツール | テスト ツールは、テストを自動化し、ユーザー操作をシミュレートし、テスト結果を生成します。 このプロジェクトに使用できるテストツールは数多くあります。例えば、 Selenium、QTPなど |
| 3. | ネットワーク | 実際のビジネスとユーザー環境をシミュレートするには、LANとインターネットを含むネットワークが必要です。 |
| 4. | パソコン | ユーザーがWebサーバーに接続するためによく使用するPC |
ステップ 6) テスト環境を計画する
テスト環境とは何ですか
テスト環境とは、テストチームがテストケースを実行するためのソフトウェアとハードウェアのセットアップです。テスト環境は以下のものから構成されます。 本物のビジネス および user 環境だけでなく、サーバーやフロントエンドの実行環境などの物理環境も含まれます。
テスト環境の設定方法
プロジェクトの話に戻りますが、 テスト環境 この銀行のウェブサイトについて?
このタスクを完了するには、次のものが必要です 強力な協力 テスト チームと開発チームの間。
テスト対象の Web アプリケーションを理解するには、開発者にいくつかの質問をする必要があります。 はっきりと以下にいくつかおすすめの質問をご紹介します。もちろん、必要であれば他の質問もしていただけます。
- この Web サイトが同時に処理できる最大のユーザー接続数はどれくらいですか?
- この Web サイトをインストールするためのハードウェア/ソフトウェア要件は何ですか?
- ウェブサイトを閲覧するために、ユーザーのコンピュータに特別な設定は必要ですか?
次の図は、銀行ウェブサイトのテスト環境を示しています。 https://demo.guru99.com/V4
ステップ7) スケジュールと見積もり
記事では テストの見積もりすでにいくつかの手法を用いてプロジェクト完了までの工数を見積もってきました。今度は、その見積りとスケジュールをテスト計画に含める必要があります。
テスト見積もりフェーズでは、プロジェクト全体を小さなタスクに分割し、各タスクの見積もりを次のように追加するとします。
| 仕事 | 加盟国 | 労力を見積もる |
|---|---|---|
| テスト仕様書を作成する | テストデザイナー | 170人時 |
| テスト実行の実行 | テスター、テスト管理者 | 80人時 |
| 試験報告書 | テスター | 10人時 |
| テストの実施 | 20人時 | |
| トータル | 280人時 |
次に、 スケジュール これらのタスクを完了するには、
スケジュール作成はプロジェクトマネジメントにおいてよく使われる用語です。テスト計画において確固としたスケジュールを作成することで、テストマネージャーはそれをプロジェクトの進捗状況を監視し、コスト超過を管理するツールとして活用できます。
プロジェクト スケジュールを作成するには、テスト マネージャーには次のようないくつかの種類の入力が必要です。
- 従業員とプロジェクトの期限: 作業日数、プロジェクトの期限、リソースの可用性はスケジュールに影響を与える要因です
- プロジェクトの見積もり: 見積りに基づいて、テストマネージャーはプロジェクトの完了にどれくらいの時間がかかるかを把握し、適切なプロジェクトスケジュールを立てることができます。
- プロジェクトリスク: リスクを理解することで、テストマネージャはリスクに対処するためにプロジェクトスケジュールに十分な追加時間を追加することができます。
例を使って練習してみましょう:
上司がプロジェクト Guru99 を完了したいと考えているとします。 XNUMXつ 月単位で、テスト見積もりで各タスクの工数をすでに見積もっています。スケジュールは次のように作成できます。
ステップ 8) 成果物をテストする
テスト成果物は、テスト作業をサポートするために開発および維持する必要があるすべてのドキュメント、ツール、およびその他のコンポーネントのリストです。
テストの各段階で異なるテスト成果物があります。 ソフトウェア開発ライフサイクル.
テスト成果物が提供されます テスト段階。
- テスト計画の文書。
- テストケースのドキュメント
- テスト設計の仕様。
テスト成果物が提供されます 間に テスト
- テストスクリプト
- シミュレータ
- テストデータ
- テストトレーサビリティマトリックス
- エラーログと実行ログ。
テスト成果物が提供されます After テストサイクルは終了しました。
- 試験結果・報告書
- 欠陥レポート
- 設置/テスト手順のガイドライン
- リリースノート
テスト計画における一般的な課題(およびその解決策)
効果的なテスト計画は、しばしば実務上の課題に直面します。これらの課題を認識し、積極的な解決策を適用することで、よりスムーズな実行とソフトウェア品質の向上が実現します。
- 不明確な要件
課題: プロジェクト要件があいまいであったり、変更されたりすると、テストの範囲が不完全になります。
解決策: 要件ウォークスルーを実施し、最新の要件トレーサビリティ マトリックスを維持します。 - 限られた資源
課題: ツール、時間、または熟練したテスターの不足はテストの品質に影響します。
解決策: 重要なテスト ケースを優先し、反復的なタスクの自動化を活用します。 - 非現実的な期限
課題: 厳しいスケジュールにより、適切なテストの設計と実行に要する時間が短縮されます。
解決策: 見積り手法を使用し、リスクを関係者に早期に伝えます。 - コミュニケーション不足
課題: チーム間の不一致により、遅延ややり直しが発生します。
解決策: 透明性を高めるために、定期的な同期会議と共有ダッシュボードを実装します。 - 不十分なリスク管理
課題: 潜在的なリスクを無視すると、プロジェクトのスケジュールが狂う可能性があります。
解決策: リスクを早期に特定し、リスク ログを維持し、軽減戦略を計画します。














