Time Travel; Environments

~ by Randy Wagner

Time Should Be Your Friend

Event Driven Transactions & Date Driven Transactions

There are two types of insurance transactions: event driven transactions such as coverage changes and date driven transactions such as renewal processing. In both types of transaction, dates are critically important.

With back-dated, out-of-sequence and prior term endorsements the actual coverage change may be identical, but the gyrations required of the system depend on when the event occurs and when the system is notified.

Time Travel Planning is Critical in QA

Time is a critical factor and time travel needs to be planned into any project QA effort. Poor planning creates unnecessary stress on the client, sysadmins, affects the budget, and people start losing track of where to test, where to duplicate a defect, and even what day the system is on. It doesn’t have to be so challenging.

Time Travel Planning and Coordination Help to Optimize the QA Cycle

Let’s start with the need for time travel. I can’t test policy changes properly if someone is moving the clock a year down the line while they test renewals. It’s difficult to validate non-pay scenarios while the next QA is doing escheatment work in the same environment. Planning and coordination are key to avoiding wasted time and effort.

Plan Three Things Around Time Travel Up Front: Environments, Ownership, and Data

#1. Time Travel Environments – How Many Should You Have?

First, identify the number of time travel environments needed during the Inception phase. For a big project, especially when transitioning to the Guidewire Insurance Suite, a time travel environment per X-center, above and beyond the QA environment for that center, is a safe bet. There’s a lot going on in basic testing just to meet the sprint schedule. As mentioned above, when you start moving the clock around, it messes with everyone else’s work. There’s rarely more than one person in a time travel environment at a time and when there are, it takes a lot of coordination not to step on each other.

Time Travel Environments Should Not Be Rushed – Plan Ahead

Plan on having the environments ready in the early sprints. Even by sprint 2, time related functionality can start cropping up. Start environment planning up front and then follow up with the sysadmins and release manager in Sprint 1 so they have time to get boxes/vm’s and scripting ready. Rushed environments and hurried release scripts are not conducive to smooth transitions.

#2 . Ownership – Identify Your Gatekeeper to Keep Priorities Straight

Second, define who owns each time travel environment. Typically, it’s a more experienced QA, likely a lead, but can be anyone. You need a single point of contact for everyone to reach out to when they have something they need to do in there. The owner acts as gatekeeper for competing users and helps prioritize what gets done.

#3. Data – Set a Clean Up Schedule to Account for Changing Data

Third, data is the one area people tend to forget about. As the clock continues to move further and further into the future, you start to get beyond certain rate tables or custom functionality which can affect test results. Particularly during the development phase, the code is changing so data evolves in the tables. Old data can start creating issues with batch processing or old accounts can throw a wrench into newer testing. You’ll want to set a clean-up schedule, define who can purge the data, preferably the environment owner, and reset the clock. Remember, clocks should only be moved forward. Jockeying them back and forth will give you untold headaches, even if someone swears you can do it.

Manage Time Travel Environments to Release Schedules for Efficient Tracking

You can use fewer time travel environments, but you will spend far more in the cost of resource time to coordinate everyone than just spinning up a new vm. And really, once the release scripting is done, it’s not much additional effort. Time Travel environments should be kept on the same release schedule unless there is a significant reason to pull one out. It’s a bigger hassle to manually track which release is on the box than to just keep it in the normal rotation and it reduces false positive defects.

Time travel doesn’t have to be a surprise and it can be managed pretty well. Plan ahead, put some guardrails around it, and life will be a lot smoother across the project. Now if only we could take all these lessons learned and travel back in time to save ourselves so much trouble!

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.