テスト &#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版）のダウンロードはこちら

まとめ

サポーターさん

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

Salesforceシステム要件定義書（PPTテンプレート）サンプル・利用方法

要件定義書（別紙5）「テスト要件定義書」（PPT版テンプレート）サンプル

セールスフォース標準化推進ラボ — Sun, 18 Sep 2022 09:12:56 +0000

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した要件定義書の別紙5「テスト要件定義書」（PPT版）のテンプレートの利用手順とダウンロード方法をご説明いたします。

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

要件定義書本編については以下の記事からダウンロード可能です。

参考

1.テーラリングガイド

テンプレートをダウンロード後、テーラリングガイドを参考にご自身のプロジェクトに合わせてカスタマイズしてご利用ください。

1.本書の構成

上記の通り、今回のサンプルでは、要件定義書の別紙5の位置づけで作成しておりますので、上記の構成となりますが、要件定義書の構成に合わせてテスト要件を非機能の中に入れて纏める場合もあると思います。

プロジェクトに合わせて、要件定義書の構成を検討してください。

2.目次

続いて、目次としてテスト方針書の章立て（構成）を定義していいます。

こちらについても、プロジェクトの中で章立てを検討し、目次を変更してください。

サンプルは、比較的中規模程度のプロジェクトで必要最低限の項目を定義していますが、大規模プロジェクトの場合には、より詳細な内容を定義しておくことをお勧めします。

特にスコープ、品質管理、体制・役割については、テスト工程の見積に大きく影響するため曖昧に終わらず、しっかり明確になるまで検討しておく方がよいです。

3.テストの目的・概要

テスト実施の目的と実施期間などテスト全体の概要を記載しておきましょう。

4.テスト範囲（スコープの定義）

自社が担当するテスト範囲を明確にするため、まずは、システム全体構成図の中からスコープを定義するとわかりやすいでしょう。また、スコープ外はどこか明確な場合は、同じようにスコープ外を明記しておくほうがよいでしょう。

システム領域や機能単位でスコープが明確な場合は、具体的に定義しておくほうがよいです。（非機能についても同様）

続いて、テストの前提条件や制約事項について定義します。

5.テストの位置づけ

上記は、Salesforceで構築したシステムの機能要件に対するテストの位置づけを表現したものとなります。

Salesforceのサービス基盤（プラットフォーム）部分と、設定・開発したアプリケーション部分に分けてテスト対象を定義しています。機能要件では、アプリケーション部分のみテスト対象とすることを明記し、各テスト工程でどのようなテストを実施するか説明しています。

今回対象の欄については、プロジェクトに合わせて、どの機能をどのようにテストを行うのか定義します。

内部結合テストについては、処理結合テスト、機能結合テスト、業務結合テストに分けて定義していますが、プロジェクトによって実施範囲ややり方が異なることが多いので、規模や方針に合わせて変更してください。

非機能

非機能についても同様にプロジェクトでのテストの位置づけを定義します。

主に性能テスト、セキュリティテスト、基盤テストについてのテスト観点を定義します。

例では、性能については、基本的にアプリケーション（オンライン、バッチ処理）について記載しています。

※Salesforceのプラットフォーム（基盤）に対しての性能試験（主に負荷試験）を実施する場合は、事前にサポートへ連絡して、作業内容や実施日時についての調整が必要となるので注意が必要です。

6.テスト計画書作成方針

テスト計画書の作成に関する方針を定義します。

テスト計画書として定義する項目（目次）や記載内容（粒度）について定義しておきましょう。

・スケジュール、テスト評価基準の定義、テストの開始・終了条件、テスト実施体制と役割、テスト方法（ツール）、テストデータ、テスト環境、テスト観点、エビデンス作成に関する方針、レビュー実施に関する方針など。

7.テスト環境方針

テスト環境の方針について、各テスト工程（単体テスト、結合テスト、総合テスト、受入テスト、移行リハ）毎にどの環境を利用するか定義します。

どのシステムがどのタイミングでどの環境を利用するのかわかるようにしておきましょう。

同じ環境を他のシステムや他のベンダー担当者が利用する場合もあると思いますが、その場合は占有期間や利用方針を定義しておき、テストに影響がでないように調整しておきましょう。

