Skip to main content

Lovability testing

Testing for lovability explained

The Pega Express testing strategy is designed and executed during the Build phase. Testing is important to validate that the Pega Platform solution is not just functional but also lovable by the client. 

The testing strategy does this through:

  • Shifting left – Start testing earlier in the project and make it a component of each sprint
  • User testing – Include business users earlier in the project to provide feedback, as well as professional testers; user testing is different from UAT (user acceptance testing)
  • Planning – Create a test plan to ensure that the application meets business outcomes, not just functional requirements
  • Consistency – Agree and adhere to a definition of done (DoD)
  • Tools – Use built-in validation tools such as the Application Quality Dashboard or Pega Predictive Diagnostic Cloud
  • Automation – Build an automated test suite with Pega Platform or third-party tools
Note: Testing is integral to project success, ensuring that the Pega solution is both lovable and high quality. Unlike traditional IT projects that only do testing at the end, the Pega Express strategy is to start testing activities during the Prepare (or even Discover) phase and continue for the duration of the project.

View the short video for an overview on Pega Express testing.

Shifting left

Shifting left means that you begin testing activities earlier in the project life cycle. DevOps uses this practice in software development to help teams focus on quality, work on problem prevention instead of detection, and begin testing earlier in the project timeline. It plans for and validates your application quality from the first day.

As shown in the following image, the Pega Express delivery approach front-loads the project with various testing and validation activities. This concept of testing early, often, and continuously is central to Pega Express and supported by a formal process and set of built-in tools to promote quality checks within each sprint and throughout the entire project life cycle.

Shift Left

Shifting left is straight forward with Pega Express, it is achieved through the following (note due to this approach issue identification should be greatest during Sprint Testing and start to significantly reduce as your move towards Release Testing):


Testing Focus

Testing Type

Shift Left Best Practice

Sprint Testing

Unit Testing

  • Use Pega Diagnostic Cloud to resolve issues
  • Use Guardrails
  • Lean Usability Test on XD Prototypes during Prepare
  • Pega’s tools ensure you focus only on the MLP
  • Focus only on what has changed
  • Mandatory Adherence to Definition of Done
  • Automate Testing with Pega Unit

Sprint Testing

Scrum Testing

  • Test against real interfaces early to flush issues
  • Business involved to ensure early validation
  • Automate with Pega API & Pega Scenario

Functional Testing

End to End

  • Deploy with DevOps & use automated regression tests
  • Pega Express Test Plan to drive effort and focus

Functional Testing


  • Deploy with DevOps & use automated smoke tests

Release Testing

Performance and Security

  • Utilize deployment manager

Defects are easier and cheaper to fix the earlier they are found. The cheapest place to correct an issue is during the Discover or Prepare phase. The most expensive place to find and fix defects is during a post-build QA phase or Acceptance Testing as was traditionally done in waterfall projects. Therefore, Pega Express encourages validating and testing the solution as early as possible.

Testing activities in Prepare

Your test strategy begins to take shape during the Prepare phase. Before any code is written, business architects (BAs) and testers validate the business outcomes, scope, and design with the client. As BAs create the user stories, testers validate that each user story is clear, concise, actionable, and contains acceptance criteria.

All user stories must have acceptance criteria

Acceptance criteria complement the user story narrative. They describe the conditions that must be fulfilled before the story is done. The acceptance criteria enrich the story, make it testable, and ensure that the story can be validated, demonstrated, or released to the users and other stakeholders.

Well-written acceptance criteria have the following characteristics:

  • Testable with clearly-defined expected results
  • Clear and concise, not ambiguous
Tip: A Pega Express best practice is to create three to five acceptance criteria for detailed stories.

Creation and adherence to a Definition of Done

In addition to creating individual acceptance criteria for each user story, the Scrum team creates a formal Definition of Done (DoD), which identifies consistent acceptance criteria required across all user stories. A DoD ensures the quality of work. It is a checklist of what must be done for user story development work to be considered complete.

The Definition of Done ensures everyone on the team knows exactly what is expected of every component the team delivers. DoD ensures transparency and quality fit for the purpose of the product and organization.

The DoD typically includes items such as:

  • A feature that is developed, unit tested, and meets the acceptance criteria
  • Unit test scripts that are created in the PegaUnit application and are available for future regression testing
  • An item is ready for acceptance testing
  • Any code that goes through code review
  • A releasable item
  • No increased technical debt

You can download a Definition of Done template from the Pega Express Delivery Resource page.

Microjourneys and business outcome focus

One question that always comes up is, "How do you organize testing so that it is effective, efficient, and validates that we are delivering the client's business outcomes with a product they will love?"

Pega has designed a simple test plan that achieves these goals while providing a Microjourney™-centric approach. The plan ensures comprehensive test coverage and enables reporting on the testing status in terms of business outcomes rather than disparate functional elements and generic test coverage stats.

The test plan gives the client assurance that their desired Microjourneys work as intended and that the resulting product is both lovable and fulfills their business outcomes.

Test plan creation

Creating a Pega Express test plan is very simple. To start:

  1. Build a table with six columns to easily identify and fully test all of your Microjourneys.
  2. In the first column, list your Microjourneys, such as "Obtain Mortgage Loan."
  3. In the second column, list the subcases, the basic Pega building block, of each Microjourney.
  4. Then, break it down further in the subsequent columns, by stages, personas, channels, and interfaces for each Microjourney.

Once completed, you have a table for each Microjourney, similar to the following example shown. Each row in the table represents a path to test in the Microjourney ensuring that all outcomes of the Microjourney are tested.

Pega Express Test Plan
Note: One of the advantages of this approach is that it shows the application's health in terms that business stakeholders understand. Rather than report on features, the plan reports on specific customer Microjourneys and business outcomes. It shows how much of the journey has undergone testing, which paths passed testing, and which areas have issues. The business stakeholders can see what is working and what is not because the reporting is in a language and format that they understand.

Validation tools and automated testing

Automation is about driving to quality and repeatability. The System Architect's work is not complete until they have unit tested their work and created a PegaUnit test script.

Built-in validation tools

Pega Platform includes several built-in validation tools and dashboards that provide a holistic view of the health of the application, such as the Application Quality dashboard, which focuses on application health and the Pega Predictive Diagnostic Cloud (PDC), which provides a view into the health of the cloud service.

Tip: Check the Application Quality dashboard and PDC at least once per sprint.

Build up your automated test pyramid using Pega's built-in tools or 3rd party tools

Pega Platform's native tools support components of the test pyramid. You can also use industry-standard tools. However, when testing a Pega Platform application, Pega tools are usually the best option.

In the following image, click the + icons to learn more about the test pyramid.

Checklist for success

  • Shift left and involve testing resources from the start of the project
  • Ensure that all user stories have acceptance criteria
  • Create and adhere to a DoD
  • Create a test plan to focus on Microjourneys and business outcomes
  • Use built-in validation tools
  • Automate your testing

To learn more about Unit Testing and how to use PegaUnit, see the Pega Academy module Unit Testing Rules.

Check your knowledge with the following interaction.

This Topic is available in the following Module:

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice