It’s Pega PRPC testing, so how big a deal is that?

It’s the cursor-on-a-blank-screen experience all test managers — aspiring or experienced — know and dread; and nothing plagues them more than planning a QA approach for Pega PRPC based applications. So what’s the big deal about testing Pega water-mark2PRPC solutions? I mean you already have a Test Plan template or past experience to help you crack it. Can’t you delve in detail and design a standard approach? While templates or experience can contribute to a reasonably good test approach it does not always make it representative or exemplary. So let’s break down exactly how to write an effective Pega QA Approach. If you’re ever having trouble churning out a suitable QA approach for every new Pega PRPC solution, come back here and re-read this formula to lift yourself out of that anxiety of ‘Should I reuse my old test plan or is this my chance to apply thought leadership?’

  1. You must understand that any COTS (Commercially Off The Shelf) product when configured according to the requirements, will have base product limitations. Pega PRPC is no exception. This is especially important when you are implementing Pega Rules Process Commander with multi-layers of Pega frameworks along with it such as CPM, NBA, PUI, PCS, etc. Once you cognize this, you must gain a deeper understanding into what each of these frameworks brings forth to the solution, so you will be better to conclude where to draw testing boundaries.
  2. During the elaboration phase, each attribute must be thoroughly validated with the way Pega Design deals with it. Requirements that need too much customization in a Pega PRPC solution will primarily fail one of the guardrails of Pega. This step is necessary in order to avoid potentially high severity defects discovery later. The same rule applies for business logic as well. Validating business logic against Pega PRPC and the planned frameworks features is crucial, and hence it is imperative to realize when to start.
  3. The brilliance of Pega PRPC product is that it can easily build any complex solution, but it is equally thought-provoking to apply the right skill to maneuver it. You may glance through the PDN website for further insight into the product features. The seemingly simple configurations can be so cryptic that you might be surprised to realize there were misses on how poorly the application handles what it is not supposed to do. Had the same requirements been written for a java or a dot net implementation, developers could have coded from scratch and have had the freedom to design by the book. Therefore, more focus should be laid to identify and cover negative test combinations.
  4. Unless you are an expert in solution’s domain, it is not easy to predict business-specific roadblocks upfront before construction begins. For this reason, one should continue to explore negative scenarios after the solution is built, as well as at various stages during the process and once it is fully complete. Extend focus for exploratory testing in your QA approach to derive outcomes of what a business rule can do and match if it contradicts elsewhere, or gets displayed the wrong way.
  5. An important part in your QA approach should be about expectations in accordance to testing heavy rules based application, resulting in a predictive possibility of low performance consequences. This is where you must know the Pega PRPC product and be able to use its built-in utilities for testing benefits to nip issues at the start. Base-lining how an application performs with load and analyzing how the application responds to a single user are two different things. While concluding application behavior within acceptable user load limits is one part of the assessment, it is equally important to verify how the parameters and control is passed within the application, in other words, rules performance, if it is within the recommended limits as per Pega PRPC standards.
  6. Along with everything else mentioned above, you should also do a simple check on the developers’ adherence to Pega PRPC Guardrails.

While the above helpful tips are for a transformational solution, for Pega PRPC upgrades the test approach is slightly different; but you will have to wait until my next blog post.

Swapna Priya Gambhiraopet

Associate Manager - QA, Virtusa. Swapna has around 11 years of leadership in diverse areas of Software Quality Assurance & Testing, where she developed a wealth of experience in Test Planning, Team Management, Test Execution, Test Design, establishing global delivery teams, Test Estimates, set strategic direction for Testing and Manage QA function E2E. Swapna has focused on Pega based solutions for Warranty, Card Payments, and Insurance. She enjoys reading psychology books and has an interest in developing DIY mini electronic items. She holds a Bachelor of Technology in IT from JNT University.

More Posts

2 Comments

  • Anuj Sharma May 26, 2015

    Very Nice and informative article. 🙂

  • Gangadhar Gupta June 5, 2015

    It’s really very Interesting, Innovative, and Informative Article.

Comments are closed.