PolicyCenter and Portal: Reconciling Siblings
~ by Randy Wagner
The Dependencies Between PolicyCenter and Portal Require a Cohesive Testing Approach
The problem with building a complete insurance software platform is that it is huge, running millions of lines of code and cannot all be designed and built at once. The history of every core system is that of a gradual build out. In Guidewire’s case, it was claims first, then policy and billing, and later came the portals. PolicyCenter (PC) and Portal are age-separated siblings that ideally should have been twins. Like kids from a later marriage, Guidewire is doing everything it can to help the two play nicely together. As they continue to massage the connections between Portal and the X-centers, the biggest testing focus has to be between the Portal and PolicyCenter. Vendor Engage aside, the rest of Portal depends so heavily on what happens in PC that testing has to be similarly dependent.
From Past Portal “Feeds” to Present Portal Integrations…
Back in ancient times, say 5 years ago, Portals were just that: a window into the main processing applications. You could write or modify a portal that pulled or fed information in and out of the main system. It could be coded and tested independently with little difficulty. That world has changed.
Today, especially with quick quotes and advanced policy transactions available within the Portals, the ties back to PC raise data and flow challenges. Marketing often drives the Portal side with a focus on fewer questions or touch points per transaction, integrations running in the background, and simplified logic to get results faster. Underwriting, on the other hand, is driving PC with a focus on details and greater functionality. This sets up a collision because the Portal isn’t executing transaction logic on its own. It depends on the pages in PC so when PC makes a change; it impacts Portal immediately.
Portal and PC Configurations Should Be Co-Developed
It would be nice to think we could just make sure the two teams are talking to each other, but it goes much deeper than that. Portal and PC configurations really should be co-developed. It’s incredibly easy to get into a cycle where a change in one causes a break in the other whose fix then breaks the first side, and so on. At the QA level, it’s incredibly frustrating to be blindsided by the changes. It takes some changes in thinking to square it up.
Two Ways to Ease the Challenges of Separately Developed PC/Portal Configurations
If your project is not running a combined PC/Portal development, the QAs will need to be a little creative. The biggest key will be the external integrations.
- First, have the QA for Portal and the QA for PC compare notes on when the integrations fire and how they handle the returned data. This single effort will yield enormous rewards. Integrations are driven by the sequencing and if Portal and PC are out of step with each other, this is where the issues will be most visible.
- Second, the integrations team will often only test to ensure the connection and return are successful but not how various transactions and user behaviors impact the flow. Consider the following, for example:
-
- What happens when you change the underlying data, as often occurs when an agent is trying to get the best price?
- What happens when an integration fires a second time on a quote or a policy change?
- How is the behavior different in Portal versus PC?
- Is the historical and current data being stored appropriately?
Focusing on these more realistic fluctuations in the flow will help the teams stay in sync and reduce the costly ping-pong effect of defects from each side.
Upfront Coordination and Planning of QA Can Save Time and Heartache Later
While there is no magic pill to command a smooth implementation of Portal and the X-centers, sometimes you have to get creative in your testing to keep the teams in line. QA doesn’t have to feel the whiplash of teams over-correcting as they lurch forward, out of sync with each other. Coordinate the testing and you can smooth out the forward motion and save a lot of heartache in the stabilization phase!
Randy Wagner is Director of Quality Assurance for CastleBay Companies. He has 20 years of consulting experience across private and public sectors, Guidewire InsuranceSuite, InsuranceNow, and Duck Creek, with specializations in quality assurance, configuration management, and automation.