Pro-rating Testing Challenge

I am currently reviewing a book on domain testing. While doing that I realized I can put up a testing challenge based on what I annoyed my colleagues with a few years back. I disabled comments on this post in order not to spoilt future visitors of my blog. You will have to find another way to respond to this.

Imagine a service which is rated on a monthly basis like Spotify, Watchever (they don’t pay me for writing this blog), pay-TV, phone lines, or mobile phones. Usually that means that you have a fixed monthly rate.

Now, the business prescribe that you have a monthly fee that you need to pay. For example for Spotify premium this is 9.99 EUR, and something else for some other service. The business rules also provide that you can cancel this service mid-month before payment. Then you will be charged only the pro-rated amount of the monthly fee for the current month. For example, if the payment period starts on the 1st of the month, and you cancel the service on the 3rd of the month on a 30 day month, you will only pay 2/30th of the monthly fee for the final month.

Unfortunately we deal with a larger system. In that system the pro-rating is transporting from the domain subsystem to the billing subsystem via the percentage of the prorating. That means that for the above scenario we will trigger some process on the billing backend with 1/15th in percent, yielding 6,666666666667 percent. The value used here is a double-precision floating point value.

Analyze this program (consisting of both subsystems) for interesting variables, what could go wrong, and how would you test it?

  • Print
  • Twitter
  • LinkedIn
  • Google Bookmarks

Leave a Reply

Your email address will not be published. Required fields are marked *