Quality Assurance (B2C)

Quality Assurance is important in identifying issues before they impact your customers and, depending on the nature of your project, there are several different types of quality assurance testing that you’re going to want to consider as part of your integration with Auth0:

• Is your application easy to understand and use, even by those with a disability?

• Does your application need to work across various different browsers and devices?

• Does your application need to work in multinational and/or international environments?

• How will your application perform when subjected to unexpected production loads?

• How can you ensure your application is safe from security-related vulnerabilities?

Auth0 Universal Login and associated UI widgets (such as Lock) have already been designed and built following usability and accessibility best practices, and provide tested out-of-box support for a whole host of browsers and devices. Support for internationalization (I18N) is also provided out-of-box, with built-in extensibility designed for custom multi-language and localization (L10N) situations.

To ensure functional requirements are met and unexpected events are handled correctly, guidance is provided for testing the integration between your application(s) and Auth0, and for unit testing individual extensibility modules (such as Rules, Hooks, and Custom Database scripts). Guidance is also provided regarding Auth0's penetration testing policy to help when testing for security vulnerability, and also how Mock testing can be leveraged in conjunction with our load testing policy to help ensure your application(s) perform under unexpected load.

The objective of unit testing is to test individual units of code. If you create custom code within Auth0 in the form of Rules, Hooks, and/or Custom DB scripts, you should consider use a testing framework (such as Mocha) to test your code. Companies who have been most successful with Auth0 have found it useful to execute these unit tests prior to automatically deploying Auth0 tenant configuration and collateral.

It is a recommended best practice that you set up different tenants for development, testing, and production as discussed in Architecture guidance for SDLC support. Auth0 allows you to configure variables that are available from within custom extensibility; these can be thought of as environment variables for your Auth0 tenant. Rather than hard code references that change when moving code between development, test, and production environments, you can use a variable name that is configured in the tenant and referenced by the custom extensibility code. This makes it easier for the same custom code to function, without changes, in different tenants as the code can reference variables which will be populated with tenant-specific values at execution time:

• For use of variables in Rules, see how to configure values

• For use of variables in Hooks, see how to configure secrets in the editor

• For use of variables in Actions, see Explore Flows and Triggers

• For use of variables in Custom DB Scripts, see the configuration parameters

You can automate your overall build process by incorporating deployment automation as well as test automation. This can be used to deploy new versions of configuration and/or custom code to Auth0 and execute automated tests. If the tests uncover any failures, the deployment automation capabilities can be used to revert to the last working version. For further information, see the deployment automation guidance provided.

In a balance between Auth0’s load testing policy and the desire to load test, it is common practice among Auth0’s customers to mock out Auth0’s endpoints. This is a valuable practice in order to ensure that your application works with your expected interfaces without having to restrict your testing, and tools such as MockServer, JSON Server or even Postman can be used to assist.

We provide planning guidance in PDF format that you can download and refer to for details about our recommended strategies.