テスト &#8211; AI開発実践ラボ

1.テーラリングガイド

1.テスト実施概要

テスト実施概要では、プロジェクトで定義した各テスト工程の中で、どの環境をつかって、どの資産（プログラム等）に対して、だれが、どのようなツールを使って、どのようなデータを使って、どのようにテストを行うのかということを整理します。

以下の例では、表にまとめて整理していますが、ワードを利用する場合は、テスト工程ごとにエクセルの列に定義してある以下の事項を整理していくとよいでしょう。

テスト種別：テスト工程を定義

実施環境：テストの実行環境を定義（プロジェクトごとに定義した環境の名称と合わせてSaelsforceのエディションも定義）

テスト対象：プログラム（Apex、LWC、Visualforceなど）、標準設定機能（ページレイアウト、承認プロセス、フローなど）

テスト実施方法：利用するツールやテスト実施方法、カバレッジの確認方法などを定義

利用ツール：テストで利用するツールを定義

実施担当：テストの実施担当（検証担当やデータ作成担当など詳細に分けて定義）

利用データ：テスト用のサンプルデータ、移行用の大量データ、本番相当データ（マスク済み）など

画像はクリックすると拡大表示されます。

また、テスト工程の呼び方等もプロジェクトで使用する用語に合わせて適宜変更してください。

例：単体テスト：UT（Unit Test）、結合テスト（ITa,ITb)など

2.テスト実施概要テンプレートのダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

update 2022/04/17 直接エクセルファイルをダウンロードするリンクを追加

「テスト実施概要表」（Excel）のダウンロード

ダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。

もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

以下は、スプレッドシートでの表示となります。

テスト方針書（EXCEL版）のダウンロードはこちら

まとめ

サポーターさん

テンプレートのご利用に関して不明な点があればお問い合わせください。また、テンプレートに対しての要望がありましたらご意見ください。皆様の役に立つように改善していきたいと思います。

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

工程別レビュー計画書（Excelテンプレート）サンプル

テスト観点表（Excelテンプレート）サンプル

セールスフォース標準化推進ラボ — Sun, 17 Nov 2024 06:28:07 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成したテスト観点表のテンプレートをご提供しております。

Salesforce（セールスフォース）関連プロジェクトのテスト方針作成の際は、ぜひ本テンプレートをご活用ください。

※合わせてレビュー計画書が必要な方は以下の記事よりダウンロードいただけます。

参考

1.テーラリングガイド

1.テスト観点表

テスト観点表では、プロジェクトで定義した各テスト工程の中で、システムや機能単位でどのような観点でテストを実施するのか概要レベルで整理します。

以下の例では、Salesforceの機能種別（画面、バッチ、API、標準カスタマイズなど）について、どのような観点でテストするかをマトリクス形式に纏めています。テスト観点は、品質要件を担保するために各機能でどのようなテストを実施すべきか検討し整理していきます。

品質要件は、機能性、性能・拡張性、可用性、信頼性、運用性、保守性、セキュリティ、移植性、操作性（ユーザビリティ）、移行データ品質などを定義します。

画像はクリックすると拡大表示されます。

また、テスト工程の呼び方等もプロジェクトで使用する用語に合わせて適宜変更してください。

例：単体テスト：UT（Unit Test）、結合テスト（ITa,ITb)など

2.テスト観点表テンプレートのダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

update 2022/04/17 直接エクセルファイルをダウンロードするリンクを追加

「テスト観点表」（Excel）のダウンロード

ダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。

もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

以下は、スプレッドシートでの表示となります。

テスト方針書（EXCEL版）のダウンロードはこちら

まとめ

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

Apexクラスカバレッジ管理表（Excelテンプレート）サンプル

セールスフォース標準化推進ラボ — Thu, 02 Jun 2022 02:59:57 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成したApexクラスカバレッジ管理表のテンプレートをご提供しております。

本テンプレートは、Salesforce（セールスフォース）プロジェクト以外にも活用可能なフォーマットとなっておりますので、是非をご活用ください。

1.テーラリングガイド

1.Apexテストクラス一覧（カバレッジ）

Apexクラス一覧のシートでは以下の情報を管理することができます。

Apex基本情報（Apexクラス名、APIバージョン、ネームスペース、説明）
Apexクラスのデータアクセス権限（with Sharing, without Sharing, inherited Sharing）
クラスタイプ（Triggerなど）
テストクラス名
カバレッジ目標（パーセント（％）、ステップ数（LINE））　合計（全体の平均）
カバレッジ実績（パーセント（％）、ステップ数（LINE））　合計（全体の平均）
リリース状況

Apexクラスごとにカバレッジ状況を管理できるような作りとしています。

最終行に全体としてのカバレッジ平均を算出して表示しています。

Salesforceでは、クラス単位でカバレッジを確認することが多いと思います。

開発コンソールを利用すると、メソッド毎のカバレッジも確認することができます。

Code Coverageのをクリックするとクラス全体とメソッド単位のカバレッジが表示されます。（赤枠部分）

２．メソッド一覧

メソッド単位でカバレッジを管理したい場合は、メソッド一覧のシートを利用してください。

管理できる情報は以下の通りです。