8.テスト設計方針

テスト設計に関して定義します。

通常は各テスト工程に適したテスト観点表を作成して、内部レビューを実施した上で、テスト設計を行う流れになると思います。

9.テスト担当社方針

テスト担当として、テスト設計を行う担当者とテストの実施を行う担当者についてそれぞれ定義します。

記載例）

テスト設計者については、システムの業務要件、各種テスト技法を把握している者など、設計に必要な知識を要しているものを担当社とする

10.テスト実施概要

テスト実施概要の章では、各テスト工程でのテスト概要を記載します。

11.テストデータ作成方針

テストデータの作成方針では、各テスト工程で、それぞれ作成するテストデータの内容が異なるため、どのようなテストデータを作成するのかわかるように記述しておきます。

例：外部結合テストや統合テスト（システムテスト）については、システムの上流側で生成されるデータを利用する

12.テスト実施体制と役割

テスト工程での関係各社の役割を定義します。

特に他社と共同で行うテスト工程では、テストシナリオやケースの作成やテストデータの作成について、誰がどの範囲を担当するのかを明確にしておきましょう。

お客様については、UAT以外は主に設計や実施結果の報告についてのレビューを実施していただくことが多いと思います。

また、UAT（ユーザ受入テスト）について、シナリオの作成やデータの準備はベンダー側で実施すると考えているお客様がいる場合もあるため、誰が実施するのか協議の上確定し、本書に決定内容を記述しておきましょう。

13.テスト品質管理方針

テスト品質は、非常に重要な内容となります。具体的に定量的に品質評価するための評価方法や、メトリクス、定量指標の決定などに関する基本方針を定義します。

システムの品質管理は、しっかりやるとかなりの工数がかかる作業となり、また品質管理のスキルも必要となります。

テスト品質の管理として、どこまで実施するのか、どの部分は実施しないのか明確にしておきましょう。

14.成果物の定義

最後にテスト工程で作成する成果物を定義しておきます。エビデンスの作成が必要な場合は、具体的にどのようなエビデンスを作成するのか明確に定義しておきましょう。

例：画面のスクリーンショット、システムログの取得など

15.補足資料（Appendix）

テスト要件に関する補足資料がある場合は、追加するか別紙として定義しておきましょう。

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

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

資料ダウンロード

要件定義_要件定義書_別紙4「テスト要件定義書」_(ワイド版16：9)（PPT版）のダウンロードはこちら

2.まとめ

テスト方針書についてはこちらの記事を参照ください。

参考

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

サポーターさん

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

サンプルコード（テンプレート）Apex/Lwc/Visualforce/Flow

Batch Apexサンプルコード（取引先の部門を一括更新するバッチ処理）

セールスフォース標準化推進ラボ — Sun, 03 Jul 2022 07:42:16 +0000

バッチ処理の概要

処理概要：取引先の部門項目を一括で更新するApexバッチ処理となります。

以下、取引先部門が未設定の取引先レコードに対して、一括で’未設定’という固定値を設定する処理

バッチを実行することで、以下のように取引先部門に’未設定’の文言が一括でセットされます。

Batch Apexのサンプルコード

Batch Apexのサンプルクラス、スケジューラ、テストクラスの基本セット

詳細な仕様は公式の開発者ガイドを参照「Apexの一括処理」してください。

取引先の部門更新処理バッチ（BatchApexUpdateAccount.cls）

/**
 * プログラム名：BatchApexUpdateAccount
 * 概　　　要　：取引先の部門を一括で更新するためのバッチ処理
 * 作　成　日　：2022/07.01
 * 作　成　者　：cclt(David)
 * 変更履歴　　：
 */
