A Silly Mistake Can Lead to a Big Mistake

May 13, 2011 at 11:53 am · Filed under Software Testing

Writing code and testing software are both challenging tasks in Software Development. It is never easy to make cent percent synchronization between these two. It is challenging for a developer to write almost flaw less code similarly it is challenging for a tester to cover almost cent percent of testing path.

Very often we are in a situation where we are forced to or we have to overlook some minor analyses and we leave some very minor flaws in code or in testing.  Because of the ignorance of the analysis apparently we think that those minor flaws won’t affect the whole system in its major functionalities. But in reality a very minor flaw in the system can lead it be an unusable system.

Few days back I was asked to develop a tool to modify an SQL file which were generated form a replicated database and had to execute the modified SQLs to a pgSQL database. The original file size was 70-80MB and total number of lines were about 600K.

The main task was to filter out some specific SQL blocks from the file then writing those modifications into two set of files. One set of files was a single file that contained the whole modified SQLs and another set of files was with multiple files that contained the modified SQLs as several chunks.

Since number of lines were huge so it was difficult for me to test all those line manually, but I tried my level best and found it to be according to the requirement. I opened those files manually and seemed to be OK. I executed the second set of files (the chunk SQL blocks) and these were successfully executed to the desired database. BUT when I executed the first set which contained the whole modified SQLs then it showed me syntax error.

I started to analyze the file and found that very few of the very last lines were not present in it. It was also very interesting that the skipped lines were started from a middle of a line, I was sure about my logic that either it will write a complete line or skip it completely, fraction of line is impossible.

So at first glance I supposed it to be a memory related problem and started to minimize the original file size but found the same problem every time  I minimized the files. That really shocked me as the other chunk files even bigger than my problematic was OK. Then I went to the source code and found that every StreamReader or StreamWriter I used for reading/writing files were properly closed except the problematic one. I modified the source code and then executed the tool which then solved the problem.

As we know an opened stream made a file inaccessible but in my case I was able to use it and that made me think that closing the stream wasn’t big a issue apparently.  But that silly mistake made my application a useless one. That is why every developer and tester should be aware about his silly mistake, they need to increase their analysis even after a very very minor case, they have to increase their foreseeable power.

Leave a Comment

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

December 11, 2010 at 12:38 am · Filed under Software Testing

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 data/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.

Comments (9)

DATABASE MIGRATION TESTING

September 17, 2010 at 11:13 am · Filed under SQL

Many often you are required to perform database migration testing. The task isn’t easy but if you follow some instructions one by one then the task will be easy for you. In my professional experience I’ve executed three types of database migration testing. These are MySQL to SQL Express, pgSQL to SQL Server and SQL Server to pgSQL.

When you will execute the task then you will have to face many db specific challenges, but here I’m presenting only the cases that are very to common to every database migration task.

Following cases should be considered in database migration task

  1. Unless specified, the migrated database should have equal number of tables, views, stored procedures, user defined data types,… and equal number of columns for each of the mentioned objects.
  2. Unless specified, the migrated database should have same name and same letter case for the names of tables, views, stored procedures, user defined data types and columns.
  3. Unless specified, the column/parameter order in tables, views, stored procedures and user defined data types should be same as original database.
  4. The type and size including precision of every column should be same as original database.
  5. If migrated database doesn’t have exact type as original database then it should use the type which is most similar to original database. Special consideration should be taken for numeric, bit, binary, image and date/time [with/without time zone] related data types.
  6. The constraints Primary Key, Foreign Key, Unique Key, Default, Check, NULL and NOT NULL on column(s) of table(s) in migrated database should be same as original database.
  7. Unless specified, the constraint names on every table should be same as original database.
  8. The actions of CASECADE DELETE and CASCADE UPDATE of foreign key(s) should be same as original database.
  9. Unless there has any limitation in migrated database, then the migrated data should be same as the data of original database.

Leave a Comment

Take Care of Your Alternative Email!

May 5, 2010 at 9:32 pm · Filed under Helpful Topics

Alternative email ID is an easy way of retrieving forgotten password. Many of us use this feature in many applications. To use this feature we use two email IDs. Basically one email ID is for prime usages and another(the alternative email ID) is for retrieving the forgotten password of the prime email ID.