基本情報（Apexクラス名、メソッド名、説明）
アクセス修飾子（global, Public, private, Protected, Future）
メソッド種別（Static,Instance）
アノテーション（@AuraEnabled, @Deprecated , @future , @AuraEnabled, @InvocableMethod, @InvocableVariable , @isTest , @JsonAccess , @NamespaceAccessible , @ReadOnly , @RemoteAction , @SuppressWarnings ）
テストクラス名、メソッド名
テストクラス名
カバレッジ目標（パーセント（％）、ステップ数（LINE））　合計（全体の平均）
カバレッジ実績（パーセント（％）、ステップ数（LINE））　合計（全体の平均）

呼び出し元機能
リリース状況

画像はクリックすると拡大表示されます。

テストクラスの管理と合わせて、バグ（故障）管理を行う場合は、故障管理表のテンプレートも合わせてご利用ください。

参考

2.Apexクラスカバレッジ管理表テンプレートのダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

update 2022/04/17 直接エクセルファイルをダウンロードするリンクを追加

Apexクラスカバレッジ管理表（EXCEL版）のダウンロードはこちら

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

まとめ

サポーターさん

単体テスト仕様書兼結果報告書（Excelテンプレート）サンプル

セールスフォース標準化推進ラボ — Sat, 26 Mar 2022 05:37:59 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した単体テスト仕様書兼結果報告書のテンプレートをご提供しております。

本テンプレートは、Salesforce（セールスフォース）プロジェクト以外にも活用可能なフォーマットとなっておりますので、是非をご活用ください。

1.単体テスト仕様書兼結果報告書

テストケース：テスト内容を詳細に記述します。

実行前提条件：テストケースの実施にあたっての前提条件を記述します。

実行手順：テストの具体的な実行手順を記述します。

入力値：テスト実施時に入力する内容（バッチのパラメータや画面の項目への入力値など）を記述します。

期待値：実施した結果の期待値を記述します。

実行日、実行者：テストの実行日と実行者を記述します。

改修日：単体テストでNGの場合にバグ改修などが必要な場合に改修実施日を記述します。

再テスト確認日：改修後の再テストでOKとなって日を記述します。

故障管理No.：故障管理表のNo.を記述します。

故障管理

単体テストで検出したバグについては、品質管理のため故障管理表へ転記しておきます。

故障管理管理表のテンプレートはこちらからダウンロードしてご利用ください。

参考

2.課題管理表テンプレートのダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

単体テスト仕様書兼結果報告書（EXCEL版）のダウンロードはこちら

サポーターさん

ファイルは直接ダウンロードされます

まとめ

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

Backlog（バックログ）を使ってタスクやプロジェクト管理を効率化しよう

質問管理表（QA管理表/一覧）（Excelテンプレート）サンプル

セールスフォース標準化推進ラボ — Mon, 07 Mar 2022 06:40:39 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した質問管理表（QA表）のテンプレートをご提供しております。

本テンプレートは、Salesforce（セールスフォース）プロジェクト以外にも活用可能なフォーマットとなっておりますので、是非をご活用ください。

また、QA管理などのコミュニケーション管理ツール（サービス）をお探しの方は、ぜひバックログ（Backlog）をお試しください。

参考

Backlogのご紹介今回は、クリエイティブコンテンツラボトウキョウがお勧めす…

1.テーラリングガイド

1.質問管理表

管理番号：シーケンシャルな番号

タイトル：質問に関する概要がわかるようにタイトルを設定

質問内容：質問内容を詳細に記載

質問分類：質問のカテゴリを定義して選択可能にしておきます。※集計の時に分類ごとに集計

重要度：（任意）重要度管理を行う場合に利用

緊急度：（任意）緊急度を定義する場合に利用

起票者：質問の起票者（または質問者）

回答者：質問の回答を行う担当者

回答期限：回答期限の日付を指定

回答状況：ステータス管理する場合にステータスを指定

備考：任意のコメント欄

2.QA管理表テンプレートのダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

update 2022/04/17 直接エクセルファイルをダウンロードするリンクを追加

質問管理表（EXCEL版）のダウンロードはこちら

以下は、スプレッドシートでの表示となります。

質問管理表（EXCEL版）のダウンロードはこちら

まとめ

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

テスト方針書の作成（前編）はじめに~テスト環境方針

テスト方針書の作成（後編）テスト担当者方針~管理方針

セールスフォース標準化推進ラボ — Sat, 27 Nov 2021 11:51:40 +0000

前回に引き続き、テスト方針書（後編）の内容について説明していきます。

本サイトでは、テスト方針書やテスト計画書のPPT(パワーポイント)テンプレートやサンプルも用意しているので合わせてご利用ください。

前半の内容を確認したい場合はこちらの記事を参照ください。

参考

今回の記事では、全体テスト方針書の作成方法について説明したいと思います。テスト…

テスト方針書の作成（後編）

４．テスト方針

２．テスト担当者方針

テスト設計担当者やテスト実施担当者を選定する場合には、テスト品質向上の観点から適切な要員をアサインすることが望ましいです。

一般的には以下の観点で要員のアサインを行います。

参考

テスト設計者については、プログラムの仕様に関する設計を行ったものとは別の者が担当する。
本システムに関する業務仕様・システム仕様を理解しているもの、かつソフトウェア開発のテスト技法を理解しているものがテスト実施を担当する。
テスト実施に必要となる仕様の理解や、テスト技法に関する知識が乏しい場合、テスト準備期間に必要なトレーニングを実施する。

