Pega’s goal is to have a high-quality, working system in the simplest, most rapid way possible. You can accomplish this by using tools and processes that improve and streamline the normal testing approach:

• Test early and often
• Involve business stakeholders; ensure you are focusing on outcomes
• Focus your manual testing on what has changed
• Use a Pega Express Test plan
• Use automated testing tools; PegaUnit and PegaScenario (or a 3^rd party alternative)
• Use the Deployment Manager to support the DevOps pipeline (continuous integration and continuous delivery)

Your test team is likely to be a combination of business representatives and testing professionals that are familiar with industry-standard tools and approaches. Your test team will form an important part of the Scrum team. They will have been involved in the Prepare phase, when your Pega Express Test Plan will have been created. This plan helps you arrange your testing so that it is effective and efficient. The test team will also have been involved in the design of user stories, ensuring the Product Owner and business have set appropriate acceptance criteria, while also getting ready for testing.

Testing early and often ensures the discovery of small issues before these issues snowball into larger, more costly defects that are harder to fix and retest later on. This is why you test in sprint; to give feedback as early as possible. You should also involve business stakeholders in each phase of the project. From the beginning of the project, it is important to integrate end user representatives into the scrum team as scrum testers. End user representatives can identify issues quickly and will provide invaluable insights into how the application will achieve desired outcomes, making them ideal testers.

So what should you test and how? Firstly, you should test in a dedicated environment. During the sprint, user stories should be promoted from the development to the test environment. Each user story then needs to be tested to ensure it meets the acceptance criteria and the Definition of Done. User stories will be tested in-sprint manually and should focus on testing what has been configured rather than testing out‑of‑the‑box Pega functionality which has already been thoroughly tested e.g. there is no need to actively test Pega pulse.  

Automated test tools should also be used to create test scripts during each sprint. Automation drives quality, ensures that any future regression is captured early, and will streamline testing in later phases. During configuration the developers will have created unit test rules (using PegaUnit) that can be run as part of the DevOps pipeline (CI/CD). During in-sprint testing, your test team should also create automated scenario tests using either Pega Scenario or a 3^rd party tool. This is in addition to PegaUnit tests. During testing, defects should be raised immediately and fixed in-sprint or added to the next sprint if low priority. A daily triage should be setup to determine priority and severity.

Pega platform built-in tools will automate the running of test scripts from within Pega’s Deployment Manager, performing regression tests with minimal effort. This takes the focus off creating extensive script documentation and refocuses on test execution. The Application Dashboard provides a holistic view of the health of the application, giving you a snapshot of the guardrail score, test coverage as well as PegaUnit and Pega Scenario test results.

Finally, if you are in the last sprint of your first release or a major release, you should dedicate that sprint to hardening. You should not deliver any new user stories in the hardening sprint; instead, you will conduct performance, security and a final end to end user testing (usability testing) to ‘harden’ the application before it goes live. Hardening provides an opportunity to establish baselines for usefulness, efficiency, effectiveness, learnability and satisfaction. You can measure against this baseline during Adopt.

What happens next? Build is an iterative process. At the end of each sprint, if there is a user story that has not been fully tested, or high priority defects have not been fixed / retested, then the user story should be moved back to the product backlog for inclusion in a future sprint. Your next steps might be to deploy your new features to Production (using Deployment Manager) or you’ve just completed your hardening sprint, and now it’s time to go live and move into the Adopt phase.

The related content links below provide methods and tools to help you.