To keep up with faster turnaround times and shorter software development cycles, it is often easy to fall into the trap of leaving the development team to power through building the application and assigning a separate testing team to check for bugs and defects. The truth is, however, that it’s more efficient and cost effective to get the developers involved in testing the software as they go, rather than working in a vacuum. Relying on test engineers, who didn’t create the application in the first place, to find problems not only places a huge burden on their shoulders, but also ends up taking longer. It also costs more and can compromise the quality of the product. If you wait too long to test the application, the best-case scenario is an expensive re-coding job. The worst-case scenario is a buggy application resulting in dissatisfied users and a potentially brand-damaging PR nightmare.

What

Testing continuously means that bugs, hiccups, or defects of any size can be highlighted and fixed as part of the development process, improving the quality and security of the software and saving valuable time. Testing the code early and often throughout the development process means that the developers writing the software can identify potential bugs more easily, putting them right as they go.

Why

It’s much easier to fix a defect if you find out about it immediately after you build the software. The debugging processes is faster than if you are delving into rulesets several months after they were configured.

How

In Pega, you create draft working screens and processes very rapidly. These are not complete with all data fields, interfaces, working buttons, UI etc., but they give a good idea of how the working system will look and can be changed quickly. These draft screens and processes should be tested at an early stage to ensure they function as expected, and later when they are complete they can be tested again to ensure they work fully.

In the early stage, you want to practice effective unit testing. This starts with a formal Definition of Done (DoD) – basically a checklist for each use case, or specific task of what must be done in it to be considered finished. Leverage PegaUnit, the extensive Automated Unit Testing capability, during the build process to ensure your data, flows, case types, and more, behave as expected with the test cases. You can also regularly assess the readiness and health of the app using the App Quality Dashboard – it displays your Guardrails score, which highlights what rules are not covered in automated unit testing, and the actual results for what is covered.

A key part of the DoD is to incorporate a UI/UX review during the development process. User experience is very hard to improve after something is written, and very easy to do well if done from the start.