モダンなSalesforce開発において、Lightning Web Component（LWC）は欠かせない技術要素となっています。しかし、多くの開発チームが「どのようなコーディング規約を設ければよいのか」「チーム全体で一貫したコードスタイルを維持するにはどうすればよいのか」といった課題を抱えています。

本記事では、SalesforceのApexコーディング規約の考え方を参考にしながら、LWC開発における実践的なコーディング規約の策定と活用方法について詳しく解説します。品質の高いLWCアプリケーションを開発するために、ぜひ本ガイドを参考にして、あなたのプロジェクトに最適なコーディング規約を構築してください。

本記事では、このテンプレートの特徴と効果的な活用方法について詳しく解説します。

なぜコーディング規約が重要なのか

1. フロントエンド開発の複雑性への対応

LWC開発では、JavaScript、HTML、CSS、そしてSalesforceのメタデータが複雑に絡み合います。統一されたコーディング規約がないと、以下のような問題が発生します：

• コンポーネント間でのスタイリングの不整合
• JavaScript のパフォーマンスの劣化
• コンポーネントの再利用性の低下
• デバッグの困難さ

2. Salesforceプラットフォーム特有の制約

LWC開発では、一般的なWebフロントエンド開発とは異なる独特の制約があります：

• Locker Service によるセキュリティ制約
• Lightning Data Service の効率的な活用
• イベント伝播とコンポーネント間通信
• レスポンシブデザインとLightning Design System（SLDS）の準拠

3. 長期保守性の確保

LWCコンポーネントは、Salesforceの組織内で長期間にわたって使用されます。初期開発から数年後の機能拡張や修正を考慮した、保守しやすいコード構造を保つことが重要です。

1.テーラリングガイド

１．目次サンプル

目次
1 はじめに 
　1.1 本書の目的 7
　1.1.1 利用者 7
1.2 記号 7
　1.2.1 本書で使用する記号についての説明 7
1.3 用語の定義 7
　1.3.1 本書で使用する記号についての説明 7
2 基本方針 8
　2.1 可読性の優先 8
　2.2 保守性の確保 8
　2.3 Lightning固有の考慮事項 8
3 命名規則 8
　3.1 コンポーネント名 8
　3.2 メソッド名 9
　3.3 定数名 10
4 ファイル構造とフォーマット 11
　4.1 ファイル構成 11
　4.2 インデント 11
　4.3 行の長さ 12
5 Javascript設計 13
　5.1 クラス構造の順序 13
　5.2 プロパティ設計 15
6 HTMLテンプレート設計 17
　6.1 テンプレート構造 17
　6.2 イベントハンドリング 18
7 CSSスタイル設計 21
　7.1 SLDS準拠 21
　7.2 CSSカスタムプロパティ 22
8 データアクセスとAPIコール 22
　8.1 Lightning Data Service (LDS) 22
　8.2 Apexメソッド呼び出し 24
9 イベント設計 25
　9.1 カスタムイベント 25
　9.2 プラットフォームイベント 27
10 テスト設計 28
　10.1 Jestテスト 28
　10.2 テストデータファクトリ 31
11 セキュリティとベストプラクティス 33
　11.1 セキュリティ考慮事項 33
　11.2 パフォーマンス最適化 34
12 国際化対応 36
　12.1 カスタムラベル使用 36
　12.2 日付・通貨・数値フォーマット 38
13 エラーハンドリング 40
　13.1 統一的なエラーハンドリング 40
　13.2 バリデーションエラー 43
14 デバッグとトラブルシューティング 45
　14.1 ログ出力 45
　14.2 パフォーマンス監視 46
15 コンポーネント設計パターン 48
　15.1 コンポーネント間通信 48
　15.2 コンポーネント間通信 50
16 メタデータ設計 53
　16.1 コンポーネントメタデータ 53
17 運用保守 55
　17.1 コードレビューチェックリスト 55

２.基本方針（可読性・保守性の重視）

テンプレートでは、「可読性の優先」「保守性の確保」「Salesforce固有の考慮事項」の3つを基本方針として掲げています。これらの方針は、長期的な開発・運用を見据えた重要な指針となります。

可読性の優先

• コードは書く時間よりも読む時間の方が長いことを念頭に置く
• 自己説明的なコードを心がける
• 適切なコメントで意図を明確にする

保守性の確保

• 単一責任原則に従ったコンポーネント設計
• 疎結合と高凝集を実現する構造
• 将来の変更に対応しやすい設計

パフォーマンスの重視

• 不要な再レンダリングを避ける
• 効率的なデータフェッチ
• 適切なライフサイクルフックの活用

３.命名規則の統一

3.1 コンポーネント名
規則:
• kebab-case（小文字、単語間はハイフン）
• 意味のある名前を使用
• 業務領域を表現する接頭辞を付ける

3.2 メソッド名
規則:
• camelCase（最初は小文字、以降の単語は大文字開始）
• 意味のある名前を使用
• Boolean型はis、has、canで開始

3.3 定数名
規則:
• UPPER_SNAKE_CASE（全て大文字、単語間はアンダースコア）
• 意味を明確に表現

4.ファイル構造とフォーマット

4.1 ファイル構成

my-component/

├── my-component.js         // Javascript ロジック

├── my-component.html       // HTML テンプレート

├── my-component.css        // CSS スタイル

├── my-component.js-meta.xml // メタデータ

└── __tests__/

    └── my-component.test.js // テストファイル

4.2 インデント

規則:

• 2スペースインデント（タブ文字は使用しない）
• 一貫したインデントレベルを維持

4.3 行の長さ

