Sometimes when testing, we encounter scenarios that are so rare that they may only happen once or so a year, every few years, or perhaps only once in a lifetime. These types of events or occurrences need to be in the back of our mind while they are approaching, so we can be sure to test when necessary.
The Daylight Savings
While not every town in America recognizes daylight savings, and especially the whole world, it is a strangely impactful event that really messes some people up in Spring, and one that some looks forward to in Fall. Most go to bed at night wondering if their alarms or phones will auto adjust for the new time come 2:00am, and there are some like myself who set multiple different alarms on different devices to prevent waking up late to the Sunday morning activities. The latter of course being a Spring problem.
When testing, it’s important to note if your product has time as an important factor, and if so, what happens when the clock strikes 2:00?
I thought it was interesting when I checked the weather for tomorrow’s day and noticed 1:00am written twice. That actually took me a moment to process and then made entire sense as we will relive the 1:00-2:00 hour tonight.
Seeing this made me think of the testers over at The Weather Channel app team, and the scenario they had to test which occurs twice a year for only specific regions of the world.
The Leap Year
I recall a few years back encountering a production bug with a user’s data who had February 29th as part of their information. Though I don’t recall exactly what field, it unfortunately wasn’t an obvious field like birth date, but rather something like CreateDate or an audit field which caused the user’s login page to look a little funny. This led to deeper investigation with a temporary fix of moving the date to something more regular until we were able to push a more permanent fix to production.
This would be another scenario where testing is so rarely encountered, but something noteworthy when the time approaches.
A couple other events to consider when testing is phone numbers and license plates. Recently I wrote about the increase in character count on the license plates in Wisconsin. That impacts things like the database and the UI that the DMV uses for license plate renewal and registration. It also has an impact on the software that car dealers use when distributing new plates. It is possible that any software was designed with this in mind, but testing and validation becomes slightly different, as now they accept letters before numbers, and vice versa.
I was recently thinking about phone numbers and how the seven digit numbers are soon to max out with the distribution of phone numbers growing so fast. They were able to assist the problem slightly with the introduction of area codes, but the problem will reiterate itself again soon I’m sure. Of course they can separate regions and add more area codes, but I wonder if and when they may add a region code like they did a few years back when people used to type 1 before the area code.
While I don’t know much about the phone number industry, it’s just another one of those events that occur so rarely that it may never be tested or designed originally, but perhaps the kind of thing we as testers should be aware of if the time is approaching soon.
Fortunately we are still a long way off from a five digit year!
What other rare occurrences have happened in the past or are yet approaching that we as testers have had or will get the joy of testing in our lifetimes?