品質保証（B2C）

品質保証は、重大な影響を受ける前に問題を特定するために重要です。プロジェクトの性質に応じて、異なる種類の品質保証テストから適したものを選び、Auth0統合の一環として実施することをご検討ください。

• アプリケーションは、障がいのある人にとっても理解しやすく、使いやすいですか。

• アプリケーションは、多種のブラウザーやデバイスで動作する必要がありますか。

• アプリケーションは、複数の国で、あるいは国際的な環境で動作する必要がありますか。

• 予期しない生産負荷が発生した場合、アプリケーションのパフォーマンスはどうなりますか。

• セキュリティー関連の脆弱性からアプリケーションをどのように保護しますか。

Auth0のユニバーサルログインおよび関連するUIウィジェット（Lockなど）は、使いやすさとアクセシビリティのベスト プラクティスに従ってすでに設計および構築されており、多くのブラウザーやデバイスに対してそのまますぐに使えるテスト済みのサポートを提供しています。国際化（I18N）のサポートも初めから組み込まれており、カスタムの多言語・ローカリゼーション（L10N）シナリオに対応できる拡張性を備えています。

機能的な要件が満たされ、予期しないイベントが正しく処理されるように、アプリケーションとAuth0の間の統合をテストするためのガイダンスと、個々の拡張モジュール（Rules、Hooks、カスタム データベースのスクリプトなど）のユニットテストに関するガイダンスが提供されます。また、セキュリティの脆弱性をテストする際に役立つAuth0のペネトレーションテストポリシーに関するガイダンスも提供されます。さらに、負荷テストポリシーと組み合わせてモックテストを活用して、予期しない負荷の下でもアプリケーションが確実に動作するための情報も提供されます。

ユニットテストの目的は、コードの個々のユニットをテストすることです。Auth0内でRules、Hooks、カスタムDBスクリプトの形式でカスタムコードを作成する場合は、テストフレームワーク（Mochaなど）を使用してコードをテストすることを検討してください。Auth0を上手に活用している企業は、Auth0テナントの構成その他を自動的にデプロイする前にユニットテストを行うと効果的だと言います。

ベストプラクティスとして、開発・テスト・運用用に個別のテナントをセットアップすることをお勧めします（「SDLCサポートのアーキテクチャガイダンス」を参照）。Auth0を使用すると、カスタム拡張性内から使用できる変数を構成できます。これらは、Auth0テナントの環境変数とみなすことができます。ハードコード化された参照は、開発・テスト・運用環境間で移動すると変わってしまうため、代わりに、テナントで構成され、カスタムの拡張コードによって参照される変数名を使用することができます。コードが変数を参照すれば、実行時にテナント固有の値が書き込まれるため、同じカスタムコードを異なるテナントで変更せずに使用できます。

• Rulesでの変数の使用については、値の構成方法

• Hooksでの変数の使用については、エディターでシークレットの構成方法を参照してください

• Actionsでの変数の使用については、「フローとトリガーを見る」

• カスタムDBスクリプトでの変数の使用については、構成パラメーター

デプロイメントの自動化とテストの自動化を組み込めば、ビルドプロセス全体を自動化できます。これを利用して、新しいバージョンの構成やカスタムコードをAuth0に導入し、自動テストを実行することができます。テストでエラーが見つかった場合は、デプロイメントの自動化機能を使用して、動作していた最後のバージョンに戻すことができます。詳細については、提供されている「デプロイメントの自動化に関するガイダンス」を参照してください。

Auth0の負荷テストポリシーと負荷テストを行いたいという要望とのバランスを取るため、Auth0のエンドポイントをモックすることが慣行となっています。これは、テストを制約することなく、想定したインターフェイスでのアプリケーションの動作を確認できる有効な方法であり、補助としてMockServer、JSON Server、Postmanといったツールを使用できます。

当社では、PDF形式の計画ガイダンスを提供しています。ダウンロードして、推奨される戦略の詳細を参照してください。