> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 品質保証（B2C）

> B2C IAM実装の品質保証で考慮すべき事項。

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

* アプリケーションは、障がいのある人にとっても理解しやすく、使いやすいですか。
* アプリケーションは、多種のブラウザーやデバイスで動作する必要がありますか。
* アプリケーションは、複数の国で、あるいは国際的な環境で動作する必要がありますか。
* 予期しない生産負荷が発生した場合、アプリケーションのパフォーマンスはどうなりますか。
* セキュリティー関連の脆弱性からアプリケーションをどのように保護しますか。

Auth0の[ユニバーサルログイン](/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)、カスタム データベースのスクリプトなど）の[ユニットテスト](#unit-testing)に関するガイダンスが提供されます。また、セキュリティの脆弱性をテストする際に役立つAuth0の[ペネトレーションテストポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/penetration-testing-policy)に関するガイダンスも提供されます。さらに、[負荷テストポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/load-testing-policy)と組み合わせて[モック](#mock-testing)テストを活用して、予期しない負荷の下でもアプリケーションが確実に動作するための情報も提供されます。

## ユニットテスト

ユニットテストの目的は、コードの個々のユニットをテストすることです。Auth0内でRules、Hooks、カスタムDBスクリプトの形式でカスタムコードを作成する場合は、テストフレームワーク（[Mocha](https://mochajs.org/)など）を使用してコードをテストすることを検討してください。Auth0を上手に活用している企業は、Auth0テナントの構成その他を[自動的にデプロイ](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/deployment)する前にユニットテストを行うと効果的だと言います。

## 統合テスト

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

* Rulesでの変数の使用については、[値の構成方法](/docs/ja-jp/customize/rules/configuration)を参照してください
* Hooksでの変数の使用については、エディターで[シークレット](/docs/ja-jp/customize/hooks/hook-secrets)の構成方法を参照してください
* Actionsでの変数の使用については、「フローとトリガーを見る」を参照してください
* カスタムDBスクリプトでの変数の使用については、[構成パラメーター](/docs/ja-jp/connections/database/custom-db/create-db-connection#step-3-add-configuration-parameters)を参照してください

<Info>
  ### ベストプラクティス

  テナント固有の値や、カスタムコードで公開すべきではないセンシティブな情報を含むには、変数を使用するのがおすすめです。カスタムコードがGitHubにデプロイされている場合、テナント固有の変数を使用すればGitHubリポジトリを通じたセンシティブな値の公開を避けられます。
</Info>

### テスト自動化

デプロイメントの自動化とテストの自動化を組み込めば、ビルドプロセス全体を自動化できます。これを利用して、新しいバージョンの構成やカスタムコードを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のエンドポイントをモックすることが慣行となっています。これは、テストを制約することなく、想定したインターフェイスでのアプリケーションの動作を確認できる有効な方法であり、補助として[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 Project Planning Guide](https://assets.ctfassets.net/cdy7uua7fh8z/3er1aEQ7Ul0q3c9leJWczR/b1f18b4c16abb7e78b01e4eb2b52bb8e/B2C_Project_Planning.pdf)