Posted by: SJC
Database application, Database application front-end programming, Software application development, Software maintenance, Software Quality, Software testing
So you have completed making the small changes required in your application, you have tested, you have debugged, you’ve done “everything” right! But alas, your application goes “live” and — problems! Strange error messages are being generated faster than the eye can follow! You find yourself saying “I’ve never seen that error before –” (…or perhaps you’re thinking more along the lines of “…<expletive deleted>…”! Whatever the thought process going on at that point, you have to act fast.
Naturally you have saved the “old” version of the application and quickly get the working version back in place. (…all the while hoping of course that the existing data was not somehow corrupted with the revised app). Your fears of corruption ever so slowly ebb away as your users once again begin their processing — without errors — and their incessant squalking about the problem has stopped. Life is good once again! You now take a deep breath and begin to look at the problem.
You continually ask yourself what could you have missed? You go back to your test environment and the app works perfectly. The thought occurs to you that perhaps there is some problem with the “live” data that your new app version sees as a problem and barks at you with those error messages you’d never seen before. You are not able to understand the error “…unable to understand…” – it tells you nothing of value for determining the root of the problem. You clearly are on your own with this problem.
You take time away from the problem to see if you can clear your head — all the while when away from it still not escaping — the problem has your head spinning! You look at the changes you made to your code – again – (fortunately you commented the most recent changes so that it was easy to review). You see no change that even with a hugh stretch of your imagination could bring about the chaotic issue.
You talk about your problem with others — they have no suggestions (…you don’t find it helpful when they say “…better you than me!” Their condolences don’t help. Only resolving the issue will help — you know that there is an answer! (…you also know that it probably is VERY obvious).
On your drive home from the office the light goes on! You begin to wonder if it was possible that the test data you were using was not the latest configuration? You remember that the last change to the app (…made months ago), added a new table – and you don’t remember that table in your test data. You also remember that during your changes you remember commenting out a reference to some include file that seemed to not be needed. Could it be that this was causing the problem?
Back at the office you find that include file in your source (…that’s the one that you DIDN’T comment on so missed it each time you reviewed your code changes). You uncomment it, recompile and run the app — with NO errors! Perhaps that wasn’t it after all! But wait — there’s more! You look once again at your test data and realize that it does not include a critical relationship that exists with the live data — the problem is with your test data, and once establishing the correct relationship you can begin to debug – since finally you have been able to replicate the errors on your test system.
The rest, as they say, is history. You find the problem and the new app goes “live” without issue. The subject of user calls is once again a discussion of what they want to add next! Live is good in development land once again!
The moral of the story — ALWAYS note changes made to source — ALWAYS make sure your test data truly reflects what is needed.