規則:

• 1行120文字以内を推奨
• 長い行は適切な位置で改行

5.Javascript設計

クラス構造体の順序、ﾌﾟﾛﾊﾟﾃｨ設計の規則と例を記述しています。

6.HTMLテンプレート設計

テンプレート構造、イベントハンドリングについての規約と例文について解説しています。

7.CSSスタイル設計

CSSスタイル設計のSLDS準拠について、CSSカスタムプロパティの利用方法について解説しています。

8 データアクセスとAPIコール

Lightning Data ServiceやApexメソッドの呼び出しに関する規則について解説しています。

8.1 Lightning Data Service (LDS)
規則:
• 単一レコード操作にはLDSを優先的に使用
• @wireでリアクティブなデータバインディング
• エラーハンドリングを適切に実装

8.2 Apexメソッド呼び出し
規則:
• @wireで自動データバインディング
• imperative callで手動データ取得
• 適切なエラーハンドリング

9.イベント設計

カスタムイベント、プラットフォームイベントについて解説

10.テスト設計

Jestテスト、テストデータファクトリについて解説

11.セキュリティとベストプラクティス

11.1 セキュリティ考慮事項
規則:
• ユーザー入力は常にサニタイズ
• lightning-formatted-textでXSS対策
• CRUD/FLS権限を考慮

その他

テンプレートを参照ください。

テンプレートの効果的な活用方法

1. プロジェクト開始時の規約策定

新しいSalesforceプロジェクトを開始する際、このテンプレートをベースとして、プロジェクト固有の要件に合わせてカスタマイズすることで、短時間で実用的なコーディング規約を策定できます。

活用手順：

1. テンプレートをダウンロードし、開発チーム全体で内容を確認
2. プロジェクトの特性に応じて、必要な項目を追加・修正
3. チーム内での合意形成とドキュメント化

2. 既存プロジェクトの品質改善

既に進行中のプロジェクトでも、段階的にコーディング規約を導入することで品質向上を図ることができます。

段階的導入のアプローチ：

• 第1段階: 新規開発コードから規約適用開始
• 第2段階: 既存コードの修正時に規約に合わせてリファクタリング
• 第3段階: 重要なモジュールから順次全面的な規約適用

3. コードレビューの効率化

テンプレートに含まれるチェックリストを活用することで、コードレビューの観点が明確になり、見落としを防ぐことができます。

4. 新人教育・オンボーディング

新しくチームに参加する開発者に対して、このテンプレートを教育資料として使用することで、Salesforce開発のベストプラクティスを効率的に伝えることができます。

実装時の注意点とコツ

段階的な導入を心がける

すべての規約を一度に導入しようとすると、開発チームに大きな負担をかけてしまいます。重要度の高い項目から順次導入し、チーム全体が慣れてから次の項目に進むことが重要です。

ツールを活用した自動化

可能な限り、IDE（Salesforce CLI、VS Code）の設定やCI/CDパイプラインを活用して、規約チェックを自動化しましょう。手動でのチェックに頼りすぎると、継続が困難になります。

定期的な見直しと改善

プロジェクトの進行に伴い、新たな課題や改善点が見つかることがあります。定期的に規約を見直し、チームの成長とプロジェクトの変化に応じてアップデートしていくことが大切です。

テンプレートに含まれる実践的なコード例

このテンプレートの大きな特徴の一つは、豊富な実装例が含まれていることです。抽象的な説明だけでなく、具体的なコード例を通じて「良い例」と「悪い例」を明示しているため、開発者が実際のコーディング時に迷うことなく適用できます。

SLDSの活用例

(css)
/*  良い例 - SLDS準拠 */
.account-container {
  padding: var(--lwc-spacing-medium);
}

.header {
  margin-bottom: var(--lwc-spacing-large);
}

.content {
  display: flex;
  flex-direction: column;
  gap: var(--lwc-spacing-medium);
}

.empty-state {
  text-align: center;
  padding: var(--lwc-spacing-x-large);
  color: var(--lwc-color-text-weak);
}

.error-message {
  color: var(--lwc-color-text-error);
  padding: var(--lwc-spacing-small);
  border: 1px solid var(--lwc-color-border-error);
  border-radius: var(--lwc-border-radius-medium);
  background-color: var(--lwc-color-background-error);
}

/* レスポンシブ対応 */
@media (max-width: 768px) {
  .content {
    padding: var(--lwc-spacing-small);
  }
}

継続的な品質向上のために

コーディング規約の導入は、ゴールではなくスタートラインです。継続的に品質を向上させるために、以下の取り組みを推奨します：

定期的なコードレビュー会の実施

チーム全体でコードレビューを行う時間を定期的に設け、規約の適用状況や新たな課題について議論します。

メトリクス測定と改善

テストカバレッジ、複雑度、規約違反数などのメトリクスを測定し、定量的な改善を図ります。

知識共有とベストプラクティスの蓄積

チーム内で発見されたベストプラクティスを規約に反映し、組織の知見として蓄積していきます。

まとめ

今回公開したSalesforce Apexコーディング規約テンプレートは、実際の開発現場での経験を基に作成された実践的なドキュメントです。このテンプレートを活用することで、開発チームは以下のメリットを得ることができます：

• 開発効率の向上: 統一されたコーディングスタイルにより、コードレビューや保守作業が効率化
• 品質の向上: Salesforce特有の制約を考慮したベストプラクティスにより、バグの削減と性能向上を実現
• チーム力の強化: 共通の規約により、チーム内でのコミュニケーションと協力が促進
• スケーラビリティの確保: 将来の機能拡張や保守作業に対応しやすいコード構造の実現

