Stupid things that usually cause defects in software

In software, it seems like there are certain things that we implement that result in the same defects every single time. They are difficult to test and catch in action because they may only occur at certain times of day in certain places around the world. One way to catch them before they bite is to ask the questions and think them through. A third is to write unit or automated tests that can check for them. Below is a list of things that are stupid mistakes that I see over and over.

Dates

There are countless ways you can introduce defects when dealing with dates. Here are some questions to ask when testing things around dates. Answering these questions will help you see where there might be defects.

  • Which calendar library did you use?
  • Are you using more than one calendar library in different parts of the code? - - Are you comparing things to dates?
  • Should your comparisons include today (e.g. greater than or equal to)
  • How precise are your comparisons?

Example: The requirement is that you want everything from today and before.

Problem: Your database column is a timestamp, which includes hour, minutes, seconds, et cetera. You do the comparison something like this:

select * from db_table where updated_date <= system.time.now()

This can result in a precision problem. You want to compare on the day. This got me because it was 3PM in the afternoon when I was using the software. In the DB, the entry I wanted had a timestamp of 10PM. Technically it was in the future, but all I cared about was if it was the same day.

Times

Times can be a disaster—mostly in the interpreting of them and comparing them.

Use case: You need to collect the time someone is leaving.

Questions you should ask yourself

  • How are you sending the data from the browser to the server? Some javascript libraries automatically account for client side (browser) timezones. If you account for them again on the server or don’t account for the correction already made by the client you may get times that you do not expect.

  • Are you coercing an input to a certain timezone in your code? This is almost certainly a red flag. We caught a bug the other day where input between the hours of 11PM and 12AM would cause the results on the server to be interpreted as the next day. The server was coercing the data coming in to Mountain Standard time, when the server itself was using Mountain Daylight time (a 1 hour time difference). This was easily tested with a unit test so it should not happen again for us. I didn't have to stay up til 11PM to test it.

  • How are your times stored? Do timezones matter (e.g. are they in UTC in the DB, shown in local time somewhere else, passed to another service that expects a different format, etc cetera?)

Concluding things

You know that there are a million ways that bugs can creep into software. These are just a couple things that keep getting me. They are hard to test when you are going through the software. Sometimes you only find it because someone in New Zealand complains that all his dates are off by a day. Hopefully some of these questions will make your wheels turn and think about your own software.