ただし、実際のプロジェクトでは、限られた要員の中でやりくりするしかないことも多いと思います。特に小規模のプロジェクトでは、設計担当者が実装やテストまですべて担当することもあると思います。

その場合には、少なくとも仕様の理解やテスト技法など理解不足の状態でのテストとならないように、必要なトレーニングや教育は実施するように心がけましょう。

３．テストツールの利用

テストで利用するツールについての方針を記述します。

例えば、Webシステムの負荷テストでよく利用されるJmeterや、APIのテストで利用するPostmanのようなものなどについて、利用するツール名やテスト工程、利用用途などをリストアップして記述しておきます。

また、ツール以外にも、第三者機関にセキュリティ診断を依頼するなど、外部サービスを利用する場合にもその内容を記述しておきましょう。

４．テスト設計方針

続いて、テスト設計の方針を記述します。

例：テスト設計では、テスト観点表を作成し、それに基づきテスト設計を行うなど。

参考

テスト観点表：テスト観点とは、作成したシステムが正しく動作するかを確認するための切り口（軸）を指す。機能/非機能テストを行う場合に、どの部分をどのようにテストするのかという観点を表に整理したもの。
テスト設計書：テスト対象の機能一覧を整理し、各機能に対して、テスト観点を掛け合わせて、テスト対象項目を抽出する。※業務フローの各プロセスや条件分岐などの粒度で作成する。
テストケース表：テストの実行単位を1ケースとする。主要項目：前提条件、実行手順、入力値、期待値、テスト結果（OK/NG)など。テスト観点表、テスト設計仕様書、各種テスト技法を組み合わせてテストケースを作成する。

テスト優先度の設計に関する観点も記述します。

参考

テスト実施の優先度については、以下の観点に基づき優先度を決定する。

業務観点でリスクの高い業務機能を優先する
業務の実行手順を考慮した優先度を設定する。（例：月初処理⇒月中処理⇒月末処理）
リソース制約（特定日しか操作できないなど）がある場合は制約を優先する。

５．テスト実施

テスト実施方針については、以下の例では、機能テストと非機能テストに分けて記述しています。

機能テストでは、例えば単体テストの実施方法として、Salesforceの標準機能に関するテスト方法、Apexなど開発したプログラムに関するテスト方法など分類しています。

参考

単体テストの実施方法

ワークフローや承認プロセスなどの標準機能のテストについては、テストケース表に基づき、UI上から操作を行い、仕様通りの動作をしているか検証する。
Apexトリガー/バッチ処理については、テストケース表に基づき、テストクラスを作成し自動テストを実行する。

上記のように各テスト工程で、機能領域ごとにどのようにテストを実施するのか明記しておきましょう。

続いて、非機能テストに関する実施方法ですが、性能テストやセキュリティテストについて具体的な実施方法や測定方法などを記述します。

参考

(1)単体性能テスト

各機能の単体性能としての性能を測定する。
オンライン（画面）に関する処理性能テストは、対象端末のブラウザからのイベント（ボタンクリックなど）を起点として、WebブラウザからのRequest⇒サーバ内部処理⇒WebブラウザでResponse受信⇒描画までのターンアラウンドタイムで計測する。(※1)
Salesforceサーバのリソースに関しては、制御負荷のため測定対象外とする。
単体性能テストは、処理結合テストにて実施する。
性能目標値は結合テスト計画段階にて検討し定めることとする。

特にブラウザを使って画面系の性能を測定する場合は、レスポンスタイムとターンアラウンドタイムの違いを意識して、どこの範囲についての性能を検証するのか図示するなど、明確に定義しておきましょう。

負荷性能テストに関しては、実施する場合には、Salesforceのサポートへお問合せし、実施内容や時間帯などを調整する必要があるので注意してください。

“テスト日の少なくとも 2 週間前までにパフォーマンステストの承認申請を行う必要があります。この 2 週間前までの通知のない要求は拒否される場合があります。要求を送信するには、ヘルプポータルに移動して、[Network and Performance (ネットワークとパフォーマンス)] > [Notify Salesforce of an upcoming activity (活動の予定を Salesforce に通知)] > [Schedule a Performance Test (パフォーマンステストをスケジュール)] を選択します。
30 日の期間を超える要求は承認されません。この場合は、複数の要求が必要です。“

引用元「パフォーマンステストに関する FAQ」より

https://help.salesforce.com/

実施体制

テスト実施体制については、体制図や体制表を用いて、全体を俯瞰できるものと、管理ルートや役割が明確にわかるように定義しましょう。

テスト工程ごとの作業内容や成果物についての役割表も合わせて作成しておきましょう。

特に、テスト計画書や仕様書についは、だれが作成し、だれがレビュー・承認を行うのか決めておく必要があります。

５．管理方針

第5章では、テスト工程における管理業務の方針を記述します。

1．進捗管理方針

最初にテストの進捗管理方針を記述します。

例では、テスト進捗管理表を用いて管理する方針としています。定量的に進捗を管理するため、以下の方法で進捗率（％）を算出しています。

消化率＝（基準日時点の消化ケース数）／（総ケース数）

テスト進捗管理表のサマリーシートを添付して、全体のケース数、消化済数の表やグラフを表示し、進捗状況が一目でわかるようにしています。

本サイトで用意しているテスト進捗管理表を利用したい場合は、以下よりダウンロードいただけます。

