As experienced developers, we are already familiar with good testing practices. Even so, it never hurts to be reminded about some of the more critical habits to maintain.

Any modification greater than trivial should be tested in one way or another by at least two people. The people assigned should not be a part of the team that created the design or coded the modification. It would be best if one of the testers is an experienced user, because users seem to have a knack (for obvious reasons) of understanding how the modification operates compared to how the rest of the system acts in the course of day-to-day work. This helps us obtain meaningful feedback on the user interface before going into production.

One of the testing goals is to supply unexpected data and make sure that the modification can deal with it properly. Unfortunately, those who were involved in creating the design will have a very difficult time being creative in supplying the unexpected. Users often enter data the designer or programmer didn't expect. For that reason, testing by experienced users is beneficial.

The C/AL Testability Tools provide features to support testing how system functions deal with problem data. If possible, it would be good to have users help us define test data, and then use the Testability Tools to assure that the modifications properly handle the data.

After we cover the mainstream issues (whatever it is that the modification is intended to accomplish), we need to make sure our testing covers all boundary conditions. Boundary conditions are the data items that are exactly equal to the maximum, minimum, or other range limit. More specifically, boundaries are the points at which input data values change from valid to invalid. Boundary condition checking in the code is where programmer logic often goes astray. Testing at these points is very effective for uncovering data-related errors.