Salesforce開発の品質向上を目指すすべてのチームに、このテンプレートを積極的に活用していただき、より良いシステム開発を実現していただければと思います。

資料のダウンロード

テンプレートのダウンロードは、Creative Content Lab Tokyoの公式サイトから無料で行えます。ぜひ、あなたのプロジェクトでもご活用ください。

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

一般公開資料

開発コーディング規約のダウンロード

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

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

最後に

サポーターさん

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

サポーターさん

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

にほんブログ村

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

お客様から提示された要求仕様に関して、変更が発生した際に本テンプレートを利用して変更内容を管理してください。

変更管理を行う場合の管理プロセスについてもBacklogと本管理台帳を使ったプロセスを定義しておりますので、合わせてご利用ください。

要求仕様管理台帳が必要な方はこちらの記事を参照してください。

参考

要求仕様管理一覧（テンプレート）

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

資料サンプル

表紙

管理プロセス

変更要求管理台帳

1.テーラリングガイド

1.変更要求管理プロセス

変更要求の管理プロセスについては、お客様社内の変更管理プロセス（起票から承認まで）と、開発ベンダー側での変更管理プロセスの2種類があります。

プロジェクトに合わせて、管理プロセスを定義してください。お客様内部のプロセスを定義する必要がない場合は、開発ベンダー側だけの管理プロセスを記述してください。（ただし、実施可否の最終判断はお客様となるためその部分はプロセスに定義しておきましょう）

管理プロセス（サンプル①）

以下のサンプルでは、お客様側の変更要求起票はバックログを使って運用する想定で記載したものとなります。

管理プロセス（サンプル②）

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

変更要求管理台帳

主に以下のような内容を記述します。※プロジェクトによって管理項目は適宜変更してご利用ください。

・変更要求管理番号：変更要求を一意に識別するための管理番号を定義します。※命名ルールに準拠すること。

・件名：変更に関するタイトルを定義します。

・変更内容：変更内容（概要レベル）で記載します

・変更対象機能：変更を行う対象の機能を具体的に記述します。

・変更種別：追加・変更・削除などの種別を定義します。

・要求元：変更要求の要求元を定義します。

・業務影響度：変更が業務に与えるインパクトを記述します。

・期待効果：変更による期待効果（改善効果）を記述します。

・納期：対応の納期が決まっている場合には記述します。

・起票日：起票した日付を記述します。

・起票者：起票者を記述します。

・発生日：変更要求が発生した日付を記述します。

・ステータス：変更要求の管理ステータスを記述します。※ステータスは別途定義する必要あり

・開発者項目として、影響する機能の洗出し結果や、技術的に変更が対応可能かなどの項目を定義します。

・対応想定工数が必要な場合には工数の情報も合わせて定義しておきます。

2.変更要求管理台帳のダウンロード

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

一般公開資料

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

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

まとめ

サポーターさん

テンプレートのご利用に関して不明な点があればお問い合わせください。

また、テンプレートに対しての要望がありましたらご意見ください。 皆様の役に立つように改善していきたいと思います。

サポーターさん

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

にほんブログ村

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

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

参考

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

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

続きを読む

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

４．テスト方針

２．テスト担当者方針

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

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

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

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

３．テストツールの利用

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

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

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

４．テスト設計方針

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

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

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

５．テスト実施

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

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

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

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

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

負荷性能テストに関しては、実施する場合には、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テンプレート）サンプル

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

2.品質管理方針

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

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

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

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

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

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

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

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

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

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

参考

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

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

4.回帰テスト実施方針

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

5.課題管理方針

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

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

まとめ

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

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

参考

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

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

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

参考

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

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

続きを読む

関連記事

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

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

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

テスト方針書の作成手順

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

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

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

1.はじめに

１．本書の目的

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

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

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

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

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

２．本書の構成

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

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

２．基本事項

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

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

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

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

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

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

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

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

１．前提条件と制約事項

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

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

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

２．テスト範囲

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

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

３．テスト対象（機能）

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

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

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

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

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

４．テスト方針

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

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

補足）テスト環境構築

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

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

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

変更セットで対応できない資材については、直接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版テンプレート）サンプル

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

関連記事

まず言葉の定義ですが、本記事では、プロジェクトで作成する各種ドキュメントやソースコードなどのプログラムを「成果物」とし、お客様に納品する対象の成果物を「納品物」と定義しています。

特に新入社員の方は、成果物の全てが納品対象ではないということを覚えておきましょう。

納品物については、RFPの中で作成し納品するべきものが定義されている場合もありますが、最終的には提案書の中で、どの工程でどういった成果物を作成し納品しますということを記載します。

もちろん、作成する成果物の量や質（内容や粒度）によって、作成の工数が増減し、また品質管理（内部や外部のレビューの実施方法や回数など）によっても必要な工数が変わってきます。

見積の段階で成果物の精緻な工数を算出するのは難しく、ある程度の経験が必要になってきます。

均一な見積工数を算出するためにも、社内で成果物の作業工数一覧表や工数計算のツールなどを利用するようにしましょう。

また、成果物のサンプルはできる限り、見積の段階で提示しておくことをお勧めします。

プロジェクト開始後により高品質のものを求められることがあり、お客様の要望に対応することで予定外の工数が発生してしまうため、初期にリスクを潰しておくことが重要となります。

成果物一覧サンプル

Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）では、以下のようなExcelの成果物一覧を用意しています。

このような成果物/納品物一覧を作成しておき、プロジェクトごとに、作成するもの、納品するものを定義しておきましょう。