global class BatchApexUpdateAccount implements Database.Batchable, Database.Stateful {

    //取引先部門に設定する固定値を定義
    private final String SITE_DEFAULT_VALUE = '未指定';

    /**
     * スタートメソッドでは、QueryLocatorを使ってバッチ処理を行うレコードを取得する
     * 本サンプルでは、取引先の部門を更新するため部門がNULLのレコードを全て取得する
     **/
    global Database.QueryLocator start(Database.BatchableContext BC) {
        
        //取引先部門（Site）が未設定の取引先レコードをすべて取得
        String query = 'SELECT Id, Name, Site FROM Account Where Site = null';
        return Database.getQueryLocator(query);
    }
        
    /**
     * スタートで取得したレコードのリストをパラメータとして、メイン処理を実行
     * バッチ実行時に処理するレコード数が指定されていない場合、デフォルトでは200レコードずつ分割して処理される。
     */
    global void execute(Database.BatchableContext BC, List accList) {
        
        //取得した取引先部門が未指定のレコードについて、固定値'未指定'をセットする。
        for(Account acc : accList) {        
            try {
                //取引先部門に固定値をセット
                acc.Site = this.SITE_DEFAULT_VALUE;
            } catch(Exception e) {
                //桁数を超過する文字列をセットした場合などにエラーが発生します
                System.debug('エラーが発生しました。' + e.getMessage());
            }
        }
        /**
         * Database.SaveResultを使って処理したレコード1件ずつチェックし
         * 異常終了（エラー）の場合にはCSVファイルにエラーメッセージを添付しメール通知する
         * **/
        Database.SaveResult [] updResultList = Database.update(accList,false);
        for (Database.SaveResult di : updResultList) {
            //エラーの場合は、レコードにエラーメッセージを設定
            if (!di.isSuccess()) {
                for(Database.Error err : di.getErrors()){
                    System.debug(err.getStatusCode() + ': ' + err.getMessage());
                    System.debug('登録エラー: ' + err.getFields());
                }   
            } else {
                System.debug('正常終了');
            }
        }
    }   
    
    /**
     * バッチ処理の最後に実行する処理を定義
     * バッチが異常終了した場合にもfinishで定義した処理は実行される
     */
    global void finish(Database.BatchableContext BC) {
        // 
        System.debug('finish');
    }
}

注意ポイント

バッチ処理を実装するには、Database.Batchableを継承する必要がありますが、合わせてDatabase.Statefulを指定することを忘れないように。

Database.Statefulを指定しない場合、Execute内で更新されたメンバ変数が引き継がれなくなります。

開発コンソールでバッチを直接実行する

//バッチ処理を開発コンソールで実行する場合は、以下のコメントを利用してください。
BatchApexUpdateAccount xbatch = new BatchApexUpdateAccount();
Id batchId = Database.executeBatch(xbatch);

スケジュールクラス（ScheduledBatchUpdateAccount.cls）

/**
 * プログラム名：ScheduledBatchUpdateAccount
 * 概　　　要　：取引先部門一括更新バッチのスケジューラ
 * 作　成　日　：2022/07.01
 * 作　成　者　：cclt(David)
 * 変更履歴　　：
 */
global class ScheduledBatchUpdateAccount implements Schedulable {
    global void execute(SchedulableContext sc) {
        //取引先部門一括更新バッチクラスをインスタンス化
        BatchApexUpdateAccount b = new BatchApexUpdateAccount(); 
        //execcuteBatchでバッチ処理を実行
        Database.executeBatch(b);
    }
}

Schedulableとすることで、以下の画面からスケジュールジョブとして設定することができるようになります。

登録するとスケジュール済みジョブの画面にて、次回の実行予定を確認することができます。

注意ポイント

スケジュール登録の際に、作成したスケジューラのバッチが選択できない場合があります。その場合には、一度開発コンソールで直接スケジュール設定を行うと表示されるようになります。
スケジュール済み Apex ジョブは一度に 100 件しか設定できません。（分単位でバッチを登録すると1つのバッチだけで60個のジョブ枠が使われてしまうため注意が必要）※サポートに問い合わせしても変更できません。
スケジュール済み Apex の 24 時間あたりの最大実行数も制限されているため、ジョブの実行回数についても注意が必要です。

//開発コンソールで直接スケジュールを設定する

ScheduledBatchUpdateAccount m = new ScheduledBatchUpdateAccount();
String sch = ’20 30 8 10 2 ?’;
String jobID = system.schedule(‘取引先部門一括更新ジョブ’, sch, m);

sch（スケジュール）に設定する内容については、

‘Seconds（秒） Minutes（分） Hours（時間） Day_of_month（日） Month（月）Day_of_week（曜日）‘の順