参考

テスト進捗管理表（Excelテンプレート）サンプル

2.品質管理方針

続いて、品質管理方針について記述します。

品質管理方針では、品質要素と品質水準を定義します。以下の例では、品質要素として、テスト密度とバグ密度の2つを定義しています。

それぞれ以下の計算式で算出します。

テスト密度の計算式：　テスト密度　＝　テストケース数/規模

バグ密度（欠陥密度）の計算式：　バグ密度　＝　検出バグ数/規模

※母数の規模に関しては、FP（ファンクションポイント）などの機能数を用いることが一般的ですが、プロジェクトの方針に合わせて定義してください。

また、各指標値については、過去の類似プロジェクトを参考にするなど、何を基準として設定するかを決めておきましょう。

3.バグ（故障）管理方針

続いては、各テスト工程で検出したバグの管理についての方針を記述します。

参考

１）各テスト工程で検出したバグは、故障管理表に記録し管理する。

また、1回目のテスト完了時に、バグの傾向分析を行い、同様のバグがほかの箇所に潜在していないか確認し、存在する場合は横展開を行う。

さらに、バグの検出密度についても指標値と比較し密度が足りていない場合には、追加テストを実施するなど、適切な対応を検討する。

故障管理表について、本サイトで用意しているテンプレートを利用したい場合は、こちらよりダウンロード‘いただけます。

参考

4.回帰テスト実施方針

回帰テストについては、どのタイミングで実施するのか。どの範囲までテストするのかについて方針を決めておきます。

参考

テスト範囲の決定について

回帰テストの実施範囲に関しては、テスト対象機能の修正や変更内容により、影響範囲を調査の上、テスト責任者が必要なテストケースを決定する。
回帰テストの実施タイミングについては、バグ修正後や仕様変更後、また環境やパラメータの変更後に実施する。また、回帰テストによりデグレードが発生した場合には、すべてのテストケースが正常となるまで繰り返し回帰テストを実施する。

5.課題管理方針

最後に、課題の管理方針について記述します。

テスト工程で発生した課題について、どのように管理・運用するのか記述すればよいでしょう。

まとめ

テスト方針に関する説明（後編）は、ここまでとなります。

テスト方針書（PPT版）のテンプレートが必要な方は、以下の記事からダウンロードしていただくことができます。

参考

テスト方針書（PPT版テンプレート）サンプル

テスト計画書の作成（結合テスト）（１）計画書の構成~基本事項の記載

テスト計画書の作成に関する記事は以下となります。

参考

みなさん、こんにちは。今回の記事は、テスト計画書の作成がテーマとなります。最近…

テスト方針書の作成（前編）はじめに~テスト環境方針

セールスフォース標準化推進ラボ — Fri, 26 Nov 2021 13:27:10 +0000

今回の記事では、全体テスト方針書の作成方法について説明したいと思います。

テスト方針書やテスト計画書については、本サイトの中でも特に人気のコンテンツとなっています。

本サイトでは、テスト方針書やテスト計画書のPPT(パワーポイント)テンプレートやサンプルも用意しているので合わせてご利用ください。

※2021/11/26　テスト方針書については、Excel版の内容をアップグレードしたPPT版を新規追加しました。

テスト方針書の作成手順

１．テスト方針書の章立て（目次）

まずは、テスト方針書の全体の目次をご紹介します。

【テスト方針書（章立て）】参考

目次
改訂履歴

はじめに
1. 本書の目的
2. 本書の構成
基本事項
1. 各テストの位置づけ
テスト範囲
1. 前提条件と制約事項
2. テスト範囲
3. テスト対象
テスト方針
1. テスト環境方針
2. テスト担当者方針
3. ツールの利用方針
4. テスト設計方針
5. テスト実施方針
管理方針
1. 進捗管理方針
2. 品質管理方針
3. バグ（故障）管理方針
4. 回帰テスト方針
5. 課題管理方針
添付資料（Appendix）
1. 用語集

上記は中規模程度を想定したものとなっています。小規模であればもう少し簡素なものでもよいと思いますし、大規模プロジェクトであれば、記載すべき事項はもっと多くなると思いますので、プロジェクトに合わせて、適宜変更してください。

1.はじめに

１．本書の目的

画像はクリックすると拡大表示されます。

まずは、テスト方針書を作成する目的を記述します。テスト方針書は、あくまで今回のプロジェクトでは、どのような方針でテストを進めるのかについて大枠の方針を決定するための位置づけとなります。

詳細な内容は、テスト方針書でお客様や関係者と合意した内容に基づき、各テスト工程でテスト計画書を作成していきます。

テスト方針の段階で検討しておくべき事項について合意形成することが目的となります。主に以下のような内容について定義します。

テスト範囲やテスト対象（対象外）の明確化
環境や体制などのリソースに関する方針
テスト設計や実施に関する方針
品質や進捗の管理方針など

２．本書の構成

構成に関しては、テスト方針書と別紙になるものがあれば定義しておきましょう。

用語集などは、方針書（本書）に入れてしまってもよいと思います。

２．基本事項

続いての基本事項では、最初に関係者間でテストに関する事前の認識合わせが必要な内容について定義しておきます。

以下の例では、今回のプロジェクトのテスト工程の定義（単体テスト、内部結合テスト、外部結合テスト…）では、対象とテスト観点についての説明をしています。