成果物/納品物一覧の利用方法

社内のテンプレートを利用する場合にも必要な軸（列）が定義されているか確認しておきましょう。

ただし、無駄な軸が多いと可読性が低下してしまうため、必要なものだけ追加するようにしましょう。

例えば、提案時に必要な項目は以下のようなものとなります。

1. 納品工程
2. 納品物名
3. 納品予定日
4. 引き渡し方法（電子ファイル/紙媒体）
5. 引き渡し場所

また、契約後、プロジェクト管理の一環として成果物/納品物を管理する場合には以下のような軸で管理するとよいでしょう。

1. 作業工程
2. 成果物/納品物名
3. ファイル名（命名規約）
4. ファイル様式（Excel/ppt/word)
5. 作成/納品（成果物を作成するかどうか、納品物として提出するかどうか）
6. 用途
7. 主要項目

記載内容の解説

①作業工程

まず、作業工程を定義しますが、どの工程でどの成果物を作成するのかを意識する必要があります。

特にSalesforceのプロジェクトでは、アジャイル開発を行ったり、オブジェクト定義や標準のインプリを要件定義で実施したりすることも多いため、要件定義工程、基本設計工程でそれぞれなにを作成し、納品するのかを決めたうえで定義する必要があります。

作業工程については、提案書やプロジェクト計画時に定義している内容に合わせて定義しましょう。

②成果物/納品物名

成果物名については、例えば業務フロー図やER図など具体的にイメージしやすいものを書くようにしましょう。

要件定義書のようなものを記載する場合、どのような内容が含まれるのかお客様から質問されることが多いため、記載する章立てやサンプルを合わせて提示するとよいでしょう。

③ファイル名（命名規約）

成果物に対して、ファイル名の命名ルールを定義します。命名規約については、別の資料で管理する場合は除外してもよいでしょう。

④ファイル様式（Excel/ppt/word)

作成する成果物のファイル様式が指定されている場合もあるので注意しましょう。特に指定がなければ自社で用意しているフォーマットを利用するということで定義しておきましょう。

⑤作成/納品（成果物を作成するかどうか、納品物として提出するかどうか）

成果物一覧にすべての工程の成果物が定義されている場合、今回のプロジェクトで作成するものとしないものを明確にするため、作成する成果物には〇、作成しないものは×などマークを使って識別可能な状態としておきましょう。

また、作成した成果物のうち、どれが納品対象かを示すために納品の列を設け、納品対象の場合には〇、それ以外は×を付けて識別しておきましょう。

お客様は、作成したものすべて納品してもらえると思っている場合もあるので、プロジェクト開始後の早い段階で認識合わせをしておくことをお勧めします。

⑥用途

成果物の用途を記述しておきます。

⑦主要項目

成果物の章立てや主要な事項を記述しておきます。文章での記述が難しい場合は成果物のサンプルを提示するとよいでしょう。

（以下、提案書に記載する内容）

⑧納品予定日

提案書には工程のフェーズ分けや契約/検収時期が定義されていると思います。それに合わせて、各工程で納品する成果物の納品予定日を記述しましょう。

具体的な日付ではなく、要件定義工程終了後30日以内などのような記載をする場合もあります。

⑨引き渡し方法（電子ファイル/紙媒体）

納品物については、引き渡し場所と方法を記載しますが、システム導入によりペーパーレス化を目指すようなプロジェクトであっても、成果物の納品は紙媒体でお願いしますと言われることもあります。

電子ファイルでの納品でよいのか、紙媒体に印刷しての納品が必要なのか事前に確認しておきましょう。

⑩引き渡し場所

引き渡し場所については、紙媒体であればお客様に直接お渡しすることが多いと思いますが、電子媒体の場合、ファイルサーバに配置するなどの方法もありますので、お客様と調整した結果を記述しておきましょう。

その他

上記以外の項目としては、例えばレビュー対象について記述するのもよいでしょう。

お客様から見ると、どの成果物についてレビューを実施しないといけないのかあらかじめ知っておくことで、レビューのタイミングに合わせて予定やメンバーの調整をしやすくなります。

またレビューをどのような形式で実施するのか（対面なのか、回覧形式で実施するのか）などレビュー方式についても検討しましょう

プロジェクトで発生するレビューについては、別途レビュー管理表を用いて管理することをお勧めします。

レビュー管理表とレビュー指摘表は以下の記事からダウンロードしてご利用いただけます。

参考

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

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

参考

レビュー指摘表（Excelテンプレート）サンプル

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

まとめ

成果物や納品物については、プロジェクトマネージャやPMO、営業担当は意識することが多いとおもいますが、開発担当のメンバーであっても、どの工程でどのようなフォーマットを使って成果物を作るか意識しておきましょう。

特に納品物については、お客様が目にしたときにベンダーの品質や評価につながることが多いため、しっかりとしたフォーマットを使って、必要な情報が漏れなく整理され記述されているかチェックしておきましょう。

サポーターさん

本サイトでは豊富なテンプレートを用意しているのでぜひご利用ください

本サイトで用意している成果物のテンプレートやサンプルは以下の記事でご確認いただけます。

参考

ダウンロード可能なコンテンツ（サンプル・フォーマット）一覧

[st-kaiwa2]お問合せ・ご要望いただいているコンテンツも頑張って作成して…

続きを読む

成果物/納品物一覧のダウンロード

資料をダウンロードしたい方は、こちらの記事からどうぞ

参考

成果物/納品物一覧（Excelテンプレート）サンプル

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

