テストのススメ

はじめに

みなさんこんにちは。
走れるエンジニアに触発され、最近皇居ランを始めた佐々木です。
みなさんテストやってますか?
Salesforceのテストというと、ApexのTestClassが真っ先に思い浮かぶと思いますが、
「標準カスタマイズでもテストの観点は必要なのでは」という思いから、今日はソフトウェアテストと
Salesforceのテストについて、考えてみます。

みなさんこんにちは。 走れるエンジニアに触発され、最近皇居ランを始めた佐々木です。 みなさんテストやってますか? Salesforceのテストというと、ApexTestClassが真っ先に思い浮かぶと思いますが、 「標準カスタマイズでもテストの観点は必要なのでは」 という思いから、今日はソフトウェアテストの観点でSalesforceの標準テストについて、 少し考えてみました。

テストの種類

まずは、テストの種類についておさらいです。

開発工程に合わせたテスト
おなじみV字モデル


V字モデルV字モデル

  • 単体テスト(JSTQB*1では、ユニットテストやコンポーネントテストといいます) ソフトウェアを構成する最小単位の機能(モジュール)のテストを指します。
  • 結合テスト 関連する機能(モジュール)を組み合わせたテストを指します。
  • システムテスト すべての機能(モジュール)を統合し、外部システムを含めたシステム全体の テストを指します。
  • 受け入れテスト 主に顧客(発注側)にて実施するテストで、要求仕様通りのシステムができているか 検証するテストを指します。

品質の観点でのテスト

  • セキュリティテスト 対象のシステムに関して、不正アクセスにつながるような脆弱性がないかを検証するテストを指します。 (SQLインジェクションやクロスサイトスクリプティングなどがあたります)
  • 性能テスト 一定時間あたりの、処理能力やレスポンスを検証するテスト指します。
  • 負荷テスト 処理が集中したことを想定し、システムリソースの限界を検証するテスト指します。
  • 機能テスト そのシステムが持つべき、機能について入力などの操作により正しい実行結果が得られるかどうかを検証するテストを指します。
  • ユーザビリティテスト システム使いやすさをユーザ目線で検証するテストを指します。

実行方法

  • 動的テスト 実際にテスト対象を動かして検証するテストを指します。
  • 静的テスト ソースコードレビューや設計書のレビューなど、机上での検証を指します。

テスト手法

  • ブラックボックステスト 内部構造や動作を意識せず、システム要件に基づいたの入力と出力だけに着目したテスト
  • ホワイトボックステスト システムやプログラムの構造や動作に着目したテスト

Salesforceでとソフトウェアテスト関係

導入・追加開発時

テストを考える前に、Salesforce標準開発での主な作業を開発工程に当てはめると以下のようになるかと思います。

Salesforce標準開発での主な作業

次にV字モデルに当てはめるとそれぞれのテストが見えてくると思います。 要求定義に対応するテストは、受け入れテストが相当しますが、顧客側のテストになりますので、 今日は割愛します。

開発および詳細設計に対応するテストは、単体テストです。 標準カスタマイズでの単体テストでは、要件に元づく入力規則、項目自動更新、承認プロセス など、各設定を動的テストとして検証を行います。

次に、基本設計に対応するテストは、結合テストです。 結合テストでは、プロファイルごとのページレイアウトの割り当てが正しく設定されているか レビューを行います。(静的テスト) また、特定のプロファイルでログインし、承認申請等を画面上から行う動的テストで、 単体テストで確認した、承認プロセスと項目自動更新、メールアラートなどの連携処理の 検証を行います。

最後に要件定義に該当するものは、システムテストです。 システムテストでは、期待されているシステム要件が網羅されているかどうかを実際に画面 から入力して検証します。 Salesforceの場合は、プロファイルごとにテストユーザを作成し、そのユーザでログインする ことで、適切な設定となっているか、データの共有範囲、項目レベルセキュリティの設定は 正しいかをを確認します。

実行方法は、「動的テスト」、テスト手法は、「ブラックボックステスト」が該当します。

また、Salesforce標準開発におけるシステムテストは、受け入れテストの観点も踏まえ 業務フローにそって実施すると、それぞれの設定の関連性も確認でき業務がスムーズに 流れるシステムであることを確認することができます。

バージョンアップ時

バージョンアップによるセキュリティ強化で仕様 が変更される場合があります。 標準機能のみの設定でも影響を受ける場合がありますので、その影響分析と リグレッションテスト(回帰テスト)が 必要になります。

最後に

ビジネススピードに合わせ、より使いやすいシステムに柔軟に変更できるのがSalesforce標準の すばらしいところだと思います。テストが不要という意見もあるかもしれませんが、 標準で提供される機能自体のテストは不要であっ ても、それを使った設定事項のテストは やはり必要であると考えます。

各工程ごとにテストを分けて実行することも可能ですが、Salesforce標準のみの開発の場合、 テストの費用対効果を考え、システムテストのみで実施することも可能だと思います。

また、テストについては、顧客毎に考え方や呼び方が異なることが多いです。 例えば、単体テストをユニットテストといったり、結合テストを統合テストや、IT (インテグレーションテスト)といったり、より細かいテスト工程を設けていたりします。

Salesforce標準開発か否かによらず、テスト工程の考え方テストの範囲については、 できるだけ早い時期に合意をすることが望まれます。