Bugs happen — learn from them

So for the past couple of weeks, our team deployed updated versions of our app into production to address some interesting issues. But of course, when we were in the midst of trying to address them, they didn’t seem so interesting then.

Issue 1: Login would fail *sometimes*

Apparently, we were using an old LDAP server that was on its way to being decommissioned. You’d think getting our app to point to the updated LDAP server would be the needed fix. Well, technically, it was! But in the course of deploying, a new version of nodeJS got released wherein one function our app was using got deprecated. This then caused problem in saving records which we hadn’t anticipated when we did our impact analysis. The lesson is not to skip on the smoke tests even though the change seems quite straightforward.

Issue 2: We’ve deployed a new version but the browser keeps using the cached old version.

We typically find Chrome more reliable than IE. But this time around, we found that IE was the one behaving as designed / implemented / intended. Despite the initial setup not to cache, Chrome was still using an older version of the app even though we had already deployed a newer one. It also didn’t help that we kept on clearing our cache during testing so we had always been getting the latest version. The lesson here highlights the value of having a staging environment that is a mirror of production — this way we’d simulate what prod users would encounter when the new version gets deployed. Also, another lesson is to test in another environment where we don’t keep on clearing the cache since prod users most likely won’t be clearing their browsers as often as we do while doing integration testing.

Issue 3: Error on saving a particular profile record

One of the standard test cases from where I previously worked that I somehow carried with me (most of the time) is to check for whether leading and trailing spaces are trimmed when saving data in forms. For our app though, we had to previously make a decision to ship or delay, and opted to go ahead with deployment with that bug still open. Extra spaces in the field values didn’t seem critical compared to not having the app at all. Little did we know that spaces entered into a particular field would somehow cause a circular reference in the json formed to submit the data and cause an error in saving and retrieving the data. Thankfully, the impact wasn’t so bad considering we only had 1 instance of this issue out of around 300 records that had been created or modified. Lesson learned here is well not to skip trimming leading and trailing spaces if you can help it and to test for the impact of spaces in your test data.

So there. Bugs happen. There’s no such thing as perfect software. There’s no sense in kicking yourself endlessly over bumps like these. What’s important is to get some learning out of instances like these and to keep on moving forward.


One thought on “Bugs happen — learn from them

  1. Pingback: Five Blogs – 20 February 2017 – 5blogs

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s