設定方法に関する説明は以下の通り

Name	Values	Special Characters
`Seconds`	0–59	None
`Minutes`	0–59	None
`Hours`	0–23	`, – * /`
`Day_of_month`	1–31	`, – * ? / L W`
`Month`	1–12 or the following: `JAN` `FEB` `MAR` `APR` `MAY` `JUN` `JUL` `AUG` `SEP` `OCT` `NOV` `DEC`	`, – * /`
`Day_of_week`	1–7 or the following: `SUN` `MON` `TUE` `WED` `THU` `FRI` `SAT`	`, – * ? / L #`
`optional_year`	null or 1970–2099	`, – * /`

【特殊なスケジュール設定方法】

・Special Charactersの文字列を使うことで、複雑なスケジュールの指定が可能となります。

①カンマ’,’を使った場合、月のパラメータに”JAN,FEB,MAR”といったように複数の月を指定することができます。

②半角ハイフン’-‘を使うと、月のパラメータの場合、”JAN-MAR”といったように月のFROM-TO指定が可能となります。

※そのほかの例は、以下公式HELPサイトよりご確認ください。

「https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_scheduler.htm」

Batch Apexテストクラス（）

@isTest
private class ScheduledBatchUpdateAccountTest {

    public static String CRON_EXP = '0 0 * * * ? 2022';
    static testmethod void testScheduledJob() {
        // 処理対象の取引先データを作成
        List accRecs = new List();
        for (Integer i=0; i<10; i++) {
            Account acc = new Account(
                Name = 'テスト取引先 ' + i,
                Site =  null);
            accRecs.add(acc);
        }
        insert accRecs;
        
        // インサート後のレコードIDとレコードをマップに格納（検証用）
        Map accMap = new Map(accRecs);

        // テスト開始
        Test.startTest();
            // スケジュールジョブ実行
            String jobId = System.schedule('ScheduledBatchUpdateAccountTest',
                CRON_EXP, new ScheduledBatchUpdateAccount());
                
        //テスト終了
        Test.stopTest();

        //テスト結果の検証
        for(Account acc:[SELECT Id,Name,Site FROM Account
                        WHERE Id IN :accMap.keyset()]){
            System.assertEquals(acc.Site , null);
        }
    }
}

注意ポイント

System.schedule メソッドを使って、スケジュールした結果を確認する場合には、Test.startTest()→System.schedule メソッド→Test. stopTest()の順に実行する必要があります。

サンプルコード一覧へ戻る場合は、こちらへ

参考

Salesforceの開発を行うときにベースとなるサンプルコードを探すことが多い…

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））　合計（全体の平均）

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

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

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

参考

故障管理表（バグ管理表）（Excelテンプレート）サンプル

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

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

一般公開資料

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

Apexクラスカバレッジ管理表（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テンプレート）サンプル

故障管理表（バグ管理表）（Excelテンプレート）サンプル

2.品質管理方針

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

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

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

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

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

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

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

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

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

参考

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

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

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

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

参考

4.回帰テスト実施方針

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

参考

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

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

5.課題管理方針

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

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

まとめ

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

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

参考

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

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

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

参考

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

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

セールスフォース標準化推進ラボ — Sat, 27 Nov 2021 08:41:43 +0000

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

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

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

参考

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

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

テスト方針書の詳細な説明や利用方法については、以下の記事を参考にしてください。

参考

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

1.テーラリングガイド

１．テスト方針書の構成

サンプルでは、テスト方針書とその他添付資料を分けて定義していますが、方針書のPPTにすべて記述しても構いません。

２．基本事項

基本事項に関しては、テストの構成などを定義していますが、事前にお客様を含め関係者で認識合わせをしておくべき事項について、纏めるとよいでしょう。

３．テスト範囲

3章のテスト範囲については、テスト対象とするシステム・機能領域を明確にします。システム構成図を使ってわかりやすく説明するとよいでしょう。

また、複数ベンダーで開発を行う場合には、各社の責任範囲を明確にするためにも、どの領域をどのベンダーが対応するのかわかるように図示してください。

以下、詳細な機能や非機能に関しては、具体的な機能名や処理名を記載するようにしましょう。

4.テスト方針

