LinkedIn
Copied!

Table of Contents

Testing a new application

Version:

Only available versions of this content are shown in the dropdown

Testing a new application involves testing in different environments.

Testing and deploying application changes

Test a new application in the Build environment before migrating the application to a test or production environment. Testing in the Build environment enables you to verify that basic functionality and interfaces work correctly, and that performance is acceptable.

  1. Run functional tests, to test specific features from the end-user perspective.

  2. Test features used by all service intents, such as security, eligibility, search, and loading of data. Automated scripts are recommended for this unit testing, but are not required.

  3. Verify that the out-of-the-box reports and your custom reports run successfully, and that they show your implementation layer data, rather than the default demonstration data. This can be an automated test.

  4. Test all integrations, both independently and with associated integrations. 

    Test integrations for any optional Pega Customer Service components and other applications that you plan to use. See the product documentation for the component or application to determine which product components to test.

    For Pega Call, check the following pieces of moving infrastructure:

    • Switch
    • Provider software
    • Connectivity (network)
    • CTI engine
    • Integration with the CTI engine

    In addition, check all delegated rules (for example, coaching tips).

  5. Test security. Test the most common roles to ensure that the required access groups are configured and point to the correct software version.

Testing in the test or production environments

After you import your application to a test or production environment, test the application in the new environment to verify that it works correctly in that environment.

  1. Verify that the source and destination files are the same.

  2. Run functional tests, to test specific features from the user perspective.

  3. Test features used by all service requests, such as security, eligibility, search, and loading of data. Automated scripts are recommended for this unit testing, but are not required.

  4. In the test or production environment, run the Application Guardrails Compliance Score to ensure that the application meets guardrails.

  5. Verify that there is an open production ruleset so that managers will be able to edit dialogs, coaching tips, and knowledge content in the test and production environments, and so that they can share those changes. Rulesets are typically locked during migration and must be unlocked after migration.

  6. Verify that the out-of-the-box reports and your custom reports run successfully, and that they show your implementation layer data, rather than the default demonstration data. This can be an automated test.

  7. Test all integrations, both independently and with associated integrations.

    Test integrations for any optional Pega Customer Service components and other applications that you plan to use. See the product documentation for the component or application to determine which product components to test.

    For Pega Call, check the following pieces of moving infrastructure.

    • Switch
    • Provider software
    • Connectivity (network)
    • CTI engine
    • Integration with the CTI engine

    In addition, check all delegated rules (for example, coaching tips).

  8. Verify that the integrations point to the correct system of record, and not to the system of record for the Build environment.

  9. Test security. Test the most common roles to ensure that the required access groups are configured and point to the correct software version. Use these common roles in your smoke tests (see next step).

  10. Run a smoke test to compare the source and destination environments. Verify that all tests that pass in the build environment also pass in the test or production environment. If anything fails, compare the environments to determine whether it is a difference in environment that causes the test to fail. If the environment causes a failure, either fix the issue that causes the failure or adjust the test as appropriate for the new environment.

  11. Run performance tests to verify that performance meets expectations. Pega recommends automated performance testing. Save the results so that you can compare them to future performance test results to determine whether an application update has a performance impact.

Testing in the UAT environment

After you complete testing in a Test environment, it is common for large call centers to perform User Acceptance Testing (UAT) in a designated UAT environment, which could be a preproduction environment. UAT ensures that users will be able to successfully complete their work and meet business objectives.

Organizations that use Scrum for application development will complete less formal UAT as part of each sprint cycle.
  1. Verify the integrity of the UAT environment.

  2. Have the end-users (or business analysts acting as end-users) run scripts to test all scenarios, including boundary and exception testing. The end-users (trainers, managers, and directors), must then perform the following steps during UAT:

    1. Verify that there are no major issues.

    2. Review changes to understand the features.

    3. Customize the delegated rules (for example, coaching tips) as needed.

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.