SMSルートテストの仕組み

テストが証明すること

ルートテストが答えるのは限定された問いです。このコンテンツを、この送信者から、このルートで、この市場のこれらの端末へ今日送信した場合、何が届き、どれだけ時間がかかるか。その答えは、その組み合わせについての根拠になります。カバレッジの主張でも、予測でもありません。端末が変わる、市場が変わる、ルートが変更されるといった違いがあれば、結果も変わる可能性があります。

この限定性こそが価値です。端末、コンテンツ、日付を明記したテストは、繰り返して比較できます。到達率のパーセンテージだけを報告するテストでは、それができません。生の記録を求めてください。端末に表示された送信者文字列、配信レシートの状態、送信から配信レシートまでの時間、そしてフローに必要な場合は返信経路です。

テストの前に問いを書き出してください。「このルートは、この送信者からのOTPを、この市場の一般的な端末へ10秒以内に届けられるか」といった問いからは、使える結果が得られます。「このルートは良いか」という問いからは、意見しか得られません。

テストの実施方法

まず問いについて合意します。新しいルート、新しい送信者、新しい市場、既存ルートの変更のうち、どれを確認するのか。その問いによって、端末、コンテンツ、送信回数が決まります。次に、その市場を代表する端末を選びます。複数の機種を選び、ルートが複数のネットワークにまたがる場合は複数のネットワークを含め、トラフィックの大半を運ぶと想定されるネットワークの端末を少なくとも1台含めます。

コンテンツを固定します。実際に送信するテンプレートを使い、リンク、変数、GSM-7とUCS-2のどちらになるかを決める文字も含めます。すべての端末に同じコンテンツを送信し、送信時刻、配信レシートの時刻、状態を記録し、生データを保管します。フローに返信が必要な場合は、各端末から返信を送り、届くまでの時間を記録します。テストは閑散時間帯だけでなく、トラフィックが想定される時間帯にも実施してください。

失敗の読み解き方

配信レシートがないことと、配信レシートが失敗を示すことは同じではありません。配信レシートがない場合、記録が届かなかったことを意味し、メッセージ自体は端末に届いている可能性があります。失敗を示す配信レシートには状態が含まれ、多くの場合、理由を示すネットワークコードも含まれます。たとえば、加入者不明、加入者不在、メモリ不足、サービス規制（バーリング）です。ルートを変更する前にコードを読んでください。

配信済みを示す配信レシートがあるのに表示されない場合は、別の確認が必要です。端末、メッセージアプリ、迷惑メッセージフォルダー、送信者文字列を確認します。返信が届かない場合は、送信側の経路ではなく、受信ルートまたは送信者の種類が原因であることを示しています。結果が遅い場合は、ルート、キュー、またはスロットリングされたバインドが原因であることを示しています。根拠が示す段階を修正してください。

失敗も、合格と同じ項目で記録します。端末、市場、送信者、コンテンツ、ルート、時刻、状態です。これらの項目がない失敗記録は次回の実施結果と比較できません。そして修正が証明されるのは、その次回の実施です。

レポートを信頼する前に確認すること

日付、端末、ネットワーク、正確なコンテンツを確認してください。どのルートがトラフィックを運んだか、それが直接接続かアグリゲーター経由かを確認してください。パーセンテージだけでなく、配信レシートの状態とエラーコードを求めてください。テストが対象としなかったこと、いつ再テストすべきかを確認してください。

そのうえで、レポートを自社のトラフィックと比較します。1台の端末でのテストに合格しても、別の機種、別のネットワーク、より長いテンプレートでは本番で失敗することがあります。ルートテストのサンプルレポートで記録の形式を確認できます。プロバイダー選定ガイドは、結果を次のサプライヤーへの質問に落とし込みます。