> ## Documentation Index > Fetch the complete documentation index at: https://docs-staging-update-anonymous-sessons-ea.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Business-to-Consumer の品質保証 > テスト環境と、各リリースが通過すべきリグレッションのカバレッジおよび承認ゲートを定義して、B2C IAM の Auth0 実装における品質保証を計画します。 品質保証は、お客様に影響が及ぶ前に問題を特定するうえで重要です。また、プロジェクトの性質によっては、Auth0 との統合の一環として検討すべき品質保証テストがいくつかあります。 * 障害のある方を含め、誰にとってもアプリケーションは理解しやすく、使いやすいものになっていますか？ * アプリケーションは、さまざまなブラウザーやデバイスで動作する必要がありますか？ * アプリケーションは、多国籍および/または国際的な環境で動作する必要がありますか？ * 想定外の本番環境の負荷がかかったとき、アプリケーションのパフォーマンスはどうなりますか？ * アプリケーションをセキュリティ上の脆弱性から保護するには、どのようにすればよいでしょうか？ Auth0 の [Universal Login](/docs/ja-jp/authenticate/login/auth0-universal-login) と関連する UI ウィジェット ([Lock](/docs/ja-jp/libraries/lock) など) は、すでにユーザビリティとアクセシビリティのベストプラクティスに従って設計・構築されており、多数の [ブラウザーやデバイス](/docs/ja-jp/troubleshoot/customer-support/product-support-matrix) に対するテスト済みの標準サポートを提供しています。[国際化](/docs/ja-jp/customize/internationalization-and-localization) (I18N) のサポートも標準で提供されており、カスタムの多言語対応やローカリゼーション (L10N) に対応できるよう、組み込みの拡張も備えています。 機能要件が満たされ、想定外の事象にも正しく対応できることを確実にするために、アプリケーションと Auth0 の間の[連携](#integration-testing)テスト、および個々の拡張モジュール ([Rules](/docs/ja-jp/customize/rules/debug-rules)、[Hooks](/docs/ja-jp/customize/hooks/update-hooks)、Custom Database スクリプトなど) の[単体テスト](#unit-testing)に関するガイダンスが提供されています。さらに、セキュリティ脆弱性のテストを行う際に役立つ Auth0 の[侵入テストポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/penetration-testing-policy)に関するガイダンスや、想定外の負荷がかかった場合でもアプリケーションが適切に動作するよう、[モック](#mock-testing) テストを当社の[負荷テストポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/load-testing-policy)と組み合わせて活用する方法についてのガイダンスも提供されています。

単体テスト

単体テストの目的は、コードの個々の単位を検証することです。Auth0 内で Rules、Hooks、または Custom DB scripts としてカスタムコードを作成する場合は、[Mocha](https://mochajs.org/) などのテストフレームワークを使ってコードをテストすることを検討してください。Auth0 を特に効果的に活用している企業では、Auth0 のテナント設定や関連リソースを[自動的にデプロイする](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/deployment)前に、これらの単体テストを実行することが有効だとわかっています。

連携テスト

[SDLC のサポート](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/architecture#sdlc-support) のアーキテクチャガイダンスで説明されているように、開発、テスト、本番用にそれぞれ別のテナントを設定することが推奨されています。Auth0 では、カスタムの [拡張](/docs/ja-jp/customize/extensions) から利用できる変数を設定できます。これは、Auth0 テナントにおける環境変数のようなものです。開発、テスト、本番の各環境間でコードを移動するたびに変わる参照をハードコードするのではなく、テナントで設定し、カスタム 拡張 コードから参照する変数名を使用できます。これにより、実行時にテナント固有の値が設定される変数をコードから参照できるため、同じカスタムコードを変更せずに、異なるテナントでも動作させやすくなります。 * Rules で変数を使用する場合は、[値を設定する方法](/docs/ja-jp/customize/rules/configuration) を参照してください * Hooks で変数を使用する場合は、エディターで [secrets](/docs/ja-jp/customize/hooks/hook-secrets) を設定する方法を参照してください * Actions で変数を使用する場合は、Explore Flows and Triggers を参照してください * Custom DB Scripts で変数を使用する場合は、[構成パラメーター](/docs/ja-jp/authenticate/database-connections/custom-db/create-db-connection#step-3-add-configuration-parameters) を参照してください テナント固有の値や、カスタムコード内で公開すべきでない機密の secrets を保持するために、変数を使用することをお勧めします。カスタムコードを GitHub にデプロイしている場合は、テナント固有の変数を使用することで、GitHub リポジトリを通じた機密値の漏えいを防げます。

テスト自動化

デプロイ自動化に加えてテスト自動化も組み込むことで、ビルドプロセス全体を自動化できます。これにより、設定やカスタムコードの新しいバージョンを Auth0 にデプロイして、自動テストを実行できます。テストで不具合が見つかった場合は、デプロイ自動化機能を使って、最後に正常に動作していたバージョンに戻すことができます。詳しくは、[デプロイ自動化に関するガイダンス](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/deployment)をご覧ください。

モックテスト

Auth0 の [負荷テストポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/load-testing-policy) と負荷テストを実施したいというニーズの兼ね合いから、Auth0 のお客様の間では Auth0 のエンドポイントをモック化するのが一般的です。これは、テストを制限することなく、想定どおりのインターフェースでアプリケーションが動作することを確認するうえで有効な方法であり、その際には [MockServer](http://www.mock-server.com/)、[JSON Server](https://github.com/typicode/json-server)、あるいは [Postman](https://learning.getpostman.com/docs/postman/mock_servers/setting_up_mock/) といったツールを活用できます。

プロジェクト計画ガイド

推奨する戦略の詳細をご確認いただけるよう、ダウンロードして参照できるPDF形式の計画ガイドをご用意しています。 [B2C IAM プロジェクト計画ガイド](https://assets.ctfassets.net/cdy7uua7fh8z/3er1aEQ7Ul0q3c9leJWczR/b1f18b4c16abb7e78b01e4eb2b52bb8e/B2C_Project_Planning.pdf)