Since the usages of prime email ID are very frequent, therefore we take care of the ID and it’s password regularly. BUT have you thought about your secondary email ID? If the password of this ID is weak then it may cost you harmfully! If someone knows this ID’s password then you will loose everything! At first he will retrieve the password of your prime email ID [basically email IDs are public] and then … everything!

So beware about your secondary or alternative email ID and password. For security purposes you can use some unconventional secondary email ID[so that someone gets difficulty to know the ID] and of course a strong password. Those who use more than two email IDs should also be concerned about the passwords.

Leave a Comment

UserScript and greasemonkey an Easy Way to Modify Web Pages

April 30, 2010 at 12:02 am · Filed under Helpful Topics

Do you want to see a web page as you like? Do you want to add some extra functions to a web page that will work for you? Do you want to make these changes On-the-Fly to a web page? Do you want these to a web page that you haven’t developed by you or you have no modification access to it? Then here is UserScript and greasemonkey.

You can achieve those goals easily in Mozilla Firefox. You are needed only five basic steps:

1.  Add the gresemonkey [a Mozilla Firefox] extension to your Firefox browser

2. Write your desired functionality/features to a UserScript. Include/Exclude the web address(es) in your UserScript that you want/doesn’t want to have the feature(s)

3. Then add your UserScript to the greasemonkey

4. Enable(if not) the greasemonkey into your browser

5. Finally open your desired web page into the Firefox web browser.

Here I’m not going to explain more about the greasemonkey and UserScript. but the basic idea of UserScript is:
UserScript is nothing but JavaScript code. It has two main sections: a) Header: where you will provide the Name/Description of the script, include/exclude the web pages that you want/doesn’t want to have this UserScript and b) Body: where you will write your desired feature in JavaScript code.

Once you write a UserScript then greasemonkey will provide you option to attach the file into it. An important point is that a UserScript file will have the extension .user.js [e.g. MyFeature.user.js]

Here is a sample UserScript:

// ==UserScript==
// @name SayHelo
// @description Whenever a page of google will be loaded then it will say Helo to user

// @include *google.com*
// ==/UserScript==

function SayHeloToUser()
{
alert(“Helo I’m from UserScript”);
}
SayHeloToUser();

After adding this UserScript if you open any page that has google.com in address bar then the message Helo I’m from UserScript will be shown by the browser.

> To know about greasemonkey follow the links greasemonkey and greasemonkey wiki.

> To know about how to add/delete/manage UserScript please click this link. Also don’t miss out to read the article from this diveintogreasemonkey, especially the PDF doc.

> To find existing UserScript that might work for you, follow the link www.userscript.org. This is a huge resource of UserScripts.

I hope you enjoyed this article! :)

Leave a Comment

How to Describe Table in MS SQL Server

April 28, 2010 at 12:39 am · Filed under SQL

Unlike Oracle or MySQL there is no DESCRIBE or DESC command to describe a table or object in MS SQL Server. But to describe a table or object MS SQL Server provides a very useful command or built-in stored procedure sp_help.  One can easily describe an object using this command.  You can use this command in the following ways:

> sp_help ‘your_object_name’ or
> sp_help your_oject_name
The first method is more useful because you can specify db/schema name here. Here is the command along with output:
sp_help ‘dbo.Sales’
Output:
Output of sp_help command

More info  is available here

Leave a Comment

Finding Distance between Two Points Given in Latitude and Longitude Points

March 30, 2010 at 7:02 pm · Filed under Helpful Topics

In many application especially in GIS system it requires to find distance between two points given latitude and longitude. Here I’m explaining the procedure to find distance from such type of points.

At First, Let Us See How a Point is Represented:
A point P is given in the format P(40°44′55″N, 73°59′11″W ). The first part is called latitude and the last part is called longitude.  We read a latitude/longitude [e.g.] 40°44′55″N as 40 degree 44 minute and 55 second North[N=North, S=South and so on E and W].

Formulas:
There has many formulas to find distance from given latitude and longitude points. Among them two formulas are very easy to implement and give result with a very little error. One is Haversine and another is Spherical Low of Cosine.

Keep It Mind:
The above formulas are for spheroidal shape. The earth is not quite a sphere, there are small errors in using spherical geometry; the earth is oblate spheroidal with a radius varying between about 6,378km (equatorial) and 6,357km (polar), and local radius of curvature varying from 6,336km (equatorial meridian) to 6,399km (polar). 6,371 km is the generally accepted value for the Earth’s mean radius. This means that errors from assuming spherical geometry might be up to 0.55% crossing the equator, though generally below 0.3%, depending on latitude and direction of travel. AND both the formula find shortest distance on earth surface [as-the-crow-flies]. One can use Vincenty formula for accuracy up to 1mm

