Configuration and acceptance testing

📘

The content on this page deals with a legacy feature of the ​Akamai​Identity Cloud (in this case, the JavaScript SDK). If you are currently an Identity Cloud customer and are using the JavaScript SDK, that SDK is still supported. However, if you’re new to the Identity Cloud the JavaScript SDK is no longer available. Instead, you should use Hosted Login for your login and registration needs.

Configuration Acceptance Testing is a separate process from end-to-end integration testing and user acceptance testing. The objective is to confirm that any configurations made by ​Akamai​ have been completed as agreed upon in any configuration documentation the customer approved during the requirements gathering phase. This testing is completed by the customer at the Akamai-hosted reference implementation.

​Akamai​ provides a set of 20+ standard use cases along with step-by-step test actions and their expected results. Custom test cases will also be provided for any custom requirements agreed upon in the configuration documentation.

Configuration Acceptance Testing may cover the following types of activities:

• Verify that the correct fields are shown on each screen (social registration, traditional registration, edit profile, and so on).

• Verify that the correct validations are applied to each field (length, format, requiredness, and so on).

• Verify that any select menus include the correct options.

• Verify that the correct field labels and error messages are displayed in each language.

• Verify that the new records are created with all of the necessary data captured by checking in the Console .

• Verify social and traditional login work as expected for existing records.

• Verify that any post-login screens are displayed as expected (gating based on age, email verification, acceptance of legal terms, and so on).

• Verify that data is updated correctly from the edit profile screen.

Because all styling and screen layout will be controlled on the customer’s site, Configuration Acceptance Testing should not cover the following types of activities:

• Styling/layout of the widget.
• Client-side functions for validation or navigation.
• Client-side content gating.
• HTML-controlled messaging/navigation on the reference implementation.

Configuration Acceptance Testing may start off with a screenshare for the ​Akamai​ project team to demonstrate that the reference implementation matches the configuration documentation and satisfies the test cases. The customer will either confirm acceptance of the configuration or provide ​Akamai​ with a list of specific changes needed to satisfy the configuration requirements. Once the follow-up items are completed, the project team will notify the customer for final testing and approval.