デバッグとは フローのデバッグやテストを分かりやすく解説
#テスト #Salesforce #フロー #自動化 #デバッグ
目次
Salesforceを使用する上で業務を効率化するならフローは欠かせない機能です。
作成したは良いものの、問題なく機能するのか、本番でも動くのかという心配はデバッグ、テストなしでは拭えません。
そこで今回は、フローにおけるデバッグとテストの役割から運用まで整理し、品質を落とさずに変更を迅速に行っていくための手順を紹介します。
まずはデバッグとテストとは何か、またその違いや関係性について見ていきましょう。
デバッグとテストの違い
デバッグとテストの両者は連続していますが、目的・タイミング・成果物が明確に異なります。
実務では、まずデバッグで最小の再現条件を固め、その手順をテストケースへ昇華するのが大半です。
デバッグとテストの使い分け
基本の流れはデバッグ → テスト → 本番運用となりますが、いきなりイメージするのは簡単ではありません。
ここで、デバッグとテストの違いをより具体的に掘り下げて、両者の使い分けができるように整理しましょう。
| 項目 | デバッグ | テスト |
| 目的 | フローの動作確認と不具合の発見。 実際の処理の流れや変数の値を追跡し、意図した結果が得られているかを検証する。 |
フローの信頼性と再現性の担保。 想定されたさまざまな条件下で正しく動作するかを確認し、運用環境で問題が起きないようにする。 |
| 実施タイミング | フロー作成・修正の初期段階や開発中。特定の機能や分岐を確認したいときに都度実行する。 | デバッグ完了後、本番リリース前やリリース直後。安定稼働を確認するために、複数ケースをまとめて検証する。 |
| 検証対象 | 個々の処理手順、変数、条件分岐の結果などフロー内部の動作。 | 入力条件・例外パターンを含めた全体的なビジネスロジックの整合性。Apexとの干渉も確認。 |
| 成果物 | 実行ログ、変数の値、エラー発生箇所などのデバッグログ。 | テストケース一覧、テスト結果レポート、修正方針など検証記録。場合によってはテストクラスのコード。 |
それでは実際にフローのデバッグ、テストを実施していきましょう。
今回は、商談のフェーズが成約になった際に、ToDoを新規作成するフローを使用していきます。
デバッグ フローデバッガの活用
Salesforceにはフローデバッガというデバッグ機能があります。
フローデバッガは、画面フロー／自動起動フロー／レコードトリガフローを対話的に実行し、要素ごとの通過状況や変数値を確認できます。
フローデバッガの使用方法について解説していきますが、その前にデバッグで使用する入力データについて押さえておきましょう。
入力データの作り方
デバッグを行うにはデバッグで使用するデバッグデータを準備します。
最初は処理を動かすのに必要な最小の再現データから始めます。次に少しずつ入力する項目や範囲を広げていきます。
最後に権限やユーザが変わっても問題なく処理が動くかもデバッグで確認できると完璧です。
- 最小再現：必須項目だけを満たす最小レコードで再現可否を確認します。
- 範囲を拡大：金額・日付・件数など、いろいろなデータで実施する。
- デバッグを実行するユーザを変える：管理者が別のユーザとしてフローのデバッグを実行することができます。ユーザによって参照できるものや更新可否の違いを観察します。
フローデバッガの実践
それでは、実際にフローデバッガを使用していきます。
フロービルダーで対象のフローを開いたら、右上にある「デバッグ」ボタンを選択します。
左側にフローデバッガの設定が表示されます。ここでデバッグで使用するデータの選択や値を入力することができます。
フローデバッガのデバッグは、ロールバックモードで実行することにより、データの変更は保存されません。
具体的なフローデバッグの手順については下記の記事に記載しています。
https://frogwell.co.jp/blogs/salesforce-debug/
今回は、商談のフェーズが成約の場合に、設計した通り、ToDoが新規作成されるのか。商談のフェーズが成約以外の場合にToDoが新規作成されないかを見ていきましょう。
フェーズが成約の商談「テスト2」を入力してデバッグを実施します。また「別のユーザとして自動化を実行」にチェックし、別のユーザとしてフローをデバッグすることもできます。
こうして得た最小再現→範囲拡大→権限やユーザ差分のデータは、そのままテストケースの材料になります。
実行をすると左側にデバッグの詳細としてデバッグログが表示されます。
また、詳細からデータの動きまで参照することができます。
フェーズが成約以外の商談「テスト3」を入力してデバッグを実施して、エラーが出ることも確認しましょう。
使用したレコードがフローの開始条件を満たしておらず、右上には「トリガーされていません」と表示されています。このように、作成したフローが期待通りに稼働するのかを部分的な条件を設定して、デバッグを実施していきます。
デバッグのよくあるミス
最後にデバッグで起こりがちなミスについて紹介していきます。
- 入力変数の値の入力ミス / 項目条件の未考慮：入力変数の値を誤って指定していたり、Null の可能性を考慮していない条件式を書いていると、フローデバッグ時にエラーになったり、期待どおりの分岐に進まないことがあります。
デバッグでエラーが出たり、想定と違う結果になった場合は、まずこのミスをしていないか確認しましょう。 - 並列更新 / ロック：同じデータを複数の処理が同時に更新してしまい、処理が止まることがあります。
処理の順番やスケジュールを理解して、必要なら一時的に処理を止めることも考慮しましょう。 - 権限不足によるエラー：自分は更新できるが、別のユーザは更新できないなどユーザによってデバッグの結果が異なる場合があります。
別ユーザとしてデバッグを実施して、自分以外のユーザでのデバッグ結果を確認することができます。
これらのポイントを押さえておくことでミスなくスムーズにデバッグを実行することができるでしょう。
ここだけ注意：実データ更新の抑止／外部連携の副作用
デバッグ実行は通常ロールバックされますが、メール送信や外部システムとの連携（API通信など）は止まらず動くことがあります。
そのため、テスト中は以下のように注意しましょう。
- 通知や外部連携を一時的に止める
サンドボックス環境では、メール送信を無効にしたり、外部APIの送り先をテスト用に切り替えておきます。 - 別ユーザでのデバッグも試す
別ユーザとしてデバッグを使うことで、権限や共有設定の違いによる動作の差を早めに確認できます。
以上、フローデバッガ機能について解説しました。
デバッグ機能によって、簡単にログを確認し、フローの動きをすぐに見ることができます。
テスト フローテストケースで再現性を担保
フローにはテストケースという機能があり、どんなデータを入力したときに、どうなるのが正しいかを登録しておけます。
デバッグでうまく動いた手順をそのままテストとして保存しておけば、設定を変えたあとも自動で同じテストを繰り返せるようになり、動作確認がずっと楽になります。
「テストを表示」またはデバッグ実行後の「変換してテスト」から、新規テストを作成し、先ほど実行したデバッグで分かった正しい手順をテストケースに保存します。そうすることで、ボタン一つで毎回同じチェックを回せるようにします。
テストケース設計時の押さえておくべきポイント
最初からたくさんのテストを作る必要はありません。 まずは最小限のテストを作っておき、トラブルや修正が発生したときに1件ずつ追加していく形で増やしていくのがおすすめです。
下記の４パターンを基本セットとして覚えておくとテストもスムーズに実施することができるでしょう。
- 正常パターン：想定どおり動くケース
- 異常パターン：エラーが起こるケース
- 境界パターン：ぎりぎりの値などを試すケース
- 権限パターン：ユーザの権限による違いを確認するケース
不具合がまた起きたら、その原因を再現できるテストを必ず追加しておきましょう。一度直した不具合を二度と通さないための仕組みになります。
先ほど実行したデバッグと同じテスト２を使用したテストを作成します。
テストで使用するレコードを選択し、テストデータを作成します。
何を“正”とみなすかの明確化
テストにおいてどんな変化が起きれば正しい動きといえるかを決めておくことは、とても重要です。
これを明確にしておくと、テストが失敗したときに原因をすぐに見つけやすくなります。
正とみなす条件の例）
- 更新件数： レコードの作成・更新・削除の数が想定どおりか
- フィールド値： 指定した項目の値が期待した内容と一致しているか
- 存在・非存在： レコードや関連データが正しく存在／削除されているか
- エラーの想定： 入力漏れや権限不足のときに、想定どおりエラーになるか
フローのテストでは、”正”をアサーションとして設定します。
すべてのアサーションの条件を満たしたときに初めて、テストが”正”と判定されます。
テストを表示から作成したテストを実行し、結果を見てみましょう。
実際に設定したアサーションを通過すると「合格」と表記され、デバッグ同様、処理の詳細も確認することができます。
Apexテストとの役割分担
フローの中でApexのInvocableメソッドを呼び出す場合は、Apexテストとフローテストで役割を分けるのが基本です。
層を分けておくと、問題が起きたときに原因がフロー側か、Apex側かをすぐに判断できるようになります。
Apex側（単体テスト）
- ロジック単体の動きを細かく確認します。
- 境界値（ギリギリの値）や例外処理、外部APIのモック（テスト用の代替）などをしっかりテストします。
フロー側（結合テスト）
- 業務の流れ全体が正しく動くかを確認します。
- 条件分岐の結果や複数レコードの更新、ユーザ権限による動作の違いなどをチェックします。
このように、フローでのテストではあくまで流れがうまく動くかということに焦点を当てます。Apexクラスの中身でちゃんと処理が行われているかはApex側のテストで検証しましょう。
以上、フローのテスト機能について解説しました。デバッグ同様、こちらも便利な反面、デメリットもあります。
テスト機能では、フローが起動した場合に正しく処理が動いているのかを確認することができますが、フローが起動しないかという場合のテストは、実行することはできません。
※今回の場合では、フェーズが成約以外の商談でフローが起動しないテストケース
この場合、実際にフローが動かないかは、テスト機能ではなく、データを手動で動かし、フローが起動しないことを確認する必要があります。
本番反映と運用監視のチェックリスト
リリース後も品質を保持・改善するために、同じ手順で軽くでも繰り返し確認しましょう。
- 切り替えの時間帯： 業務影響の少ない時間に新バージョンを有効化。万一に備えて旧版に戻す手順を文書化しておく。
- 権限の配布： 必要な権限セットを漏れなく割り当てる。
- 継続テスト： リリース直後にテストスイートを即実行、以降はスケジュールで定期実行。
運用監視のポイント
定期的にフローの運用をするために以下のポイントをあらかじめ押さえておくと、より品質の高いフローを運用することができます。
- 毎週月曜の午前など監視するタイミングをあらかじめ決めておく。
- 改善の履歴をチーム共有ノートやChatterに残しておく
まとめ
デバッグは修正すべき点に早く気づく、テストは確実に問題に気づくために実施します。この役割分担を徹底し、デバッグで得た再現手順をテストケース化して回帰を封じましょう。
デバッグでは値の変わる直前・値の変わる直後・ループ内の観察を徹底し、テストでは最小セット→拡張の運用に切り替えれば、フローは速くて壊れない状態に近づきます。
＜Salesforce＞
弊社ではSalesforceをはじめとするさまざまな無料オンラインセミナーを実施しています！
＞＞セミナー一覧はこちら
また、弊社ではSalesforceの導入支援のサポートも行っています。ぜひお気軽にお問い合わせください。
＞＞Salesforceについての詳細はこちら
＞＞Salesforceの導入支援実績はこちらからご覧いただけます！
医療業界に特化した営業支援、顧客管理(SFA/CRM)のコンサルティングも提供しております。こちらもぜひお気軽にお問い合わせください。
＞＞顧客管理(SFA/CRM)のコンサルティングの詳細はこちら
