Time Warp: Business Cycle Testing

"Let's do the time warp again..."

Video

A video version of this blog

Business Cycle with Time dependencies?

What is a business cycle and why do I need to test it?  I'm really talking about any type of business process that has time based business rules.  The rules can periodic in that they fire on a regular basis or they can one-time based on some time based criteria.  Most of the ones I've worked with are contract oriented or billing cycle oriented. Examples include telecom contracts, home mortgage servicing systems, term based insurance to just name a few.   They usually have some time based sequence of operations, date based rules and may have some type of state machine.  

Testing is complicated by the fact that data may need to be of a certain age before processing begins.  Loan payments may need to be delinquent.  An insurance policy may start the renewal process some time before expiration.  Collateralize debt may have payment, reimbursement  and equity distribution segments based on the time of the month.

Compressing the clock

The length of the business process and the length of a test are different.  In this picture we see that we have 30 hours to run simulated processing for a 30 day month. We are compressing a 30 day process into a 30 hour test without changing any of the business rules or system behavior.  

Understanding dates and time

Computer software can involve a lot of dates. They are used to represent action in the system, time of events in log output and are analyzed as part of business rules.  Three relatively common date concepts are 

• "Current Date" meaning "today".  
• "Activity Date" an event occurs and is recorded in the system. This usually must be within the cycle of the test.  This is different from an "Effective Date" when there is a delay in processing when there is a data fix or when something is back dated.
• "Effective Date" when an operation actually takes effect.  This is may be different than the "Activity Date" when something is processed out of order.  A system that runs only on effective date may not need any date/time manipulation.

Business data and information may use "any" or "all" of these data types. Integrated business cycle testing must manipulate all three to maintain the correct relationships.

Manipulating Time

We want to put our data in the "right place" in our timeline for each portion of the test cycle. The data needs to be coherent and must interact correctly with users, business rules and other systems.. 

Let's talk about four different ways of manipulating time while testing.  There are probably plenty of others. These are four that I've seen in person or heard about.

Explicit Effective Date

It is possible to run a full cycle test using just effective dates if all of the APIs support passing in effective dates. This lets the test back or forward date the operations. This approach will probably not work with most user interfaces since they will not allow user input in effective date for all operations.

Manipulating System Time

Change the system clock on the operating systems where the business logic runs. This approach works best in systems with few connecting components and few servers.

Pros:
No application changes are required
Works easily with single machine applications
Records the internal test timestamps in logs and databases

Cons:
Doesn't work for shared machines
Doesn't work for SaaS applications
Doesn't work in the cloud.
Logs will show the in-test time and not the external world time.

Manipulating Data Time

Change the recorded time-stamps for all data at rest between stages.

Pro:
Works if all data is in mutable data stores.
Requires no code or system changes

Cons: 
Hard to test with partner systems.
File and log time will show different times
Partner data must also be modified
Hard to find all impacted systems.

Manipulating Program Time

Alter the program's concept of current time.  This can be done by adding crosscutting code on Date and Time libraries.  The aspects go to a central time server to obtain the current "system test" time and use that in their calculations.

Pro:

No downstream manipulation.

Downstream systems see the test time

Cons:
Must reliably shim whole application
Doesn't work with services owned by other teams.
Will not work with SaaS components. 

Isolating Data by Time

Create unique data sets for each test phase.  

Pros:
No system changes
No application changes
Test can run overlapping
Works for SaaS
Works for cloud

Cons:
No true end to end test with same data
Data must be synthesized for all non-initial phases

Conclusion

Full process lifecycle can be difficult, especially if there are time based rules that cannot be changed to run a test. Try some of these approaches and see how they work for you.  I've used Program Time manipulation via libraries, Separate Data for each phase, Data Fixes and Effective Date testing when we planned on it early in the project.  The choice depends on the business problem, the operational model and other factors.

Good luck with your full lifecycle testing!

Created Feb 2017