また、Salesforceのシステム構成（基盤・ミドル・アプリ）に対して、各テスト工程で、どの部分をどのようにテストするのか概要図で説明しています。

単体テスト（UT）では、プログラム、コンポーネント、ユニットに関する説明
内部結合テストでは、処理結合テスト、機能結合テスト、業務結合テストでそれぞれ何を検証するのかを説明
外部結合テストでは、本システムと外部システムのインタフェースに関するテストを実施と明記

上記は、機能に関するテストの説明となりますが、続いて以下の図では、非機能に関してのテストの説明を行っています。

非機能に関しては、性能・セキュリティ・基盤に関するテストの概要をそれぞれ説明しています。

特にセキュリティや基盤周りについては、Salesforceのサービスとして担保されている部分については、テストを実施しないということも明記しておきましょう。

３．テスト範囲（スコープ）

１．前提条件と制約事項

3章では、テスト範囲について記述していきます。

最初に前提条件と制約事項を明記しておきましょう。コスト・期間などの制約以外にも環境や要員などのリソースの制約等も記載します。

参考

例えば、以下のようなものが考えられます。

（前提条件）本プロジェクトで利用するクラウドサービス（Salesforce）のサービス基盤に関するセキュリティや脆弱性に関するテストは実施しない。また、Salesforceが提供する標準機能に関しては、単体テストは実施対象外とする。

（環境制約）他システムとの連携テスト実施にあたり、他システム側は現在運用している環境しかないため、連携テストでは、休祝日等の非営業日を利用して、一時的に環境の切り替えを行ってテストを実施するなど。

サービス基盤側で担保されているような内容に関しては、対象外とすることでテスト工数を削減できますが、契約段階などで事前に合意しておくとよいでしょう。

２．テスト範囲

テスト範囲については、まず全体のシステム構成を提示し、各システムのどの領域をテスト対象とするのかを線引きします。

複数のベンダーが関係している場合には、各社がどの領域をテストするのかわかるように色を変えて、〇〇社担当領域など明示しておき、各社で認識を合わせておくことがよいでしょう。

３．テスト対象（機能）

続いては、具体的なテスト機能について記述していきます。テスト方針の段階でまだ詳細な機能が不明な場合には、機能のまとまり（領域）で定義して、テスト計画の段階で詳細化してください。

３．テスト対象（非機能）

非機能に関するテスト対象と対象外の事項について記述します。

特に、処理性能やセキュリティなどのテストに関しては、どこまでどのようなテストを実施するのか曖昧なままとならないように、しっかり定義しておきましょう。

テスト対象外の事項については、なぜ実施しないのか、理由も合わせて記述するようにしましょう。

４．テスト方針

１．テスト環境方針（サーバ）

テスト環境方針では、各テスト工程でどの環境を使ってテストをするのかを定義します。

参考

単体テストでは、開発目的で作成するSandbox（Developer）と同じ環境を使ってテストを実施する。本環境については、お客様のシステム担当者様にて、〇月〇日時点の本番環境をコピーして作成していただく。

※本開発環境は、〇〇社と共同で利用することになるため、共通設定（システム設定、権限設定など）を変更する場合には、事前に通知し合意を得たうえで実施する。

補足）テスト環境構築

各テスト工程における、環境構築イメージ

例では、開発したリソースを変更セットで別環境へ移送するやり方としていますが、プロジェクトによって環境管理のやり方は異なると思います。

また、変更セットだけでは対応できない内容もあるため、それらをどのように扱うのかも決めておくとよいでしょう。

変更セットで対応できない資材については、直接gitやSandboxなどからリリースできるXgeekが提供するPipelineを利用するとよいでしょう。

XgeekやPipilineについて詳しく知りたい方はこちらの記事を参照ください。

参考

Pipeline for Salesforceを使って簡単にメタデータの移行を行う（xgeek.net）

今回は、xgeek.netさんが提供する無料ツールであるPipeline for…

補足）Sandboxの種類による相違点の説明

どのテスト工程でどの環境を利用するか検討するときには、利用するSandboxの種類を選択する必要があります。

Salesforceでは、Sandboxの種類によって、格納できるデータ量・更新サイクル・利用可能な機能が異なってくるため注意が必要です。

また、お客様のご契約状況によって利用できるSandboxの種類や数が異なるため、事前に本番環境で利用可能なSandboxの状況を確認しておきましょう。

1.テスト環境方針（クライアント端末）

サーバ環境に続いて、クライアント端末についても定義しておきましょう。（端末の種類やOSの種類・バージョン、利用するアプリケーションなど）

テストする端末やOSの種類などが増えるとその分工数も跳ね上がってくるため、当初見積もりの工数や契約内容に合わせて、テスト対象を指定してください。

補足）Salesforceがサポートするブラウザの種類とバージョン

クライアント端末から利用するブラウザについては、基本的にSalesforceがサポートしているブラウザを指定するようにしましょう。

お客様によっては、サポート期限切れのIEなどが指定される場合もありますが、必ず、サポートされないことをご理解いただいたうえご利用くださいと伝えるようにしましょう。

まとめ

テスト方針に関する説明（前編）は、ここまでとなります。

続きは、次の記事へ

参考

テスト方針書の作成（後編）テスト担当者方針~管理方針

前回に引き続き、テスト方針書（後編）の内容について説明していきます。本サイトで…

