Benefits Administration Testing: Part 2
A Systematic, Complete and Efficient Approach
Posted on 1/9/2007 (originally published in print on 1/1/2005)
by Marc Heinz
I've been involved with PeopleSoft implementations for a while now and have seen all sorts of implementation methodologies with new economy names like Fusion, Method 1, Fast Track, i-somethingmadeupbymarketing, e-fast-n-cheap, slamitin-runforcover and the like. Usually these implementation models put a big-brand spin on the familiar steps of design, configure, build, test and roll-out, but contain very little or no package-specific configuration and testing guidance. Has anyone else noticed that these encyclopedia-sized implementation guides are used more during the sales cycle than the project? In my view, precious little documented guidance exists in our PeopleSoft world regarding functional configuration and testing. I've never seen a methodology, not even from PeopleSoft, that got down to functional specifics on how to make sure the application is properly configured and adequately tested. I'll admit that the PeopleBooks have gotten better over the years, but I'd describe the improvement as a progression from a state of wholly inadequate and sometimes totally wrong to partially useful in some cases.
Ever since the first time I helped configure and test the benefits administration module, I've had a persistent concern stemming from one very good question. Deanna Allgood asked me, “How can we be sure we tested everything?” I can't remember my exact answer, but I know it didn't provide the comfort she was looking for. At the time, I didn't know a better way to test the system except for coming up with a massive list of test scenarios that somehow seemed more complete and credible the longer it got. In this two-part article, I am trying to answer that question for Deanna in a much better way. Perhaps some of you have asked or have been asked the same question.
In part one, fourteen distinct eligibility groups have been isolated from the benefit program example. Remember, distinct eligibility groups are defined as a selection of employees who are eligible to choose an identical set of benefit options in any given event. Isolation of the distinct eligibility groups is an important first step in the identification and control of the variables present in our system. The event class is the second key variable to consider in determining a valid test population.
By using this testing method, we are trying to conduct a complete test of the system while minimizing the number of test cases and test employees. Once every logically distinct variant of employee (eligibility group) is tested through each separate processing path (event class), the eligibility and event configuration of the benefits administration system may be fully validated. Multiply the number of eligibility groups by the number of event classes to determine the size of the test population needed.
Number of Distinct Eligibility Groups x Event Classes = Total Number of Test Employees
In the example in Figure 1, seven distinct event classes are present, five plus another two to accommodate the MSC event's special characteristics. I usually split the MSC event into three specific scenarios, one where the employee gains eligibility, another where the employee loses eligibility, and finally a case where the employee neither loses or gains eligibility and the expected result is a final processing status of “Prepared None.” It is important to note that splitting the MSC event classes in this way depends on how the MSC class is configured with respect to the “Use History” option. If Use History is not turned on for the MSC event class, this three-way split is not necessary.
Figure 1
To continue reading this article you must have a current VP1 Subscription.