4章のテスト方針は、テスト方針書のメインページとなります。方針として定義するべき内容に抜けもれがないようにしましょう。

サンプルの例では、テスト環境方針、担当者方針、設計方針、実行方針などについて記述をしています。

またテストで利用するツールがある場合には、ツールの概要や利用シーンなどを方針として纏めるとよいでしょう。

テスト実施方針のところでは、特に非機能について、どこまで実施するか方針の段階で明確にしておきましょう。

また実施方法や指標値についても合わせて検討してください。

テストの作業内容や成果物の作成などについては、お客様含め各社でどのような役割分担で進めるのかを明確にします。

5.管理方針

管理方針では、進捗や品質管理などに関しての方針を記述します。

テストの進捗管理方法もプロジェクトによって異なると思いますが、以下の例では、総テストケースに対しての消化ケース数で進捗率を算出しています。

進捗管理表を用いて、サマリーやグラフを使って可視化するとわかりやすいのでお勧めです。

進捗管理表は、こちらからダウンロードしてご利用いただけます。

参考

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

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

品質管理

品質管理については、品質要素と品質水準を明確に定義しておきましょう。

以下の例では、品質要素として、テスト密度とバグ密度を用いています。それぞれ過去のプロジェクトなどを参考にして、指標値を設定しましょう。

バグ（故障管理）についても、管理表を用いて管理をするのか、ツールやサービスを用いて管理するか、検出したバグに対して、改修状況を確認するだけではなく、バグの傾向分析を行って、関連する機能については横展開での対応など、次のアクションにつなげるためのプロセスも検討しましょう。

2.まとめ

テーラリングでは、一部のページに対しての簡単な説明のみとなりますが、より詳細な説明やテスト方針書の利用方法を知りたい方は、以下の記事を参考にしてください。

参考

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

サポーターさん

3.テスト方針書（ＰＰＴ版）テンプレートのダウンロード

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

一般公開資料

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

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

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

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

サポーターさん

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

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

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

セールスフォース標準化推進ラボ — 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について詳しく知りたい方はこちらの記事を参照ください。

参考

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

続きは、次の記事へ

参考

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

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

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

参考

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

サンプルコード（テンプレート）Apex/Lwc/Visualforce/Flow

Apex Trigger サンプルコード

セールスフォース標準化推進ラボ — Sun, 21 Nov 2021 09:27:29 +0000

取引先オブジェクトのApexTriggerサンプルコード

取引先（Account）のトリガクラス、ハンドラクラス、テストクラスの基本セット

取引先トリガ（AccountTrigger.cls）

Trigger AccountTrigger on Account (before insert, after insert, before update, after update,before delete, after delete, after undelete) {

    //Handlerクラス 
    AccountTriggerHandler handler = new AccountTriggerHandler();

    //レコードが新規登録された時
    if (Trigger.isInsert) {
        if (Trigger.isBefore) {
            // before insertの処理
            handler.onBeforeInsert(Trigger.New);
        } else if (Trigger.isAfter) {
            // after insertの処理
            handler.onAfterInsert(Trigger.New);
        }
    //レコードが更新された時
    } else if (Trigger.isUpdate) {
        if (Trigger.isBefore) {
            // before updateの処理
            handler.onBeforeUpdate(Trigger.Old, Trigger.New);
        } else if (Trigger.isAfter) {
            // after updateの処理
            handler.onAfterUpdate(Trigger.Old, Trigger.New);
        }
    //レコードが削除された時
    } else if (Trigger.isDelete) {
        if (Trigger.isBefore) {
            // before deleteの処理
            handler.onBeforeDelete(Trigger.OldMap, Trigger.NewMap);
        } else if (Trigger.isAfter) {
            // after deleteの処理
            handler.onAfterDelete(Trigger.OldMap, Trigger.NewMap);
        }
    //レコードがごみ箱から復元された時
    } else if (Trigger.isUndelete) {
        if (Trigger.isAfter) {
            // after undeleteの処理
            handler.onAfterUnDelete(Trigger.New);
        }
    }
}

トリガハンドラ（AccountTriggerHandler.cls）

/**--------------------------------------------------------------------------
* プログラム名 ：AccountTriggerHandler
* 概　要       ：Accountトリガーのハンドラークラス
* 作成日       ：yyyy.mm.dd
* 作成者       ：cclt
*--------------------------------------------------------------------------**/
public without sharing class AccountTriggerHandler { 

    /** * before insert */ 
    public void onBeforeInsert(List newAccList){ 
        for( Account acc : newAccList) {         
            //処理
        } 
    } 
    
    /** * after insert */ 
    public void onAfterInsert(List newAccList){ 
        for( Account acc : newAccList) {         
            //処理
        } 
    } 
    
    /** * before update */ 
    public void onBeforeUpdate(List oldAccList,List newAccList){  
        for( Account acc : newAccList) { 
            //処理
        } 
    } 
    
    /** * after update */ 
    public void onAfterUpdate(List oldAccList,List newAccList){  
        for( Account acc : newAccList) { 
            //処理
        } 
    } 
    
    /** * before delete */ 
    public void onBeforeDelete(Map oldAccMap,Map newAccMap){  
        for( Account acc : oldAccMap.values()) { 
            //処理
        } 
    } 
    
    /** * after delete */ 
    public void onAfterDelete(Map oldAccMap,Map newAccMap){  
        for( Account acc : oldAccMap.values()) { 
            //処理
        } 
    }     
    
    /** * after undelete */ 
    public void onAfterUnDelete(List newAccList){  
        for( Account acc : newAccList) { 
            //処理
        } 
    }    
}

取引先トリガテストクラス（TestAccountTrigger.cls）

/**--------------------------------------------------------------------------
* プログラム名 ：TestAccountTrigger
* 概　要       ：Accountトリガーのテストクラス
* 作成日       ：yyyy.mm.dd
* 作成者       ：cclt
*--------------------------------------------------------------------------**/
@isTest(SeeAllData=false)
private class TestAccountTrigger {
    
    //テスト設定メソッド
    @testSetup
    static void initTest(){
        // テストデータのセットアップ
        // 取引先の作成後、取引先に紐づく、責任者と商談を作成
        Account acc = new Account(Name='クリエイティブコンテンツラボトウキョウ');
        insert acc;
        
        // 取引先に紐づく取引先責任者を作成
        contact con = new Contact(FirstName='デイビッド',LastName='cclt');
        insert con;
        
        // 取引先に紐づく商談を作成
        List oppList = new List();
        oppList.add(new Opportunity(Name=acc.Name + '様との新規商談について',
                                    StageName='Prospecting',CloseDate=System.today().addMonths(1), AccountId=acc.Id));
        oppList.add(new Opportunity(Name=acc.Name + '様との別商談について',
                                    StageName='Prospecting',CloseDate=System.today().addMonths(3),AccountId=acc.Id));
        insert oppList; 
    }
    
    // テストケース：取引先名が更新されたときに商談の名前が更新されるか
    @isTest static void testUpdateAccountName() {      
        
        // 取引先の名前を更新するため最新のレコードを取得
         List updAccList = [select id, Name from Account];
        updAccList[0].Name = 'CreativeContentLabTokyo';        
        
        // テスト実行
        Test.startTest();

        //トリガー起動のための処理を記述
        Database.SaveResult result = Database.update(updAccList[0], false);

        Test.stopTest();

        // テスト結果の検証 
        System.assert(result.isSuccess());
        System.assert(result.getErrors().size() == 0);

    }
    
    // テストケース：取引先を削除
    @isTest static void testDeleteAccountRecord() {      
        
        // 取引先の名前を更新するため最新のレコードを取得
        List delAccList = [select id, Name from Account];
        
        // テスト実行
        Test.startTest();

        //トリガー起動のための処理を記述
        delete delAccList[0];

        Test.stopTest();
        
        List resultAcc = [select id, Name from Account];

        // テスト結果の検証 
        System.assert(resultAcc.isEmpty());

    }   
}

サンプルコード一覧へ戻る場合は、こちらへ

参考

Salesforceの開発を行うときにベースとなるサンプルコードを探すことが多い…

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

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

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

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

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

参考

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

故障管理表（バグ管理表）（Excelテンプレート）サンプル

1.テーラリングガイド

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参考

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

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

一般公開資料

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

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

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

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

サポーターさん

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