Salesforce（セールスフォース）プロジェクトのリリース判定会議の際は、ぜひ本テンプレートをご活用ください。

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

参考

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

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

1.サンプル

2.テーラリングガイド

1.稼働判定基準（カットオーバー・クライテリア）

本報告書で一番重要な事項となる、稼働判定の基準については、各プロジェクトで定めた基準に合わせて修正してください。

2.稼働判定基準の達成状況ご報告

１．テスト実施結果の報告

3.添付資料

稼働判定報告書と合わせて報告（提出）資料があれば、添付資料として定義するか、PPT内に添付してください。

2.リリース判定会議報告資料テンプレートのダウンロード

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

一般公開資料

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

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

まとめ

サポーターさん

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

サポーターさん

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

にほんブログ村

本記事では、Salesforceプロジェクトですぐに使えるSalesforce基礎用語の用語集のテンプレートをご提供しております。

1.Salesforceの用語集サンプル

プロジェクト開始後、お客様へSalesforceに関する説明をしている際に、Salesforce特有の用語についての説明を求められることも多いと思います。

あらかじめ用語集を作成しておくとすぐに説明できるので、この機会に作成しておきましょう。

Salesforce基礎用語の用語集（テンプレート）ダウンロード

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

※実際のプロジェクトでは、複数メンバーで共同作業することが多いため、上記のようにGoogleのスプレッドシートを利用して同時編集できるようにすると作業効率がアップしますのでお勧めです。

ただしセキュリティ設定だけはしっかりとしておいてください！！

（共有は必要なメンバーを指定する形とし、リンクを知っている人が誰でも参照・編集できるような設定はしないように注意してください）

Salesforceに関する用語の基本的な説明は、実際のSalesforce組織にログインして、画面を操作しながら説明したほうが理解しやすいと思います。

また画面や口頭説明だけでは理解するのが難しい内容（ロールやプロファイルなど）については、それぞれ説明用のPPTを用意しておくとよいです。

※本サイトではこれらの用語の説明のPPTもご用意しておりますので、ぜひご活用ください。

2.用語集のダウンロード

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

一般公開資料

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

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

まとめ

サポーターさん

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

テンプレート関連の記事

サポーターさん

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

にほんブログ村

本記事では、Salesforceプロジェクトですぐに使えるSalesforce基礎用語の用語集のテンプレートをご提供しております。

1.Salesforceの用語集サンプル

プロジェクト開始後、お客様へSalesforceに関する説明をしている際に、Salesforce特有の用語についての説明を求められることも多いと思います。

あらかじめ用語集を作成しておくとすぐに説明できるので、この機会に作成しておきましょう。

Salesforce基礎用語の用語集（テンプレート）ダウンロード

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

※実際のプロジェクトでは、複数メンバーで共同作業することが多いため、上記のようにGoogleのスプレッドシートを利用して同時編集できるようにすると作業効率がアップしますのでお勧めです。

ただしセキュリティ設定だけはしっかりとしておいてください！！

（共有は必要なメンバーを指定する形とし、リンクを知っている人が誰でも参照・編集できるような設定はしないように注意してください）

Salesforceに関する用語の基本的な説明は、実際のSalesforce組織にログインして、画面を操作しながら説明したほうが理解しやすいと思います。

また画面や口頭説明だけでは理解するのが難しい内容（ロールやプロファイルなど）については、それぞれ説明用のPPTを用意しておくとよいです。

※本サイトではこれらの用語の説明のPPTもご用意しておりますので、ぜひご活用ください。

2.用語集のダウンロード

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

一般公開資料

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

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

まとめ

サポーターさん

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

テンプレート関連の記事

サポーターさん

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

にほんブログ村

本記事では、Salesforceプロジェクトですぐに使えるSalesforce基礎用語の用語集のテンプレートをご提供しております。

1.Salesforceの用語集サンプル

プロジェクト開始後、お客様へSalesforceに関する説明をしている際に、Salesforce特有の用語についての説明を求められることも多いと思います。

あらかじめ用語集を作成しておくとすぐに説明できるので、この機会に作成しておきましょう。

Salesforce基礎用語の用語集（テンプレート）ダウンロード

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

※実際のプロジェクトでは、複数メンバーで共同作業することが多いため、上記のようにGoogleのスプレッドシートを利用して同時編集できるようにすると作業効率がアップしますのでお勧めです。

ただしセキュリティ設定だけはしっかりとしておいてください！！

（共有は必要なメンバーを指定する形とし、リンクを知っている人が誰でも参照・編集できるような設定はしないように注意してください）

Salesforceに関する用語の基本的な説明は、実際のSalesforce組織にログインして、画面を操作しながら説明したほうが理解しやすいと思います。

また画面や口頭説明だけでは理解するのが難しい内容（ロールやプロファイルなど）については、それぞれ説明用のPPTを用意しておくとよいです。

※本サイトではこれらの用語の説明のPPTもご用意しておりますので、ぜひご活用ください。

2.用語集のダウンロード

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

一般公開資料

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

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

まとめ

サポーターさん

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

テンプレート関連の記事

サポーターさん

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

にほんブログ村

本記事では、Salesforceプロジェクトですぐに使えるSalesforce基礎用語の用語集のテンプレートをご提供しております。

1.Salesforceの用語集サンプル

プロジェクト開始後、お客様へSalesforceに関する説明をしている際に、Salesforce特有の用語についての説明を求められることも多いと思います。

あらかじめ用語集を作成しておくとすぐに説明できるので、この機会に作成しておきましょう。

Salesforce基礎用語の用語集（テンプレート）ダウンロード

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

