Tips for Testing Your Custom Programs.

When it comes time to testing a new package, or customization, take some time to plan how you are going to test it.   Make your plan thorough, clear, and efficient.  Part of your test group should include some actual targeted users as well as professional QA persons.   Nothing breaks a program faster than an actual user.

A common approach, is to start testing, by trying to do "what we do now".  While it is important that the system be able to do the processing that you currently do, it is important to check all scenarios that it will now do with the enhancements that were added as well.

There is an adage in testing:  Use Good data/bad data/no data.  This means that your system needs to properly handle all cases.  The correct data should be processed and give the correct results.  Bad data should be caught, and the appropriate error processing occur to handle it.  A lack of data (or missing pieces of data) should be handled in the appropriate manner, also.  Testing for empty files, tables, rows, or columns is often forgotten with embarrassing results for the developer.

Planning your testing with these issues in mind, makes the testing faster, and more thorough.  Initially, a base set of test data should be developed that has all of the scenarios that you can think of.  This is the data that should be used repeatedly, until the package or customization handles everything in it correctly.  Once that occurs, then expand your data and test program.   Your test data should cover all the cases discussed above, but keep the values simple and easy to check results with.   A complex value may not add any value in testing and waste time in checking. 

One thing to keep in mind, is to change the order in your advanced testing.  It is surprising how often good data, followed by bad data, processes correctly, but starting with bad data and trying to follow it with good data does not.  Also, in the advanced testing stage, the more people that can be involved the better. More people have a better chance of hitting that unique sequence of events that bring out hidden issues, if they exist.

If your system supports multiple, simultaneous users make sure to test with more than one user at once in the advanced testing phase.   We have seen many cases of bugs only appearing when the system is under this type of load.   For example, what happens if two users access the same record at the same time?  if one user updates an record while another prints a report on the same table, etc.

Properly planning and implementing your testing, means greatly reduces the chance of those hidden surprises when you take your system live.  Don't let Murphy's Law rule your systems.

Contact us if you need help with thei topic.

Dave.