Parallel runs for addressing billing migration challenges
Parallel run is nothing but running the rating and billing processes in parallel to generate bills and associated reports in both legacy and new stack followed by a comparison cycle to check whether the new system behaves as expected for a given input data.
There are two key steps involved w.r.t inputs –
1) Customer Account attributes like customer account status, products/subscription details etc. For example, if we want to check proration of charges, then the termination date has to be same in both the legacy and the new stack.
2) Same usage data for legacy and the new stack like date (holiday or non holiday), time of the call (peak or half peak), duration of the call and type of the call (Voice, SMS, Data etc).
One of the complex scenarios where parallel runs help is - shortening and lengthening of the bill cycle duration due to change of bill date as per the customer request. This scenario involves proration of charges, applicability of usage bundles and monthly packs due to change in duration of bill cycle where it includes complex calculations and presentation changes on the bill. Thus it is very difficult in coming to a conclusion based on the output generated by new system.
Parallel runs can be implemented either only in User acceptance testing (UAT) phase or in both UAT and production (at least for one bill run). To minimize the cost of environment and testing – parallel runs testing can be limited to UAT phase only. However, this decision depends on the number of defects discovered in the earlier testing phases and mainly the regression issues. If the defects discovered during the system testing are more than the normal trend then definitely it qualifies for parallel run in production as well to avoid issues in customer experience.
If the decision is taken very late in the cycle then the preparation for parallel runs will be delayed impacting the overall delivery schedule.
Having discussed the importance of parallel runs, there is a lot of debate which is unavoidable - many people say that parallel run is a waste of time and money and many questions arises like, when there is a testing team why do we need parallel run?
Finally one should weigh the cost and the risk of impacting the customer experience after going into production rather than treating it as a decision whether parallel run is required or not.