※実際のプロジェクトでは、複数メンバーで共同作業することが多いため、上記のようにGoogleのスプレッドシートを利用して同時編集できるようにすると作業効率がアップしますのでお勧めです。

ただしセキュリティ設定だけはしっかりとしておいてください！！

（共有は必要なメンバーを指定する形とし、リンクを知っている人が誰でも参照・編集できるような設定はしないように注意してください）

Salesforceに関する用語の基本的な説明は、実際のSalesforce組織にログインして、画面を操作しながら説明したほうが理解しやすいと思います。

また画面や口頭説明だけでは理解するのが難しい内容（ロールやプロファイルなど）については、それぞれ説明用のPPTを用意しておくとよいです。

※本サイトではこれらの用語の説明のPPTもご用意しておりますので、ぜひご活用ください。

2.用語集のダウンロード

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

一般公開資料

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

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

まとめ

サポーターさん

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

テンプレート関連の記事

サポーターさん

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

にほんブログ村

本記事では、Salesforceプロジェクトですぐに使えるSalesforce基礎用語の用語集のテンプレートをご提供しております。

1.Salesforceの用語集サンプル

プロジェクト開始後、お客様へSalesforceに関する説明をしている際に、Salesforce特有の用語についての説明を求められることも多いと思います。

あらかじめ用語集を作成しておくとすぐに説明できるので、この機会に作成しておきましょう。

Salesforce基礎用語の用語集（テンプレート）ダウンロード

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

※実際のプロジェクトでは、複数メンバーで共同作業することが多いため、上記のようにGoogleのスプレッドシートを利用して同時編集できるようにすると作業効率がアップしますのでお勧めです。

ただしセキュリティ設定だけはしっかりとしておいてください！！

（共有は必要なメンバーを指定する形とし、リンクを知っている人が誰でも参照・編集できるような設定はしないように注意してください）

Salesforceに関する用語の基本的な説明は、実際のSalesforce組織にログインして、画面を操作しながら説明したほうが理解しやすいと思います。

また画面や口頭説明だけでは理解するのが難しい内容（ロールやプロファイルなど）については、それぞれ説明用のPPTを用意しておくとよいです。

※本サイトではこれらの用語の説明のPPTもご用意しておりますので、ぜひご活用ください。

2.用語集のダウンロード

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

一般公開資料

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

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

まとめ

サポーターさん

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

テンプレート関連の記事

サポーターさん

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

にほんブログ村

各章のサンプルと解説例

１．本書の目的

２．基本事項

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

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

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

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

5.体制と役割

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

8.テスト実施手順

10.管理方針

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

参考

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

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

続きを読む

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

一般公開資料

まとめ

サポーターさん

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

サポーターさん

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

今回は、結合テストの計画書作成に関する最後の記事となります。

テスト計画のスケジュールや体制・役割からの説明となります。

テスト計画書の作成手順

５．テストスケジュール

テスト実施のスケジュールを記述します。まずは、テスト全体スケジュールを定義します。

テストスケジュールについては、マスタスケジュールのマイルストーンを意識したうえで、関係各社と調整しておく必要があります。

特に外部結合テストについては、関係各社の進捗に影響されるため、早い段階で大枠の調整をしておき、詳細なスケジュールはテスト工程が近づいてきたら調整をするとよいでしょう。

テスト開始後も、バグの発生や他社の状況により変更になることは多々ありますので、必要に応じて早めに調整するようにしましょう。

１）体制と役割

スケジュールの次は、体制と役割について記述します。

まずは、お客様や関係各社を含めた全体の体制図を提示しましょう。

体制については、プロジェクト規模や契約、自社の立ち位置などにより異なりますが、全体統括（テスト全体の取り纏めを実施する人）は明確にしておきましょう。

全体責任者以下は、システム単位や機能（モジュール）単位など、プロジェクトに応じて設定してください。

体制図では、上下の関係（報告ルート）を定義することも重要となります。だれがその領域（チーム）を取り纏めて、誰に報告するのか明確にしておきましょう。

体制図と合わせて、各社の詳細な役割についての説明ページを追加しておくことをお勧めします。

テスト実施における各社の役割（テスト計画の作成や実施の進行は誰が実施するのか、またテストデータは誰が作成するのか）を定義。

また、不具合が発生した際の責任分界点など明確に定義しておき、各社と認識合わせをしておきましょう。

２）自社の体制について

つづいて、自社内の体制と役割について詳細に記載します。担当者レベルで、誰が何をするのか記述します。

自社内のテスト責任者（全体の取り纏め）は、テスト計画の立案や各種レビュー、報告などを担当します。

その他の役割としては、テスト設計者、実施者、不具合発生時の故障対応者、テスト品質の分析を行う品質管理者など、プロジェクトに合わせて役割と担当者を定義してください。

６．成果物

テスト工程の成果物を定義します。

成果物については、基本的に契約時点で工程ごとに作成予定の成果物を提示していると思いますので、同じものを定義すればよいでしょう。

ただし契約時点で具体的に提示していない場合は、具体的な成果物名に落とし込んで記述するようにしてください。

成果物の説明やできればテンプレートについてもお客様と合意しておいたほうがよいでしょう。

７．テストの開始と終了条件（クライテリア）

つづいて、テストの開始・終了基準について記述します。

こちらの基準については、一般的に決まった内容を記述することが多いです。プロジェクト特有の事項があれば追記する形が良いと思います。

例えば結合テストの開始条件は、以下のようなものがあります。