テスト方針書（PPT版）のテンプレートが必要な方は、以下の記事からダウンロードしていただくことができます。

参考

テスト方針書（PPT版テンプレート）サンプル

工程別レビュー計画書（Excelテンプレート）サンプル

テスト進捗管理表（Excelテンプレート）サンプル

セールスフォース標準化推進ラボ — Sun, 21 Nov 2021 05:53:43 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成したテスト進捗管理表のテンプレートをご提供しております。

本テンプレートは、Salesforce（セールスフォース）プロジェクト以外にも活用可能なフォーマットとなっておりますので、是非をご活用ください。

※合わせてレビュー計画書が必要な方は以下の記事よりダウンロードいただけます。

参考

1.テーラリングガイド

1.テスト進捗（サマリー）

テスト進捗の全体サマリーのページです。こちらでは、報告日時点の状況を集計して予実分析をした結果を表とグラフで表示しています。

また進捗コメント欄を設け、進捗に対する定性報告も記入できるようにしてます。

遅延している場合のリカバリー案などは、別途詳細な内容を記載したほうが良い場合もありますので、その場合は適宜必要な項目を追加してご利用ください。

上記の表にある、消化済ケース数の合計は、報告日を起算日として、明細のシートから自動的に数値を取得する数式を設定しています。

また、表の数値をベースにグラフを作成しているので、こちらも報告日を変更すると自動的に更新されるように作成しています。

グラフは2種類用意しており、当初計画の予定テストケース数（総数）に対して、報告日時点で、どの程度消化できているか（進んでいるのか遅れているのか）すぐに判断できるように可視化しています。

また、もう一つのグラフでは、全体の残ケース数をベースとしており、今のペースで進めていって計画通りの期限までに終了するのか判断できるように可視化しています。

プロジェクトで管理したい指標に合わせて、取得するデータや可視化したいグラフは個別に追加・カスタマイズしてもよいでしょう。

２．テスト進捗管理表（明細）

明細のほうでは、日単位でのケース消化状況を確認できるような内容としています。

テスト期間（FROM-TO)にあわせて、実施予定日を入れて、各予定日にどのシナリオ、ケースを実施するのか決めたら、日単位で消化見込みのケース数を入力します。

（当日消化予定数）消化数累積（予定）と残ケース数（予定）は自動的に計算されるように数式を設定しています。

実績の項目についても同様で、当日消化数（実績）を入力すると累積と残ケース数が計算されるようになっています。

また、実績欄には、消化率（％）を計算する項目も用意しています。

画像はクリックすると拡大表示されます。

最後に予実欄では、消化予定のケースに対しての進捗状況を判断する数式を入れています。

予定ケース数＜実績ケース数の場合、前倒しとして、＝の場合はオンスケ、予定ケース数＞実績ケース数の場合は、遅延と判断しています。

テストの生産性を鑑みて、日々消化可能なケース数を設定するとよいでしょう。

最初のサマリーの状況と合わせて進捗状況を判断し、遅延が発生しそうな見込みがあれば、休日や残業対応や要員を増やすなどの具体的な施策を検討する必要があります。

さらに、テストを実施するとバグの対応も必要になってきますので、上記軸だけで見ているとバグ改修の対応工数が見えなくなるため、バグ管理表と組み合わせて、1つのファイルで管理するのもよいでしょう。

故障管理表のテンプレートも用意しているので、そちらも合わせてご利用ください。

参考

2.テスト進捗管理表テンプレートのダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

update 2022/04/17 直接エクセルファイルをダウンロードするリンクを追加

テスト進捗管理表（EXCEL版）のダウンロードはこちら

以下は、スプレッドシートでの表示となります。

テスト進捗管理表（EXCEL版）のダウンロードはこちら

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

工程別レビュー計画書（Excelテンプレート）サンプル

まとめ

サポーターさん

テスト方針書（Excelテンプレート）サンプル

セールスフォース標準化推進ラボ — Sat, 06 Nov 2021 11:38:10 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成したテスト方針書のテンプレートをご提供しております。

Salesforce（セールスフォース）プロジェクトのテスト方針作成の際は、ぜひ本テンプレートをご活用ください。

※合わせてレビュー計画書が必要な方は以下の記事よりダウンロードいただけます。

参考

1.テーラリングガイド

1.ドキュメント体系の検討

プロジェクトの規模や方針により、テスト実施にあたって作成する中間成果物や納品成果物が異なるため、プロジェクトで定義されたテスト関連ドキュメントの構成に合わせて修正します。

画像はクリックすると拡大表示されます。

また、テスト工程の呼び方等もプロジェクトで使用する用語に合わせて適宜変更してください。

例：単体テスト：UT（Unit Test）、結合テスト（ITa,ITb)など

2.テストスコープ

プロジェクトの内容に合わせて、システム構成図の差し替えやテストスコープの定義を更新してください。

※Salesforceの標準機能の単機能に関するテストの実施に関しては、実施しない方針で記載しているためプロジェクトの方針に合わせて適宜変更してください。

3.テスト方針

テスト環境等のリソースに関する方針は、プロジェクトの環境構成に合わせて更新してください。

また、テスト実施体制や役割等についてもプロジェクトの実態に合わせて更新してください。

2.テスト方針書テンプレートのダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