Haversine:
If P1(lat1, long1) and P2(lat2, long2) are two given points, R is radius of the Earth and D is the distance between the points then
D=C*R, Where
C = 2*atan2(√a, √(1−a)),
Δlat = lat2− lat1
Δlong = long2− long1
a = sin²(Δlat/2) + cos(lat1)*cos(lat2)*sin²(Δlong/2)

Here atan2(y,x) is a special implementation of arctangent atan(y/x) in programming languages.

Spherical Low of Cosine:
For the same two points and same assumption the distance D is
D = acos(sin(lat1)*sin(lat2)+cos(lat1)*cos(lat2)*cos(Δlong))*R
The Spherical Low of Cosine gives more computational precision and finds distance as small as 1m.

Please Note That:
Depending on the calculation of trigonometric function you are required to convert the latitude and longitude into radian unit.  So if we convert the point P(40°44′55″N, 73°59′11″W ) into radiance then,
Latitude = ( (40 + 44/60 + 55/(60*60) )/180 )*π and
Longitude =( (73 + 59/60 + 11/(60*60) )/180)*π

Then depending on the unit of R the distance D will be in km/miles/…

When a latitude/longitude will have S/W direction then put the negative(-ve) value of the latitude/longitude into those formula.

So let start to compute distance between tow points given in latitude and longitude.

Comments (1)

Really Software Testing is Not Inevitable and Never Complete

March 29, 2010 at 6:47 pm · Filed under Software Testing

It is not new or I need not to prove it again that Testing is not Inevitable and Never Complete. But last month I had an experience from where again I have concluded that really Testing is not Inevitable and Never Complete. I’m sharing the experience here.

It was the day when we planned to ship a pilot release. According to our plan we were testing the product and on the final day and final moment we were not getting any bug from the product. Our SQA manager asked me whether there were any findings or we would ship the product. I told him that the product seemed to be stable, and we were ready for the release. I requested few minutes from him just for an overview of the product.

In the last moment I found a bug that was not a bug to me until a new feature was implemented in this new release. I reported the bug in the issue tracker and manually informed our SQA manager. Our SQA manager took it and instantly went to the Project Manager room. While the bug was fixing then I found another bug and before reporting it to the issue tracker I went to the Project Manager room and notify it to both SQA manager and PM.

Within a very short time the bugs were fixed and again we were testing the product. After finding those bugs some exploratory thinking came to my mind that I could find more bugs in the same area. Alas! I was true! I found another new bug that wasn’t a bug to me until I reported those bugs and started thinking about those bugs. In that day we found another three/four bugs in the same area. So a total of 6/7 bugs were found and that was within a very short time. The moment was really very exciting. We found a bug and PM fixed it and again we found a new bug and PM fixed it…. Once a time our PM told us that really it was interesting. It was like ACM Programming contest.

Form this experience, I found how Software Testing is challenging and how unpredictable is it! While a minute ago I was thinking there was no bug in the product there we fond so many bugs within very short time.  The software testing seems me like Unpredictable Test Cricket. Look at the score of 2nd Innings of 2nd Test Match 2010 between Bangladesh and India. Once a time Bangladesh were 290 for 3 and the innings came last to 312 for 10.  7 wickets gone for only 22 runs. Can you believe it?

That is why all we say Really Software Testing in Not Inevitable and Never Complete.

Comments (3)

Usages of ROW_NUMBER() in MSSQL SERVER

February 14, 2010 at 4:55 pm · Filed under SQL

A very important feature of SQL Server is the usages of ROW_NUMBER() function. It gives sequential row number[starts from 1] over duplicate touple (a set of column[s]) and the order you set. The sequence of using ROW_NUMBER() in your SELECT SQL is:

ROW_NUMBER ( ) OVER ( [ partition_by_clause ] order_by_clause )

The PARTITION BY clause determines the duplicate touples on which you
want the sequential row number and ORDER BY clause determines the
criteria to set row number.
Lets see how it works and how it helps us….

In a simple way consider you have a table SALES like

