Warning: Undefined array key "QS_user_email_post" in /home/public/wp-content/plugins/quick-subscribe/quicksubscribe.php on line 260

Warning: Undefined variable $message in /home/public/wp-content/plugins/quick-subscribe/quicksubscribe.php on line 264

שנה הלכה שנה באה
אני כפי ארימה.
שנה טובה לך, אבא,
שנה טובה לך, אמא.(link)
“For auld lang syne, my dear,
for auld lang syne,
we’ll take a cup of kindness yet,
for auld lang syne. (link)”


Tomorrow we celebrate in Israel the New Year in the Hebrew calendar. Yes, 4 months before December ;), and guess what… we are now celebrating year 5771! The difference between the years counted in Gregorian calendar and the Hebrew calendar is ~3760 years.

New years, calendars and dates are extremely important for Software Testing.

Let me tell you a true story about value, about a bug. It was not a bug I found, but in fact a bug I had created.

Once upon a time I was a programmer, and wrote my very first commercial piece of software when I was in college: A library management system for a high-school, and it had to manage books and loans, and generate reports with due dates and past-due notices. It was, modesty aside, a beauty. Easy to use, quick, implemented all the requirements I was sent and even had big transparent buttons on a book-collection-picture background (well, these was in ~2000, I guess user interface tastes have changed).

Once done, I visited the school again, installed the software and database, and demonstrated the software to the manager (who had asked it from me) and the librarians. They loved the big transparent buttons! And also approved the flow of the system, how one catalogues books, and how one manages loans. Acceptance Test: Pass.

A week later, I receive a call from the librarian: The software is bad, and they can’t use it. “What’s the problem?”, I asked.

“We don’t use Gregorian dates. It is our policy that all the dates used at school and in correspondence with the students are Hebrew dates. All the reports of your application say October 14, 1999 or November 22, 2000 when we need ד׳ בְּחֶשְׁוָן תש״ס or כ״ד בְּחֶשְׁוָן תשס״א !”

Now what? No one had told me about this ‘little’ detail. Not in the requirements, and not upon acceptance homologation. So, is it a bug? Whose fault it is?

This story taught me forever that bugs are not a matter of contract. Bugs are a matter of value, and the application was completely devoid of value as it was. I added date-transformation function to all the outputs (was a lot of extra-work), and returned to the school with a version 2.0.

Almost all software has a module that is date sensitive. How thorough you test it?

Dates have tricky properties. Leap (bissext) years have one additional day in February. How do date calculations in the software you test work? If it does date subtractions, leap years can provide a good test path.

That is, if the software at least knows how to deal with the existence of leap years. For example, Microsoft Zune devices around the world rebooted and freeze in 2009, because a leap year had finished (details on the bug here).

Zune error message

Another thing you should pay attention, like in the story above, is to date locale. If the application is installed in a Hebrew OS, or a Chinese OS, it may need to display localized dates when it doesn’t. Or the opposite: Windows settings may push the localized format to the application when there was no intention of it. A good starting point to learn about locales is here.

What else? Pay attention to ends. I’ve heard of problems with the days 31 and the month of December. Or both together, December 31. Does the application behave properly in these cases? What about when the day changes to the next one? Can the software cope with the change of year?

Date changes on runtime are very important. What happens if you move the date/time back in the middle of operation? What happens if you execute a function, manipulate the time, and execute the function again at the very same time?

We shouldn’t forget one of the most notorious of date bugs: Y2K. Lots of early software used two digits for date handling, so the passage from year (19)99 to year (20)00 could have been catastrophic (at the end, only a few failures were reported).

Can you identify what are the real boundaries of the date format used in your application? Maybe Y2K isn’t a problem, but Y2038 or Y2106 is.

Well, here’re my wishes for a great year ahead. Wish you all good surprises and good and fun testing.

Shana Tova (Happy New Year)!!