My thanks to the Weekend Testers Europe group that took the time to discuss a mind-blower of a problem today.
Here's the scenario: You have a product that a customer is interested in. This customer happens to be in Nepal. As you are going through the requirements, they state that it will be important that any dates also correspond to the Nepalese calendar, and that those date conversions are handled correctly.
Seems simple enough right? Just make sure that the dates used correspond to the dates in the Nepali calendar. What's the big deal?
It turns out... a lot (LOL!).
For starters, I came face to face with a bias... a Western bias. I have experience on a daily basis with only one calendaring system, that of the Gregorian calendar. It is pretty straightforward; well, except for that pesky leap year deal that makes February so entertaining every four years, but not exactly. See, it's not actually that easy. It turns out that, if a year is divisible by 400, then it's a leap year, but if a year is divisible by 100 but not by 400, then it's not a leap year (2000 was a leap year, 2100 will not be), but if a year is divisible by 4, and not affected by the previous rules, then it is a leap year, and every other year not associated with the aforementioned rules is not a leap year. Got that? Not too bone-wrenching a situation to handle; three if statements in a function and the number of days in a given year, and how many days in February that year is pretty straightforward.
Now, how would you like to know that the days of a given month could vary by a day or two one direction or the other, and a committee met fairly regularly to determine where and when the days will be each year (or to be closer to accurate, each decade) and the basic rules from the past were applied, but there was no guarantee that those days would replicate? Welcome to the Nepali calendar, which is based on the Hindu Bikram Samwat calendar. This calendar is a "lunar-solar" calendar, which means that keeping it in sync with the lunar cycles is just as important as is keeping it in sync with the solar cycles. This makes for a much more dynamic calendar, with many more rules as to how many days each month has and when they are applied.
This was the testing question we were all faced with today, and the comments in the exchange ranged from philosophical to downright comical. Everything from "well, that makes for an interesting challenge" to "aww, come on! Are you freakin' kidding me?!" (well, OK, that last one was not actually said, but you better believe I sure thought about saying it (LOL!) ).
We discussed a number of conversion programs that were available, both commercially and out on the web, and we determined that, actually, there was no way to test this problem with 100% accuracy. With the Gregorian calendar, we can look to December 31, 3999, and determine that it will be a Friday. With the Bikram Samwat/Nepalese calendar, we cannot do that (well, we might get close, but there is no way to, with 100% accuracy, state that). While the dates are somewhat in line with historic patterns, and if looking at enough data points, we can see that the Bikram Sawat calendar is actually fairly regular, there are just enough outliers to make it nearly impossible to make a nice, clean predictive leap year algorithm like we can with the Gregorian calendar. In the example we looked at, the function actually had each year mapped out with the lengths of each of the months.
We had a great discussion about the vagaries of this system, and we ultimately realized that, indeed, there was no way to test this system to give a 100% accurate answer. We could use a predictive heuristic of past trends, and we could get close to what we thought the dates would be, but we had no way of ensuring that those dates would be accurate. Instead, we decided that, to effectively test these scenarios, we would have to work with past data and with a greatly scaled back range of future dates, i.e. those dates that the astrological committee had determined would be used for the calendars over the next ten years. With that, we determined that we could test, with a high degree of confidence and accuracy, any date conversions performed. Outside of that range, however, and our confidence dropped. A century or more outside of the range, and we felt we had little to no confidence we'd be able to convert to an accurate date.
The lesson from this was not so much the situation of converting dates, but that of wrapping our heads around vague problems, and realizing that what might seem simple on the surface may turn out to be anything but simple later on. We as testers need to be asking questions about our product, about our customers, and their expectations. A person using a calendar product in the West with the Gregorian system would be outraged if we couldn't predict accurate dates within the next 30 years (think of all those fixed rate mortgages and when their loan periods would end for the purpose of calculating interest?). By contrast, due to the vague nature of the way dates are assigned in the Bikram Samwat/Nepalese calendar, the ability to deal with the vague nature of future dates may be acceptable (and may actually be expected). We determined that as long as the agreement and requirements were in sync with the known and determined dates for the next decade, or those determined in advance by the astrological committee that determined the calendar, that that would be good enough.
If these questions intrigue you, and if you find these ideas and the thought of talking out problems like this to b e your idea of fun, then Weekend Testers needs you, and you need Weekend Testers. This is only my third experience with them, and already I have found this group and its weekly meeting and mission to be a "don't miss" opportunity (I actually am a little bummed that I will be missing it next week, but I will be camping with my daughters well away from any Internet connections, and I'll just have to learn to live with that (LOL!)). I do however plan to be there for future installments when I am able, and yes, I'm encouraging others to do the same. It's a no pressure way to learn some new ideas and techniques, and, in this case, address a problem and a challenge I never thought I'd face. whether I ever do again or not is one thing, but the additional ideas and thoughts that came from it proved to definitely be worth the time.
No comments:
Post a Comment