• 単体テストのすべてのテストケースの実施が終了し、検出されたバグについてはすべて対応済みであること
• テスト設計及び関係者のレビューが完了していること
• 結合テスト開始時点でリリースできない機能がある場合（追加開発、仕様変更、残バグ）については、別途追加実施するためのテスト計画（スケジュール）が検討済みであること

つづいて、終了基準の例

• 全てのテストケースの実行（再テストを含む）が完了していること
• 検出したバグの分析が完了し、同様のバグが潜在していないか（横並びチェック）を実施済みであること
• バグの改修が完了し、回帰テストが実施済みであること

８．テスト実施手順

テスト実施手順については、テスト計画書では、関係各社との間でテスト全体の大きな流れについて認識合わせをするための概要レベルで記載すればよいでしょう。

※実際の手順書は、エクセルベースの詳細な手順書を作成してください。

記載内容としては、各テスト工程ごとに、実施内容と作業手順（概要）、担当者、成果物を以下のようにマトリクスにして時系列でまとめるとよいでしょう。

流れとしては、一般的にテスト計画→要員計画（トレーニング）→テスト設計→テスト環境準備→テスト実施→品質分析→（再テスト）→完了報告といった感じになります。

特にトレーニングについて、ある程度経験があるメンバーが集まっている小規模プロジェクトではあまり実施することはないと思いますが、テスト品質を高めるためには、お客様の業務内容やプロセスの理解、作成したシステムに関する理解、テスト仕様書の作成方法、テスト技法、テストの実施手順などを理解したうえで実施することが望ましいです。

ただし、QCDに係る制約等により、実施が難しい場合もありますので、その場合はテスト管理者が最低限の教育と品質チェックをしっかり行う体制をとるようにしましょう。

１０．管理方針

１）進捗管理

管理方針には、テスト工程で管理すべき内容（進捗管理、インシデント管理、コミュニケーション管理、品質管理など）についての方針を記述します。

以下は、進捗管理方針についての説明資料（サンプル）ですが、テスト実施の際には、具体的な実施予定に対する消化率を計測するために以下のような表を用いて管理するなどの方針を記述するとよいでしょう。

※テスト実施の予実については、少なくとも日時単位で把握するようにしましょう。

全てのテストケースを算出して、テスト期間（実際のテスト可能な営業日数）で割ると、1日あたりに消化すべきケース数が算出できると思います。

ただし、テスト期間全体で割ると、終了がぎりぎりになってしまい、想定外の不具合が発生した場合などにリカバリーできなくなるため、予めバッファを考慮して前倒しで終了する予定を組むようにしたほうがよいでしょう。

お客様への定例会で進捗を報告する場合には、進捗率と合わせて、バグの発生件数や対応状況も報告するようにしましょう。

２）インシデント管理

つづいては、インシデント（バグ・故障・欠陥）管理についての方針を記述します。

方針としては、以下のような管理表（Excel）を用いて、件数や発生内容、バグの傾向分析を実施するなど記述すればよいでしょう。

もしくは、インシデント管理専用のツールやサービスを利用する場合には、それらを用いてどのような内容を管理するか記述してください。

クリエイティブコンテンツラボトウキョウが用意した、故障管理表のテンプレートを利用する場合は、以下よりダウンロードしてください。

テストの品質管理について

参考

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

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

３）品質管理

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

テストの品質管理方針については、最低限プロジェクト計画書に記載の内容は定義するようにしてください。

バグの検出率などの指標に関しては、各社の過去プロジェクトやプロジェクト独自の指標を検討して記載します。

※一般的な開発指標を用いても構いませんが、お客様に説明して納得していただける根拠は必要となります。

その他の管理方針

上記以外にも、コミュニケーション管理、回帰テスト管理などページを追加して必要な事項はもれなく定義するようにしましょう。

まとめ

今回は、結合テストに関するテスト計画書のサンプルと合わせて、記述内容や考え方を説明してきましたが、いかがでしたでしょうか。

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

参考

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

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

関連記事

結合テスト計画書の作成（第二回）では、テスト計画の詳細について説明していきたいと思います。

テスト計画書の作成手順

３．テスト計画（テスト範囲）

まずは、テスト範囲の定義について記述していきます。

このページの目的としては、システム全体の中で、どの部分について結合テストで実施するのかを明確することです。

また、結合テストで検証しない部分はどこなのかを明確にして、関係者の間で共通認識を持つことが重要です。

システム構成図ベースで範囲を囲ったり、どの部分は内部結合テストで検証するのか、外部結合テストで検証するのか、全体像がわかるように記載するとよいでしょう。あまり詳細な内容を記載する必要はありません。

テスト範囲の詳細は、別のところで説明すればよいので、ここでは全体像を把握できるレベルにしておきましょう。

1.テスト範囲（スコープ）

つづいてのページでは、同じくテスト対象について記述しますが、工程ごとにどのようなテストをするのか詳細していきます。

２．テスト対象

１）内部結合テスト

内部結合テストでは、前の記事で説明した通り、処理結合テスト、機能結合テスト、業務結合テストの3種類があります。

それぞれについて、どのシステム（領域）のどの業務/機能/処理（コンポーネント）の結合を検証するのかを明確に記述します。

処理結合テストでは、コンポーネントの単位に気を付けてください。（粒度を合わせるように）

また、業務結合テストについては、基本的に要件定義で検討した業務フローに沿ってシナリオを作成することになりますが、イレギュラーケースや想定している業務オペレーションや端末、アクター（権限）など考慮してシナリオを検討してください。

さらに計画書のレビューと合わせて、テストシナリオ、テストケースについては、お客様側の担当部門の方にも参加していただき、対面レビューを実施することをお勧めします。

