>Hi,
>I have been in business long time and I used to do 0 (zero) testing before releasing new updates. And invariably, as soon as the app would get in the hands of a customer, it would crash. I even remember the times - before internet - when I had to ship a diskette overnight or send it with a taxi.
>
>Now I am doing much more testing, even though updating is much simpler.
>
>Which brings me to a question. I don't have a QA, so I am it :)
>
>Currently I am doing a refactoring where 3 SQL Select statements are replaced with 1. The SQL Select is very important because it is part of the important Business unit of the application. The way I am testing it as follows:
>1. I created a list of test cases (various possibilities of data)
>2. Run this new SQL Select and BROWS the resulting cursor
>3. Run the old 3 SQL Selects against the same data and BROWSE resulting cursor.
>4. Compare - row-by-row the two cursors.


let the old statements in the code to compare old and new results via some basic tests on line & column count of returned cursor during dev.
then bracket old statements in compiler directives so you can deiver new versions FAST, but during the next month let your code always compare results during dev action. When you fel safe, remove old code
>
>How else would you suggest that I test this change?