update 2022/04/17 直接エクセルファイルをダウンロードするリンクを追加

テスト方針書（EXCEL版）のダウンロードはこちら

以下は、スプレッドシートでの表示となります。

テスト方針書（EXCEL版）のダウンロードはこちら

まとめ

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

テスト計画書の作成（結合テスト）（１）計画書の構成~基本事項の記載

テスト計画書（結合テスト）（PPTテンプレート）サンプル

セールスフォース標準化推進ラボ — Sun, 31 Oct 2021 03:18:33 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した結合テスト計画書のテンプレートをご提供しております。テスト計画を立てたことがないという方もいらっしゃるかもしれませんが、この計画は品質に直結する内容となるため、なんとなくテンプレートに沿って、書いていけばよいと考えているかたは、要注意です。非常に重要な作業となりますので、計画書の各章に記載すべき内容や何のための項目なのかをしっかり理解してから記述するようにしてください。また、テスト計画書については、外部結合テスト以降の工程では、自社だけではなく他社も含めて検討するべき事項やお客様の運用を考慮した運用テストの内容なども盛り込んでいく必要があるため、しっかりとコミュニケーションをとって、抜けもれなく計画書に盛り込むようにしましょう。

結合テスト計画書（章立て）

今回は、結合テストに関するテストの計画書のテンプレートをご紹介していきます。まず、本テンプレートは、中規模程度の案件を想定した構成となっていますので、5千万以下の小規模案件ではもう少し簡素化した内容でもよいでしょう。逆に、数億以上の規模の案件になってくると、ここで紹介する内容以上に検討すべき事項も増えてきますので、まずはベースとなる内容を理解して、不足する内容があれば、追加検討することをお勧めします。

【結合テスト計画書（章立て）】参考

改訂履歴や用語集については、すべてのドキュメントにページを追加しておくようにしましょう。また、第一章の本書の目的と構成についても同様で、すべてのドキュメントには基本的にドキュメントの目的や構成を記載するように習慣化しましょう。

はじめに
1. 本書の目的
2. 本書の構成
基本事項
1. テストの目的
2. 基本方針
3. 結合テストの位置づけ
テスト計画
1. テスト範囲（スコープ）
2. テスト対象
  1. )内部結合テスト
  2. )外部結合テスト
  3. )性能（パフォーマンス）テスト
  4. )テスト対象外機能
  5. )責任範囲（責任分界点）
3. テスト実施環境
  1. )サーバ環境
  2. )クライアント環境
  3. )補足）テスト対象ブラウザ
  4. )テストツール
4. テストスケジュール
  1. )全体スケジュール
5. 体制と役割
  1. )実施体制（全体）
  2. )実施体制と役割（弊社）
6. 成果物
  1. )成果物一覧
7. テスト開始・終了条件
8. テスト工程の進め方
  1. )各作業工程の進め方
  2. )テスト要員とトレーニング計画
  3. )テスト設計
  4. )テスト実装
  5. )テスト実行
  6. )回帰テスト実施概要
  7. )テスト証跡の対象と取得方法
9. 管理方針
  1. )テストの進捗管理
  2. )インシデント管理
  3. )テスト品質管理
  4. )想定されるリスクと対策
  5. )コミュニケーション方法
10. 添付資料（Appendix）

各章のサンプルと解説例

本サイトで提供している計画書のサンプルPPTの抜粋と説明例をご紹介いたします。 ※以下のサンプルは、有料員様へご提供している資料のより抜粋したものが含まれます。

１．本書の目的

こちらのスライドでは、まず計画書の作成目的を明記しています。例では、コールセンター管理システムの結合テストの実施計画、品質管理、テスト計画、テスト観点の整理を目的としていると記載しています。実際には、これらの計画を整理して、関係各社と協議するための資料という位置づけになると思います。 ※図をクリックすると拡大表示されます。

２．基本事項

基本事項では、テスト実施の目的や方針について概要レベルで定義しましょう。何のために結合テストを実施するのか目的を明確に定義しましょう。※目的が曖昧になるということは何のためのテストか理解できていないということですのでよく考えましょう。

結合テストの位置づけ（機能テスト）

下図の例では、各テスト工程ではどの範囲をどのようにテストするのかを示していますが、これらは最初のテスト方針（全体テスト方針書）の中で記載しておくとよいでしょう。その中で、今回の結合テストはこの部分のテストを実施するということを示せればよいでしょう。

内部結合テスト

処理結合テスト：コンポーネント間の結合テスト
機能結合テスト：機能（プログラム）間の結合テスト
業務結合テスト：要件定義で定義した業務フローの要件通りに動作するか検証する結合テスト

結合テストの位置づけ（非機能テスト）

また、非機能に関するテスト方針としては、性能テストやセキュリティテスト、基盤テストなどに関してのテスト方針を記載します。 RFPでお客様から提出されていた非機能の要件については最低限網羅し、セキュリティテストに関しては、どこまでどのようにテストを実施するのか具体的に記載するとよいでしょう。

性能テスト

オンライン（画面）・端末から処理をリクエストし、レスポンスを受け取るターンアラウンドタイムが目標値を満たしていることを確認するバッチ処理・指定の時間内に処理が完了するようにスループット（処理件数/時間）が目標値を満たしていることを確認する

セキュリティテスト

