Tuesday, December 19, 2006

Many times we may come across situations where we may have missed some test cases or we may have written better bug report. For that moment we may learn from them, but over the period of time we may tend to forget that learning. I thought blogging about these kinds of things in the form questions would help me in cataloguing them for future use. So here it is to start with...

Consider an application (APP1) which collects some user information and puts into a database (DB1). One of the information that it collects is say a PostalCode. Maximum number of digits/characters allowed in PostalCode is 10.

There is another application (APP2) that provides Search capability to users. But this APP2 do not perform the search in the same database DB1. It has it's own database DB2. The data is pulled into DB2 from DB1 using ETL jobs.

That was about application architecture.

Now coming to the search functionality... user is provided with a web page where she can enter search criteria and submit the query. The text field for PostalCode accepts maximum five characters. When user submits the form, the UI code basically calls a stored procedure in the backend. And unfortunately this stored procedure does an exact match (stored procedure does not use SQL keyword LIKE) for PostalCode. Due to this if user enters say 12345 as PostalCode user gets to see only those records whose PostalCode is exactly 12345; they don't see records with PotstalCode say 1234567, 123458, etc. But the end users expect these also to show up in the search results.

Whatever may be the reason, the fix for this issue was given as follows. The ETL job was modified to truncate the PostalCode if it is more than 5 characters long and then loaded into the Search application’s database (DB2).

Now as a tester what test cases we should write/execute to verify this fix?

4 comments:

karunakar said...

Sorry vinyak ,i could not understand the question...can u plz explain in more detail??

Vinayak Kumbhakern said...

Karunakar, I have modified the post now.

Pradeep Soundararajan said...

Whatever may be the reason, the fix for this issue was given as follows. The ETL job was modified to truncate the PostalCode if it is more than 5 characters long and then loaded into the Search application’s database (DB2).

Hint: If you want a tester from who is unaware of the domain you are working on to also try giving an answer, you might want to make it more generic. Not that you did not do but I was dumb to not understand it.

This problem is interesting, to me.

I would try using http://www.satisfice.com/tools/pairs.zip for the purpose!

Just in case, I have made wrong assumptions or understanding about the problem, my answer would obviously be a heuristic.

Deviprasad said...

Vinayak,
As there is no change in the front end no need to verify from front end…
And also fix done at ETL jobs. My testing approach will be like.
1. Identify the test data (postal codes) which is having more than 5 chars (digits).
2. Run the ETL job and verify the truncation done properly.