Software Testing in Proper Test Environment is a Great Challenge in SDLC

No doubt software testing is a great challenge in SDLC. To get a clear picture of your testing application you must have proper preparation in proper time and you have to execute all those preparations in proper time and proper places. On the other hand all the plans, hard works regarding software testing will be in vain if testing is not done in proper Test Environment.

In my professional experience I had found some bugs that were bugs because of not testing the application in proper test environment. Similarly I have missed some bugs that were because of not testing the application in proper test environment.

Proper test environment is not an easy term to understand. A proper test environment may relate hundred of tasks to do before testing any application. Here are some of  them:

> Application is built from proper SVN revision?

> Application is installed/deployed in proper way?

> In which OS the application is running on? What version is it?

> In which Browser it is running? Version?

> It is running where? Location, time, timezone, daylight saving?

> and so on………………..

Very recent I was missing a bug because of improper test environment. A desktop application runs mainly in USA, it communicates with server DB through web services.  The application is used by many users from several places of USA. Recently two date fields are added in it. The DB columns for these fields are of type Date, so it doesn’t consider Time/Zone related information.

In the mean time client complained us that many times they saw different dates than they provided for those fields. So I started to investigate the problem, executed different scenarios but couldn’t reproduce the bug. I tested the application both in local and live environment. The dates are selected from a calendar control and these are properly saved in DB server. Since the data type was Date so I thought there won’t be any TimeZone issues.

Just for curiosity I set different TimeZonse in my application running machine and server running machine and then started code debugging. From web service the data were returning to client side through a DataSet. When the data are assigned into a DataTable in client side then I wondered to see the return values in different environments. Here are the environments and return values:

Environment #1:
a)      App in Local PC (Time: 14:50, Time Zone GMT +6)
b)      Webservice in Live PC( Time: 03:50, Time Zone GMT-5)
c)      Original Start Date=12/05/2010 and End 12/11/2010)
d)      Now the DataTable have Start Date=12/05/2010 11:00:00 AM, End Date=12/11/2010 11:00:00 AM.
e)      So Start Date and End  Date are showing as 12/05/2010 and 12/11/2010.

Environment #2:
a)      App in Local PC(Time: 15:01, Time Zone GMT -5)
b)      Webservice in Live PC( Time: 04:01, Time Zone GMT -5)
c)      Original Start Date=12/05/2010 and End 12/11/2010)
d)      Now the DataTable have Start Date=12/05/2010 12:00:00 AM, End=12/11/2010 12:00:00 AM.
e)      So Start Date and End are showing as 12/05/2010 and 12/11/2010.

Environment #3:
a)      App in Local PC(Time: 15:01, Time Zone GMT +13)
b)      Webservice in Live PC( Time: 04:01, Time Zone GMT -5)
c       Original Start Date=12/05/2010 and End 12/11/2010)
d)      Now the DataTable have Start Date=12/05/2010 06:00:00 PM, End=12/11/2010 06:00:00 PM.
e)      So Start Date and End Date are whowing as  12/05/2010 and 12/11/2010.

Environment #4:
a)      App in Local PC(Time: 04:10, Time Zone GMT -5)
b)      Webservice in Local Newtwork( Time: 04:01, Time Zone GMT +6)
c)      Original Start Date=12/05/2010 and End Date 12/11/2010)
d)      Now the DataTable have Start Date=12/04/2010 01:00:00 PM, End=12/10/2010 01:00:00 PM.
e)      So Start Date and End Date are showing as 12/04/2010 and 12/10/2010 respectively. And this was the bug in different TimeZone.

Later I knew that whenever Date/Time related information are passed/retrieved to/from web service through DataSet/DataTable then it automatically adjusts time with TimeZone in SOAP XML [see here].

I couldn’t reproduce the bug if I had all things right except the different TimeZone. So this is how it is important to test application in proper environment.

Advertisements

9 thoughts on “Software Testing in Proper Test Environment is a Great Challenge in SDLC

    • Doctor Abdul karim this is an investigation on Time Zone issues. You can compare it with the diagnostics/investigation you do on the symptoms of a patient. By the way if you are interested in Software Testing field then I will teach you 🙂

  1. That was a very good example Maftahur. Many testers and programmers overlook issues with timezone, since they don’t understand it well. As a tester we must consider any date and time with its corresponding timezone. In fact in reality, any date/time we speak of or communicate have an implied timezone.

    In your particular case, the date on the server was probably taken as 12/05/2010 12:00am (i.e. midnight). So any client application trying to retrieve this date from a timezone that is more than 15 minutes behind or more than 24 hours ahead of the server’s timezone will change the date. So, if you were unlucky and your server was located on the east coast of USA (lets say New York), then any person from the west of this timezone would see the wrong date. Ouch! 🙂

    Well, it’s debatable if it is actually the wrong date, since any instance of date or time is relative to the location it is bound to. But sometimes (like in this scenario) we choose to ignore the timezone shifts for the sake of communication simplicity 🙂 or increased coding complexity 🙂

    By the way, try sometimes with very very old dates. These may have very weird side effects depending on the API you use to adjust timezones or DSTs.

  2. Nice topic Shishir Bhai. i’ve learned an approach for testing the time-zone related settings in test environment.But, in case of web-based application what will be the best strategy; whether we go for the time settings from client PC or we should go for the server PC . I think, this decision should depend on the business policy for that specific application. What is your idea in this regard?

    • If I may intrude 🙂 I don’t think it is a simple set of rules, or a “best” strategy. Neither do I think that the business policy have much to do with it. It may get complicated. For example, if you are using a JVM your system timezone may not matter if the administrator is running the JVM at a different timezone. But sometimes it can matter if you are using APIs beyond the JVM.

      Also, if you have a database server running at a different timezone, that could have been configured to it’s own timezone. So SQL queries that use the system date/time functions may work differently if they are executed in the DB, or prepared from the application.

      There’s more. What if your data is replicated to a different database? You may get different results if both the databases are not running on the same timezone. What if your date/time data was migrated from a legacy system? Did anyone check the timezone related integrity of the data after it was migrated?

      What if you are running a date/time search on the data? Do you need to convert the timezone of your search parameters on the client, or on the web application server, or no conversion is required? It all depends on how the implementation was done on different subsystems.

      There can be more scenarios. What matters is that we are aware that there can be problems with timezone, and we start thinking of the possible scenarios how things can go wrong.

    • I think sajjad bhai explain the matter clearly. But as a tester we should always try to test any sort application in such a environment which resembles to live environment (if possible). So in case of web app and time zone issue you may require to set time zone in both server and client machines. For example client may access the web app from multiple time zones, the web app may requires multiple web servers which may reside on multiple time zones, the web server may require multiple db servers which may also reside on different time zones… . Besides the location of client/server it also depends on how and where you are accessing/manipulating the date/time data.

  3. Wow, very nice and interesting post. I agree with you. Can you please share your thoughts on having an Independent Offshore Software Testing partner as an advantage. Look forward to your next post.

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