・ロールやプロファイルなどの設定がセキュリティ要件を満たした設定となっているか確認する。・外部ユーザがサーバ内の機密情報にアクセスできないような権限コントロールとなっていることを確認する。・SQLインジェクションやクロスサイトスクリプティングなどへの対応が実施されているか確認する。

基盤テスト

Salesforceでは、インスタンスの負荷状況を自動的に判断し、処理負荷が高くなるとオートスケールし、負荷が一定以上高くならないように制御されている。また、サービス基盤に関しては、開発ベンダー側での制御は一切できない仕様となっているため、基盤に関するテストは実施しない方針とする。

２．テスト対象

性能（パフォーマンス）テスト

性能テストに関しては、機能単位で、制約事項や測定項目を記述し、それを踏まえて指標値を設定するように記述します。 ※指標値については、事前にお客様と検討・合意した内容を記述するようにしましょう。

負荷テストの実行について

“テスト日の少なくとも 2 週間前までにパフォーマンステストの承認申請を行う必要があります。この 2 週間前までの通知のない要求は拒否される場合があります。要求を送信するには、ヘルプポータルに移動して、[Network and Performance (ネットワークとパフォーマンス)] > [Notify Salesforce of an upcoming activity (活動の予定を Salesforce に通知)] > [Schedule a Performance Test (パフォーマンステストをスケジュール)] を選択します。 30 日の期間を超える要求は承認されません。この場合は、複数の要求が必要です。“

３．テスト実行環境（サーバ環境）

テスト実行環境については、以下はサーバ環境についての例ですが、ほかにクライアント環境についても端末（PC、スマートフォン、タブレット）とOS（windows、Mac、iOS、Android）、利用アプリケーション（ソフトウェア）などの条件も記載が必要です。また、どの工程でどの環境を利用するのか、環境移行計画についても計画し、関係各社と協議しておきましょう。

サーバ環境

結合テストでは、以下の環境を用意し利用する。 Salesforce側システムでは、開発環境で作成したリソースの単体テストまでを実施し、その後、リソースを変更セットに取りまとめて、各テスト環境へ移送する。

5.体制と役割

テスト実施の体制と役割では、外部結合テストの場合、テストケースやデータ作成などで相手システムの担当者とコミュニケーションをとる必要があるため、だれが何の役割で、コミュニケーションパスはどのようになっているのか確認しておきましょう。また自社内の体制についても役割と責任を明確にしておきましょう。

7.テスト開始・終了基準

テスト開始・終了基準については。記載すべき事項は一般的な内容が多いですが、それぞれプロジェクトの基準に合わせて、記載内容を検討しましょう。

参考

テスト設計及び関係者のレビューが完了していること。
単体テストのすべてのテストケースが終了しており、検出されたバグについてはすべて対応済みであること。
結合テスト開始時点でリリースできない機能がある場合（追加開発、仕様変更対応、残バグ）については、別途追加実施するためのテスト計画・設計が行われていること。
テスト対象のリソース（メタデータやプログラム等）がソースコード管理システムにてバージョン管理され、テスト実行時点のテストケースとソース・モジュールのバージョンの紐づけが可能となっていること。

終了基準

全てのテストケースの実行(再テスト含む)が完了していること。
発見したバグを分析し、同様のバグが潜在していないか（横並びチェック）確認済みであること。
発見した全てのバグを改修していること。また、設計書にエラーが存在した場合は、修正を完了していること。
全てのバグを改修後、必要なテストケースについて回帰テストが実施済みであること。

品質分析が完了しており、適切な改善策が実施されていること。

8.テスト実施手順

10.管理方針

１）進捗管理テストの進捗を正確に測るためには、全体のテストシナリオ、テストケースの総数や重みづけを考慮して、具体的な日程に落とし込んでいくとよいでしょう。そのうえで、ある程度バッファを持たせておくことで、バグが発生した際にもスケジュールが遅延しないようにコントロールすることができます。さらに、日々の進捗確認で、進捗率が思わしくなく、遅延しそうなリスクを早期に検出し、リカバリー策を検討することができます。進捗管理：テストの進捗については、以下の進捗管理表を用いて、テストの予実管理を実施する。インシデント（故障）管理：テストのインシデント管理については、インシデント管理表を用いて管理する。３）品質管理テスト品質の基準値については、基本的には過去の類似プロジェクトを参考に算出することが一般的です。

テスト品質

テストの品質管理として、以下の施策を実施する。 ①テスト実施によるバグの検出を行い、検出率が規定範囲内であるかどうか判断する。【バグ検出率】指標値：N％からNN%の間テスト指標としてテストケース100件につき、バグ検出件数はN～NN件を目標とします。 ※バグ検出率は弊社過去の実績と一般的な開発プロジェクト指標に照らして算出しております。

サンプルは以上となります。

2.テスト計画書の作成方法

結合テスト計画書テンプレートの利用方法（具体的な記載事項）については、以下の記事を参考にしてください。

参考

みなさん、こんにちは。今回の記事は、テスト計画書の作成がテーマとなります。最近…

３.テスト計画書のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

update 2022/04/17 直接エクセルファイルをダウンロードするリンクを追加

結合テスト計画書（結合テスト）（PPTl版）のダウンロードはこちら

以下は、スプレッドシートでの表示となります。

結合テスト計画書（結合テスト）（PPTl版）のダウンロードはこちら

まとめ

サポーターさん

テンプレート関連の記事

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。