Lovability testing

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

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

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.

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):

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.

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

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.

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.

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.

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.

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.

• 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.