システムを作成する側やお客様のシステム部門だけでシナリオを検討、レビューすると特にイレギュラーなオペレーションなどの考慮が不十分となることが多く、品質低下につながります。

２）外部結合テスト

外部結合テストについては、外部システムとのインタフェーステストが中心となります。

まずは、インタフェース一覧で、システム間、機能間のインタフェース（どこから（送信元）どこ（送信先）に対して、どのような処理方式で連携するのか）を洗い出して、それぞれの連携対象に対して、どのようなテストを実施するのか検討しましょう。

外部結合テストでは、他社（他システムのベンダー様）との連携テストとなることが多いため、しっかりとコミュニケーションをとって、テストシナリオ、テストケースについては、関係各社で協議・レビューして決めていくようにしましょう。

その際、テストデータはだれが作成するのかを明確にし、テストケースで必要となるテストデータが網羅できるように作成依頼をしておきましょう。

テスト実施にあたっては、不具合が発生した際のエスカレーション方法や責任分界点など明確にしておく必要があります。

最後に、テスト実施手順についても各社と認識合わせをしておきましょう。

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

続いて、パフォーマンステストの実施に範囲や方法について記述していきます。

以下の例では、オンラインとバッチに分けて記述しています。

性能テストに関しても要件定義で検討したテスト方針に基づいて、処理毎の指標値を決めて、どのように測定するのか記述していきましょう。

特にWEBアプリケーションのテストで、端末（PC/タブレット/スマートフォンなど）から処理のリスクエストをしてレスポンスが返ってくるまでのターンアラウンドタイムで計測するのか、ネットワーク通信などは除外したサーバ内部処理のみの性能にするのかによって、指標値が大きく異なるため、この部分の認識合わせは重要となります。

以図のように、具体的にどの部分をテストするのか図示するとよいでしょう。

②バッチ処理

バッチ処理の性能テストについて記述します。

以下の例では、バッチのスループット検証として、1時間あたり9,000件の処理が可能かどうかの検証を記載しています。

また制約事項や前提条件がある場合には、それらを忘れずに記述しましょう。

特にSalesforce特有のガバナ制限を意識しないといけない処理に関しては、具体的なガバナ制限について記述しておきましょう。

バッチ系処理では、大量データで5000万件を超過するデータを扱う場合のテストや1外部APIを大量にコールアウト（Callout）するような処理がある場合には必ずテストを実施してガバナ制限に抵触しないかどうか検証するようにしましょう。

また、ヒープサイズを大量に消費するようなサイズの大きいファイルの読み込みなどについても必ずテストを実施するようにしましょう。

Salesforce環境で負荷テストを実施する場合には、上記に記載の通り、事前にサポートへ連絡して、承認を得る必要があります。

テスト計画の際に、申請タスクの落とし込みと、申請のリードタイムも考慮したスケジュールを作成する必要があります。

添付で、具体的に意識するべきガバナ制限について記載しておくのもよいでしょう。

４）テスト対象外機能

つづいては、結合テストで検証しない対象について明記しておきます。

対象外のシステムや機能・処理と合わせて、実施しない理由も記述します。例えば、環境による制約のため、テストが実施できないという場合など。

ただし、制約によりテストできない場合でも、まったくテストを実施しないということではなく、Mockをつかってテストを実施するなど代替案がある場合には必ず実施するようにしましょう。どうしてもできない場合の最終手段として有識者による机上での検証を行ってください。

５）責任範囲（責任分界点）

最後に、テストの責任範囲について記述します。

特に複数社による開発を行う場合にはこの記述が重要となります。（他社と同じモジュールやオブジェクトに対して設定・開発を行っているなど）

不具合が発生した場合に、誰の責任になるのか責任の所在を明確にします。

関係各社で協議したうえで、内容を記述するようにしましょう。

３．テスト実行環境

次にテスト実行環境について、記述していきます。

１）サーバ環境

まずはサーバ環境について記述します。結合テストの工程では、どのサーバを用意して利用するのか説明します。

Salesforceの場合、結合テスト専用のSandboxを用意してテストを実施することが多いと思います。

Sandboxの種類によって、ストレージの制限や更新間隔が異なったり、コピーされるデータが異なるため、これらの違いを把握したうえで環境の定義をするように心がけましょう。

２）クライアント環境

サーバの次は、クライアント環境について記述します。

テストを実施する端末の種類（PC/スマートフォン/タブレット）やOS、利用するBrowserなどについて記述します。

例では、Salesforceがサポートしているブラウザの種類を捕捉として添付しています。

特にIEなどサポートが終了しているブラウザもあるため、常に最新のサポートブラウザを確認するようにしましょう。

また、ブラウザの種類だけではなく、バージョンの確認も忘れないようにしましょう。

※OSのバージョンやアプリケーションのバージョンは過去分のバージョンまで組み合わせると莫大な工数が必要となってくるため、契約工数の範囲内で対応できる範囲で実施するように計画してください。

４）テストツール

最後にテストツールについて記述します。テストの種類と利用するツールについての説明を行います。

ツールを使って負荷テストをする場合は、サーバ側へかなり負荷がかかるため、実施する場合には必ずSalesforceのサポートと調整するようにしてください。

まとめ

今回はここまでとなります。次回は、スケジュールや体制・役割についての説明を行います。

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

続きは、次の記事へ

参考

テスト計画書の作成（結合テスト）（３）スケジュール~管理方針

みなさん、こんにちは。 今回は、結合テストの計画書作成に関する最後の記事となりま…

続きを読む

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

参考

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

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

関連記事