この内容は ソフトウェアテスト Advent Calendar 2020 の10日目の記事です
Salesforce界隈でのテスト
こんにちは。株式会社リゾルバでCTOをしている齋藤です。Salesforce業界に根を張って顧客支援・パートナー支援コンサルティングを行っています。
普段はセールスやプロジェクトの支援に入ったりプロダクト開発したり育成/研修サービスを展開したりと様々ですが、さまざまな支援先の会社さんの若者達を見ているとSalesforce開発の世界から自身のキャリアをスタートしたエンジニアの方もそこそこおいでで、私も実際テストをする段になって考え方とかノウハウを聞かれる機会も多いため、伝える時のメモとしてこの記事を書いておきたいと思います。
ここで伝えたい点は3点。
1.クラウドのパッケージ製品におけるテストの考え方を知るべし
2. テスト計画書を作れ
3. 詳しい人から吸収しよう
です。確かにクラウドならでは、パッケージ製品ならではの話もあるけど、本当はソフトウェアテストに関する考え方、ノウハウはSalesforceのエコシステムの中だけで学ぶというよりは、それを核として体系化している人たちから学ぶべきかな、と思います。僕もjasstのイベントに出たり本を読み漁ったりして土壌スキルが身についたので。
今回書かないこととして、Salesforceの良いところはドキュメントがとても充実しているのと、
Trailheadという自学自習の仕組みがあるので、ナレッジの網羅は公式を参照いただければと思います。
（海外の製品でここまでドキュメントが充実しているのは僕的にはSalesforceが初めてでけっこう衝撃的だったのを覚えてます）
1. クラウドのパッケージ製品におけるテストの考え方を知るべし
Salesforceはとても良くできたCRM/SFA製品で、契約すればすぐに利用できるのが良いところですね（個人的には世界で最も利用者数の多いJava EE アプリケーションの1つという理解）。
ちなみに、SaaSとして認知されていますが以下を見ると
Salesforce Platform は、100% クラウド化された PaaS（Platform as a Service, サービスとしてのプラットフォーム）です。
とのことです。標準で提供されている機能を利用したり設定したりするだけでなく、カスタムロジックを書けたりCI/CDと絡めながら組織戦略やリリース戦略を考えたり、システム連携の相手に合わせた豊富なAPIや連携方式の選択など、とても拡張性のあるカスタマイズもできるのでそのあたりはPaaSと言えるかもしれません。
基本的に、Salesforceが提供する標準機能に関してはすでに出来上がっている状態なので、導入エンジニア側でテストすべき箇所は手を加えた箇所で、
- 設定値そのもののカスタマイズ
- ユーザや連携アプリケーションの権限のカスタマイズ
- 画面レイアウト（UIのカスタマイズ）
- カスタムロジック
などです。カスタムロジックはApexというJava5に蓋をした独自言語で書くことが出来て、テストフレームワークとしてもApexTestなるJUnit風味の仕組みが用意されています（個人的にはParameterizedTestがほしいですが静的リソースからCSVをsourceとしてloadできるのが限界）
なお業界病かわかりませんがここの対象づけが結構まちまちでテストといっても属企業的・属人的だったりしてテスト計画やテスト分析・テスト設計という言葉を出しても目線が合わないことがあります。エクセル方眼紙にいきなり細かい粒度の観点表が出てくる、とかはよくあります。
一定のレベルより上に行くには、土壌・足腰スキルが必要です。
プロダクト開発主体でQAチームもいて、というケースならまだしも仮にみなさんがSIerでソロでアサインされるケースもありテストについてまとまって先人の知恵を学んだりする機会や時間が取れないエンジニアだったりしたらどう学べばよいのでしょうか？
2. テスト計画書を作れ
規模が大きくなったり難度の高いプロジェクトの場合にはテスト計画をしましょう。
良き記事が4日目に...!
要件定義/要求分析している時に僕も作るようにしてます。
全体観は記事下部のリンクをご覧いただくと良いかと思いますが、目次のイメージはこんな感じです
この資料（テスト計画）の位置づけについて
目次
テストの背景
第1章
1.1 テスト対象
1.2 テスト範囲
1.3 テストの前提と制約
1.4 ステークホルダー – 体制図/役割分担
テスト戦略
第2章
2.1 リスクベースドテスト
2.2 テストプロセス
2.3 テストの種類
2.3.1 テスト種類別のテスト範囲 (1/5) - 単体テスト
2.3.2 テスト種類別のテスト範囲 (2/5) – 結合・機能総合テスト
2.3.3 テスト種類別のテスト範囲 (3/5) – 負荷テスト
2.3.4 テスト種類別のテスト範囲 (4/5) – セキュリティテスト
2.3.5 テスト種類別のテスト範囲 (5/5) – ユーザ受入テスト（UAT）
2.3.5 テスト種類別のテスト範囲 (5/5) – ユーザ受入テスト（UAT）補足：進め方の例
2.4 テスト成果物
2.5. テストの実施方法と完了基準
2.6.1 必要となるテスト環境 – ブラウザバージョン
2.6.2 必要となるテスト環境 – その他テスト方針等
2.7 テストの中断及び再開基準
2.8 テストスケジュール
Salesforceという単語は出てこないですね...。各ページの詳細にはふんだんに出てきます。
この界隈だとテスト範囲が肝だと思っていて、Salesforceといっても Suite なので SFAもあればコールセンターもあり、コミュニティもECもあればMAやDMPやIoTもあればAIもあるしBI/MI、ネイティブアプリもなんやかんやと総花的にラインナップされているので、連携の矢印をまとめてからそれぞれにテスト範囲の定義をしたりするのがおすすめです。
プロジェクトスタートさせるときは全体のシステム・アーキテクチャ像を書いているのでそれを下敷きにすることもあるけど簡単なシステム相関図は初期調査で↓のようなちょっとしたメモ書きを書いてたりもするのでそれをインプットにしても良いです。
この例は検討段階のものなので生煮えですが、出てくるシステムが多いということはそれだけ連携方法を取捨選択しているわけで、選んだ選択肢に応じたテストのやり方がそれぞれ出てきます。ゆえにテストの計画や設計が必要になってきます。（システムランドスケープはいつももっとちゃんとしたのを作るよ！）
また、ここ数年はSalesforceファミリーの中でも複数製品を多用したプロジェクトが増えているので、横断的な連携バッチとか連携テストとかをやっていくときはテスト設計でCFD法を使うと良いと思います。僕は秋山浩一先生の本を教えてもらってそこで学びました。
3. 詳しい人から吸収しよう
テスト計画やテスト分析、テスト設計そのものは一度考え方がわかればナレッジをマルチユースに使いこなせるようになると思いますが、最初ゼロから作るのは非常に辛いので詳しい人と一緒に作っていくと良いでしょう。
先輩に詳しい人がいたり、ソフトウェアテストのパートナーさんと一緒にプロジェクトを過ごす機会があれば上級エンジニアさんから学んでみると良いと思います。大事なのは既存ドキュメントをそのままコピペするのではなく、目的意識や仮説を持って型を学ぶことなので。
個人的には型っぽいのが作れたら milanote とか quip に虎の巻をまとめておくのが良いかと。
それでは!