CustomerID ProductID PurchasedDate
C000001 P000001 2010-02-01
C000002 P000001 2010-02-01
C000002 P000001 2010-02-02
C000001 P000001 2010-02-02
C000001
 P000002 2010-02-03
C000001 P000001 2010-02-03
C000002 P000002 2010-02-04
C000002 P000001 2010-02-04
C000001 P000001 2010-02-04

Now if you execute the following SQL:

SELECT CustomerID, ProductID, PurchasedDate, ROW_NUMBER() OVER (

PARTITION BY CustomerID, ProductID ORDER BY PurchasedDate DESC) AS RowNo

FROM SALES;

Then the output will be

CustomerID ProductID PurchasedDate RowNo
C000001 P000001 2010-02-04 1
C000001 P000001 2010-02-03 2
C000001 P000001 2010-02-02 3
C000001 P000001 2010-02-01 4
C000001 P000002 2010-02-03 1
C000002 P000001 2010-02-04 1
C000002 P000001 2010-02-02 2
C000002 P000001 2010-02-01 3
C000002 P000002 2010-02-04 1

Explanation of the output:
In the SALES table there has total four distinct CustomerID-ProductID combination. In the SELECT statement this distinct combination is gained by partitioning the column with CustomerID and ProductID columns. Then the partitioned columns are given row number based on PurchasedDate column. In this case the order is DESC.

So the combination C000001-P000001 has 4 rows with dates ’2010-02-01′ to ’2010-02-04′. So the ROW_NUMBER()[here the alias RowNo] of row C000001-P000001-2010-02-04 is 1 and then C000001-P000001-2010-02-01 is 4. Similarly the combination C000002-P000001 has three rows with dates ’2010-02-01′, ’2010-02-02′ and ’2010-02-04′. So RowNo for the combination C000002-P000001-2010-02-04 is 1, C000002-P000001-2010-02-02 is 2 and C000002-P000001-2010-02-01 is 3. Here if you use the ASC as ORDER BY then the RowNo would be reverse than it is shown.

Now if you carefully see the second table then imagine how easy it is for you to select distinct CustomerID-ProductID based on most or least or Nth recent sales.

For example you now want to know the 3rd recent sales date of every CustomerID-ProductID combination. So your SQL will look like:

SELECT temp.CustomerID, temp.ProductID, temp.PurchasedDate
FROM (
SELECT CustomerID, ProductID, PurchasedDate, ROW_NUMBER() OVER(
PARTITION BY CustomerID, ProductID ORDER BY PurchasedDate ASC) AS RowNO
FROM SALES
) AS temp
WHERE temp.RowNo = 3;
The output is:

CustomerID ProductID PurchasedDate
C000001 P000001 2010-02-03
C000002 P000001 2010-02-04

Isn’t it very useful feature?

Leave a Comment

Do You Have a Hit List?

December 30, 2009 at 4:25 pm · Filed under Software Testing

In software development life cycle this is a common scenario that the tester gets less time than the anticipation. And when he goes to execute test runs then he finds a very big gap between time and test cases. He blames the shortage time.

But devising a technique he can overcome much of the ‘time limitation’ problem. If he has a list with some key points that does not require writing down in test cases and without altering the keys he can apply much of the points in any situation and in any type of application, then of course it will save time to find/identify bugs. I call this list as a Hit List.

Basically the Hit List will have two types of contents. One is Context dependent key points and another is context independent key points.

Context dependent key points: Basically these key points remain unchanged throughout the application, points are identified through testing experiences on the application.  Example: Fixed format of Price, Acc No, Title, frequent occurrence of critical bug,…, etc.

If your are keen to grab these type of points then you can easily apply these to your testing software very quickly.

Context independent key points: These points that do not depend on your testing software. Example: data type conversion/overflow error, rounding/truncating problem of number/string/character.. data types, entering special characters to input fields, unplug network connection, read/write file accessing error, …,etc. You can identify same type of more points for your Hit List.

When you have identified the key points then you can apply these to your testing software/application very quickly. Depending on how fast you have access on the points, it will save much of your testing time.

Now the question where you will save your Hit List? The best position is to keep it in your mind. If the List grow enough or you are confused recalling them in time, then you can save these to writing documents like notepad, wordpad,..,etc.

On July 28, 2009 I had a presentation on it. You can find more from here(http://www.sqabd.com/lt_present.php?id=lt5).

Good luck


Comments (4)

Follow

Get every new post delivered to your Inbox.